Full or Synthetic Full?

[HendersonD]

Currently I have Veeam 9 set to do forever forward incremental. I back up once a day and have it set for 30 restore points (30 days). My understanding is my first backup was a full followed by incrementals. On the 31st day there will be a transform process where one of the incrementals will get injected into the full and then deleted. This transform process will then happen every day so I will have 30 restore points available.

I am using an Exagrid box as the target for backups. Exagrid's best practice is to set Veeam to do a full or synthetic full backup BEFORE this transform process ever takes place. The Exagrid is not a great device to do the transform on since it would have to drag blocks out of its dedup space, conduct the transform, and then write back to that space.

I am thinking about doing a full or synthetic full every 3 weeks (21 days) so I never trigger this transform on the Exagrid box. Two questions:

1. Do I have all of this correct?
2. If I do have it correct, would you suggest a full or synthetic full?

[Shestakov]

Hello,
Your understanding is correct.
The choice if to do active full depends on your plan of recoverability checking. If you perform Surebackup you may not need neither active nor synthetic fulls.
Please check this topic for explanation,

[HendersonD]

Even with Surebackup, I do not think I can avoid an active or synthetic full. I was told to avoid having the Exagrid box doing the transform process that happens when the number of restore points exceeds the retention policy. I believe the only way to avoid this transform process is to do an active or synthetic full BEFORE the number of restore points exceeds the retention policy. I am leaning towards doing a synthetic full since my Exagrid box is at the other end of a slower link. I believe the synthetic full happens on the Exagrid box so lots of data is not sent across the slow link

[foggy]

Correct, however synthetic full requires double I/O on the target storage, comparing to active, so I'd decide after testing whether you have enough time to complete it within your backup window. It's less I/O intensive than forever forward, however, all increments are injected on a single day, resulting in much more I/O load.

[HendersonD]

Is there any way to have the backup job do an active full once in awhile and the backup copy job do a synthetic full?
I am fairly certain the answer is no since these jobs are really linked. Whatever happens in the backup job is seen by the backup copy job

[foggy]

Not sure what you're trying to achieve. Backup job and backup copy job are not "linked" in terms of the full backup type, and backup copy job only provides active full functionality (or works as forever incremental otherwise). You can configure them as you want.

[HendersonD]

So if I do a synthetic full on my backup job once a week, what happens the next time the backup copy job runs? If I keep 14 days of restore points on the backup copy job, I want to make sure that the transform process never runs on the Exagrid which is the target for the backup copy job

[foggy]

Ah, so Exagrid is the target for your backup copy job, not the original backup job. Then you do not actually have a choice between active or synthetic full for it, only active full is available. To perform it, you need to enable GFS retention ('Keep the following restore points for archival purposes' check box), configure weekly backups, and enable active full (select the 'Read the entire restore point from source...' check box). This way, backup copy will behave as forward incremental job with periodic active fulls, avoiding any transforms. On the original backup job you can set anything you need, this does not affect backup copy job.

[HendersonD]

Let me see if I can phrase this better

I have an Exagrid box that I want to use as the target of a Backup Copy job. This link gives details on Backup Copy job
https://helpcenter.veeam.com/backup/vsp ... _task.html
It appears that a transform process happens for a Backup Copy job if the retention policy on this job is exceeded. Exagrid's best practice is to NEVER run this transform process on their box. Their best practice is to periodically run a synthetic full to avoid this. There is no where on a Backup Copy job to select "Create synthetic full backups periodically". This is only available for Backup jobs. Let's say I set my Backup job to create synthetic fulls once a week. After the synthetic full is complete, what happens the next time the Backup Copy job runs? Will this somehow reset the counter on the number of restore points I have for the Backup Copy job so it DOES NOT exceed the retention set for this job so I never run the transform on the Exagrid?

[foggy]

After the synthetic full is complete, what happens the next time the Backup Copy job runs?

As I've already mentioned, this doesn't affect the backup copy job. It will perform its usual cycle and copy incremental changes into the new incremental backup file, except the days when GFS active fulls are scheduled at - in this case it will copy the entire VMs data from the source, but this still is not dependent on the original backup job settings.

[Shestakov]

HendersonD,
By default Backup copy job always works in forever forward mode regardless what mode is used for the source backup job(s). Foggy is suggesting a workaround to force backup copy job to use forward incremental mode. Again it doesn`t matter what mode is used for source job.
Thanks!

[HendersonD]

So there is no way to avoid the transform process happening on the Exagrid box when using it as the target of a Backup Copy job?

[foggy]

The way to do it was described above:

To perform it, you need to enable GFS retention ('Keep the following restore points for archival purposes' check box), configure weekly backups, and enable active full (select the 'Read the entire restore point from source...' check box). This way, backup copy will behave as forward incremental job with periodic active fulls, avoiding any transforms.

[HendersonD]

Got it, thanks for all the help

[HendersonD]

I am re-reading through the post and came up with another question. With the Exagrid as the target of the Backup Copy job (not the Backup job), the suggestion was this

Enable GFS retention ('Keep the following restore points for archival purposes' check box), configure weekly backups, and enable active full (select the 'Read the entire restore point from source...' check box). This way, backup copy will behave as forward incremental job with periodic active fulls, avoiding any transforms.

This does avoid the transformation process on the Exagrid but if I am reading this correctly, the "Read the entire restore point from source" will send a large amount of data from my source (Nimble Storage array in my DR site) to the Exagrid. The Exagrid is at my ISP across a 500Mbps connection. Wouldn't sending this amount of data across this connection be problematic? I am backing up about 5TB total.

Perhaps the Exagrid box is just not a good choice for a Backup Copy job offsite?

[HendersonD]

Perhaps setting up a second backup job with the target being the Exagrid is a better route to go. With a backup job I can specify a synthetic full every once in awhile which will avoid the transform process on the Exagrid. Is there a way to create a Backup job that has as its source the files from my current backup (Nimble array in my DR site) and the target being the Exagrid? Just thinking that having two backup jobs, both with the Nimble array in production as source and with different targets (Nimble array in DR and Exagrid) would put a lot of strain on my production array

[Shestakov]

This does avoid the transformation process on the Exagrid but if I am reading this correctly, the "Read the entire restore point from source" will send a large amount of data from my source (Nimble Storage array in my DR site) to the Exagrid. The Exagrid is at my ISP across a 500Mbps connection. Wouldn't sending this amount of data across this connection be problematic? I am backing up about 5TB total.

That`s correct. Since entire new full need to be taken not from Exagrid, it should be transmitted there.

Is there a way to create a Backup job that has as its source the files from my current backup (Nimble array in my DR site) and the target being the Exagrid?

No, backup job backs up VMs, so its source are VMs. Otherwise it would do exactly what backup copy job does.
To sum everything up I would suggest to try backup + backup copy job running in a default forever incremental mode to see how much time it`s going to take.
Thanks!

[HendersonD]

Yes, it looks like it comes down to two choices:

Run a Backup job that takes it from the Nimble in Production to the Nimble in DR. I am running this job now and it takes about 45 minutes each evening. Run a Backup Copy job that takes it from the Nimble in DR to the Exagrid offsite. Backup Copy jobs by default run as forever forward incremental. On the Exagrid once the restore points exceed the retention it will do the transform on the Exagrid. Best practice for Exagrid is to not do a transform on their box but with this method there is no way to avoid it.

Run two Backup jobs
1. Nimble in Production to Nimble in DR with forever forward incremental. Might do the compaction once a month. I am running this job now and it takes about 45 minutes each evening
2. Nimble in Production to Exagrid offsite. Forever forward incremental with a periodic synthetic full. The period synthetic full will keep the Exagrid from ever doing the transform. The Exagrid box offsite has the data mover service on it so the synthetic full happens on the Exagrid which the box is well suited for.

I am leaning towards two backup jobs. One last question. Both methods are doing an incremental to the Exagrid off campus, just one does it with a Backup job and one does it with a Backup Copy job. Either way, the amount of data I am moving across my 500 Mbps connection is the same, correct?

[Shestakov]

Yes, in both cases same amount of data should be transformed, but in a case of backup copy job you can leverage WAN Accelerator.
Besides with backup copy job you don`t need to create another backup each time.
Thanks

[foggy]

The period synthetic full will keep the Exagrid from ever doing the transform. The Exagrid box offsite has the data mover service on it so the synthetic full happens on the Exagrid which the box is well suited for.

Questionable statement. In both cases all the synthetic activity (either transform or synthetic full) is performed locally on Exagrid, the difference is in amount of I/O performed daily (transform) or weekly (synthetic full). That's why, as I've mentioned above, you should check how long synthetic full will take.

[HendersonD]

We have two backup jobs

1. We have two Nimble arrays, one in our data center and one in our Disaster Recover site. They are connected with a 10 gig connection. This backup job has as its source the production array and the target is the DR array.
2. We also have an Exagrid box that is offsite with a 500Mbps connection. This backup job has as its source the production Nimble array and the target is the Exagrid

After much research, I decide not to setup this second backup job as a backup copy job to the Exagrid. When running Veeam forever forward incremental, when the number of restore points exceeds the retention, a transform happens. The oldest incremental is rolled into the full and then deleted. The Exagrid does a poor job of this transform since it would need to drag data out of the archive. To prevent the Exagrid from doing this transform, a full or synthetic backup must be run before this transform point is reached. A Backup Copy job only allows a full backup, not a synthetic full. Doing a full backup across our WAN connection would not work, not enough bandwidth. For this reason, we use a Backup job to the Exagrid. The Exagrid backup jobs have a retention of 10 days so by running a synthetic full each Saturday, the transform never takes place. This synthetic full happens directly on the Exagrid box so no data traverses the WAN.

Is my logic correct on this and my setup best practice?

[DGrinev]

Hi,

As far as I see, the scenario you've described has been set up according to the discussion with the Veeam team a year ago.
So it's logic and your understanding of the process is correct. Thanks!