Schedule for active full backups in VBR 9.0.0.1491

[Didi7]

Hello,

on Friday evenings at 10:00pm, we usually start the first B2D jobs with several VM's, that need backup times far beyond midnight. We marked Friday as the day, when Active Full Backups should take place. All those VMs in the B2D job, which start at 10:00pm will do an 'Active Full' according to the history. In another B2D job with other VM's which starts as soon as the first B2D job (which starts at 10:00pm) finishes, the day Friday is also marked as the day, when 'Active Full' jobs should take place, but as those jobs mostly start past midnight, history tells me, those jobs are only 'Incremental'.

So I suppose, to be sure that an Active Full job also takes place for B2D jobs, which instantly start after other B2D jobs, I need to select Friday and Saturday (and maybe Sunday).

I should further mention, that we backup all our VM's from Monday to Thursday (Incremental) and on Friday (with an Active Full Backup).

We also like to seperate all VMs to many different B2D jobs and concatenate them with the schedule option 'After this job', to make sure, that *.vbk files don't get too big, specially because of tape restore reasons.

Regards,
Didi7

[nielsengelen]

It is best to prevent "run after" as this is what can happen.

Best would be to configure both jobs to start at the same time. Wwe have builtin logic to take care of the processing.
However spreading active full on friday for job 1 and saturday for job 2 is advised to lower impact on the production.

You could also look at syntethic full instead of an active full every week.

In regards to the copy to tape: you can enable "per vm chains" on the repositories which will store every VM in their own chain (full and incr). You will have to run an active full to make this change effective.

[Didi7]

Hello vmniels,

thanks for your advice. I remember I read about 'per vm chains' here ...

http://www.virtualtothecore.com/en/veea ... up-chains/

... a few months ago, but never thought about using them!

Now I know, it was a mistake

Synthetic backup is a no go for us, since the problems with CBT.

Regards,
Didi7

[nielsengelen]

Which problems regards CBT you talking about? The incrementals you are making are also based on CBT.

[Didi7]

The incrementals you are making are also based on CBT.

Exactly and since the first reports about CBT-bugs in 2014, I finally decided to make Active Full Backups every weekend, when I launched the first VBR server intro production. And since CBT bugs have a long tradition into vSphere 6 and into 2016 as well, imo it is still a good idea to have regular full backups, which don't rely on CBT-bugs

Personally I think, VMware produced a nightmare for supporters of big datacenter environments, which probably could have configured reverse incremental or forward incremental jobs without having active full backups for months or years. Who really tracked, what partition was resized from under 128GB to over 128GB for so many different VMs. I didnt't track that info.

So, when I launched the first VBR 8.x server, I also reseted CBT for every VM, which had partitions beyond 128GB.

Regards,
Didi7

[nielsengelen]

I understand the concern however do take a look at http://www.virtualtothecore.com/en/imag ... thout-cbt/ - an article from a Veeam employee which is a nice example of how Veeam can still backup fast without CBT.

[Didi7]

Yes, I read this article a while ago

Regards,
Didi7