Synthetic Full Backups using Deduplication

[andreas2012]

Hi,

We have setup a Windows Server 2016 repository server with deduplication enabled on a Ntfs share.
I am wondering if the following statement is also true regarding Windows Server 2016 and deduplication (Synthetic Full Backups using Deduplication appliances as a Repository is not recommended) since its not a deduplication appliance.


Also the creation of Synthetic Full Backups using Deduplication appliances as a Repository is not recommended, because these kind of appliances are not optimized for read operations, and a Synthetic Full Backup requires to read the previous backup files to “synthesize” a new full backup.
Ref link : https://patriciocerda.com/veeam-active- ... =GetSocial

Thanks for reply

/Regards
Andreas

[coolsport00]

Hi Andreas -
From my understanding of ReFS, this is different. It would seem that it's actually is ok to use Synth Full with ReFS as you get a lot of ReFS benefit. See this whitepaper Rick Vanover did, as well as his blog article:
https://www.veeam.com/availability-suit ... on_wpp.pdf (may need to sign into Veeam.com to view)
https://www.veeam.com/blog/advanced-ref ... suite.html

There are also a couple other forum posts on ReFS that you may find beneficial and answer some more of your questions:
veeam-backup-replication-f2/refs-for-re ... 52512.html
veeam-backup-replication-f2/refs-kb-for ... 51231.html

Hope these help.

Regards.

[skrause]

It depends upon how you set the de-duplication schedule in Windows and when you run your synthetic fulls.

If you run a synthetic full once a week, and you set your Deduplication schedule to "files older than 8 days" I think it would not have much of an impact on synthetic operations as the file age of the chain you are synthesizing into a new full would not be in the policy. Of course, that would limit your space savings from deduplication.

If you are using 2016 and are doing a lot of Synthetic operations have you looked into using ReFS and block clone?

[foggy]

Steve is spot on, it depends. Generally the quote is applicable to Windows Deduplication as well, but with proper settings you can eliminate the consequences. Here's another existing thread that might be useful.

[FedericoV]

Hi Andreas,
I want to clarify a very common misunderstanding regarding Synthetic full with Deduplication appliances.
The problem described by "patriciocerda.com" occurs only If we use a dedupe appliance as a NAS share.
Since 9.0, Veeam has implemented a great integration with some deduplication appliances to avoid that problem.
I cannot talk for every PBBA, but at least for StoreOnce (that I know well because I work for HPE) the process works differently. The only requirement is to create the Backup Repository based on Catalyst rather than CIFS. Catalyst is a communication protocol over IP or FC that does not only make source side deduplication, but it also enable a richer communication between Veeam and StoreOnce. At this point, as usual, we just check the Synthetic Full on the job GUI and Veeam will make a "Virtual" Synthetic full backup instead of a "Traditional" Synthetic Full.
Process steps:

• [1] Veeam makes the usual Incremental backup. (for a short time we may find a temporary .VIB in the repository)

• [2] Once the Incremental is completed, instead of making the traditional "Read and Merge" process, Veeam sends to StoreOnce the instructions for building the next Full and then it holds on until StoreOnce completes the task.

• [3] For StoreOnce the process is light because all the data it needs to create the next Full is already there (usually 1 .VBK and 6 VIBs) and thus the new Full does not contain new data, but only pointers to existing blocks. In other words, to create the new .VBK, StoreOnce does not move data blocks, but it only re-aggregate pointers to existing data blocks, and this is faster.

• [4] Once Veeam receive the notification that the new .VBK is ready, it deletes the temporary .VIB created on step one, and puts the new Full .VBK in its catalog.