I have used it. My experience is that it works well. You have 1 hit on the initial full backup, but after that the synthetic fulls are quick as they synthesize the other incrementals to create your new full synthetic backup.
Is there anything specific you wish to know?
To add to revaroo's post, we also use it 99.9% for what few clients we have left in our infrastructure.
A few additional points:
- you may want to schedule a few 'normal' fulls (there have been recommendations in the past to do this on the forum), just in case there are issues with the synthetics (we sometimes had issues with the building of the synthetic & the only recourse was to carry out a normal full)
- the synthetic is based on the time of the last incremental 'normal' backup, so if you want an up-to-date synthetic , ensure you do this incremental just before your synthetic (we had incrementals Sun-Fri & synthetic Sat before a 'light-bulb' moment that we were actually missing a days backups!)
Hi Revaroo, Hi Andy
Thanks for the feedback !
At the moment I'm testing the synthetics als a replament of NBU accelerator, which is not usable in big environments, because the logging ist hardcoded. A little change, f.e. of the storage server, forces a new full backup without accelerator. So thats why, we took it out of the production. It is giving to much work and checks for the operating. Also little things, like the client is booting during the backup, is causing problems.
With the synthetic-method I was running now in the problem "status 671 (query for list of component images failed)". It was because a weekly-backup was failing and the inc-images were expired. We keep the incs at the moment one week, until the full is done. So that means, we shall increase the retention for the inc's to 2 weeks, which is again blowing up our managed data - at the moment we are on 15 PB, even we are using since years datadedup.
So I'm douting also, to set this method in production ? The restriction - see manual - that AIR is not supported, would be a killer for the synthetics, because we are planing to use AIR.
I'm testing synthetic backups as a replacment of the nbu accelerator, because it is not usable in big environments. A little change, f.e. of the storage-server, forces a new full backup, without accelertor, because the loggin is hardcoded. The tool is giving tool much checking and work for the operating, thats why we took it out of the production.
With the synthetics. I was running now in the problem: status 671 (query for list of component images failed). The reason was, that a full was not running at the weekend and the inc's were already expired. we keep the incs at the moment for 1 week until the full is done. To avoid this problem, we should increase the retention of the incs to 2 weeks. But this would again increase our managed data, which ist at the moment at 15 PB, even we are using since years datadedup from symantec.
I'm douting to use this method in the production.
Yes the incrementals must not be expired. The Synthetic full is generated from each incremental which daisy-chains back to the last full. Any images missing and the Synthetic full backup will fail with a 671.