Finding balance on synthetic full frequency...

[sketchy]

I'm curious to know what other's have settled on for frequency of their synthetic fulls. Is once a week working for you? ...Or are your synthetics taking too long for that period of time. And if so, are you increasing or decreasing the frequency.

They can certainly be a challenge in high change rate environments, so I was just curious to know what others were doing.

[dellock6]

Hi Pete,
I've never played too much with synthetic fulls in production environments, so my reply is more based on common sense.
If a weekly synthetic is taking too long, a longer rotation is only going to be worse, sinc it will then have to process a larger amount of daily incrementals.

Sure, a possible solution sounds like shortening the frequency of the synthetic creation, but one problem you are going to face by doing this is your synthetic will happen in the middle of the week. On the backup target, so not a danger for production storage, but still a problem if you need a quick restore while synthetic is still running.
I would also check the daily change, it can happens sometimes VMs with a high change rate can be better protected with an active full, since there are so many blocks to be saved everyday that an active is quicker than the synthetic creation. You can maybe split the backups of those VMs and still using synthetic for low I/O VMs.

Just an idea to look for.

Luca.

[sketchy]

Good points Luca. I was already toying with ditching the current approach on the high change rate VMs. Yeah, an increasing of the chain was an obvious concern, but I was also thinking it *might* reduce some overhead in the processing of it all. I have two use cases to address that is not all that uncommon in a Software Development shop.

1.) Build/Compile Windows and Linux VMs doing tons of builds 24x7. local sandboxes and binaries being written is usually a different drive/partition (aka "scratch" partition), and is not as important. Shooting for primary VM itself backed up daily, and the scratch partition being backed up once per week.

2.) VMs serving up large flat file storage locations for some of these Development workflows. Some of them are where the binaries are shipped to, so also a high change rate, and very large. Others are not so high. These systems need to have the systems and the data backed up at the same frequency, typically no less than once a day.

Realizing that Veeam will allow for backing up the system in various ways, I'm also shooting for the most convenient approach for a point in time recovery (not pulling from multiple backups to assemble a recovery of a system). I'm targeting an approach that meets the requirements, but is somewhat elegant and simple as well.

[dellock6]

Uhm, at least for point 1 a viable solution can be to only backup the OS disk and exclude the scratch partition.You can then have two solutions to backup the scratch partition less frequently:
- a second job saving the save VM weekly, but with all disks (disadvantage is that it's going to have a high change rate, maybe a full is the best choice)
- redirect all mounted scratch partition into a file server, and only backup that file server (disadvantage is a more complex restore procedure)

Luca.

[sketchy]

Yes, I currently exclude that scratch partition from the backups, and the idea of a 2nd job for the full backups is the most realistic approach. The scratch partition for each code compiler really needs to be local storage in relation to the code compiling VM, otherwise there is just too much of a hit across the wire. Thanks for your input, and I'll keep you posted on what I find.

[dellock6]

No problem, glad to help.
By any chance are you vmpete on twitter?

[sketchy]

I'll be sure to keep you posted Luca. Perhaps some good blogpost material too. (Yep, I'm vmPete. Good to cross paths in yet another way.)