Synthetic Backups 2

[markey164]

Is anyone using these?

I'm looking into implementing these. From reading the documentation, I'm happy with the concept of how it works, but what isn't clear is how often you should do a *REAL* full backup?

In theory you could do sythetic backups forever more and never touch the box with a resource intensive full backup ever again?

But what is the recommended approach here and why?

 

[jjjon]

Markey, not sure what the Commvault recommendation is, but we use Synth Backups for Exchange Mailbox - upon implementaion we ran a full 'real' backup and then ran Incr and Synth from then on in. We did have a problem at one stage with Indexing that required a re-run of the 'real' full, but in theory I don't see why you would need/want to run the 'real' if everything is running fine as Incr/Synth.

J

 

[markey164]

Thanks jjjon. I'm seeing this as something that sounds beneficial to do as an ongoing thing, but I'm just trying to figure out what the drawbacks of it are...if any.

Maybe it just seems to good to be true.

The commvault documentation gives a couple of examples where a real full back is run on a monthly cycle, but as a synthetic is treated by Commvault as being a real full backup, i dont see why you need to do them at all.

i think i'll stick a ticket into Commvault and see what they say from an official standpoint. I'll report the findings back here )

 

[markey164]

Here's another question on this.

The documentation says that it combines the previous full and incremental backups into a single archive for efficiency and faster restores...nice.

But what happens if i need to recover a single file from that full backup? Does it have to recover the whole archive to recover the single file?

 

[theravager]

Synthetic Fulls work fine and you can pretty much use them for ever. There are only a few things that can break them and its usually some sort of corruption of your data and a real full would be needed to run.

Make sure on the intial full that no files are skipped is about the only thing to be aware of.

A Synthetic full is the exact same as a real full, just the unchanged files are sources from the previous full or synt full instead of the source server. This work particularly well across slow WAN links with only the delta traffic crossing the link.

We use these to backup a few hundred remote servers with very small WAN links, you can prestage the data into commvault via a usb drive for the intial full.

 

[MostlyNuts]

Be sure to check the catalog requirements as this can impact the space needed in some SF cases. Consider the metatdata needed to track all file movement and filesystem restructuring.
Other thatn this SF is a great way to save on bandwidth and media costs.
~MN

 

[cabraun]

I do synthetics on 3 servers. 2 are across slow WAN links and 1 is in the same data center as all my CV stuff, but hosts about 300GB/20 million image files for archival. A regular full backup of that server will take 3 full days easy. An incremental now takes about 20 minutes each night and the weekly synthetic full takes about 3.5 hours. I have had to do restores of single and multiple files/folders in the past and have not run into any problems. The last regular full backup that I ran was at least 2 years ago on that box.

 

[markey164]

Another question on this, let's assume i go to a regime of synthetic fulls and incrementals, and do away with 'real' fulls completely.

Now let's assume that over the course of the next few months, large amounts of data are cleared out and deleted.

Normally a full backup would take account of this, however a synthetic full backup won't as it doesn't touch the client. Obviously incrementals are only backing up new files, not removing old ones.

So how does Commvault handle this issue of synthetic backups and deleted files?

 

[CraigMcGill]

> So how does Commvault handle this issue of synthetic backups and deleted files?

I was about to post the same question! If files are deleted from the source server, presumably the synthetic full will never know about this? So a synthetic full will always include files that could have been deleted weeks/months/years ago and the only way to account for them is to run a real full backup no? A synthetic full can therefore only ever get bigger right?

 

[markey164]

Looking at the commvault documentation, below:

http://documentation.commvault.com/...ine_1/english_us/features/backup/syn_full.htm

...the only bit which comes close to the issue of file discrepancies, is the 'verify synthetic full backup' option which states:

"In a scenario where a conventional full backup is run only once for a given subclient, and incrementals (or differentials) with periodic synthetic full backups are run after that, files that never change may inadvertently be missed. Eventually, these files may be pruned, leaving no existing backups of the files. The problem of omissions may build up over time until the file changes or a conventional backup is executed. This can be avoided by using the Verify Synthetic Full advanced backup option.

When this option is selected, disparities between actual files on the client computer and the Index are collected. Internally, a flag is set when the synthetic full backup completes successfully. This flag adds functionality to the next incremental/differential backup to detect any items that the previous synthetic full backup did not include, and include any such items in that incremental/differential backup. The pending flag is cleared when the incremental/differential backup completes successfully, or when a conventional full backup completes, whichever occurs first"

However, there is no mention of 'deleted' files in the points above. It only seems to refer to files that may have been missed/skipped between backups (perhaps because they were in use etc)

I guess it's possible the 'verify synthetic full' option DOES index deleted files, and perhaps remove them when it builds a new synthetic full, although this certainly isn't clear from the documentation.

Anyone know the answer to this?

 

[markey164]

I got a rather non sensical answer back from our consulants on this topic, so i decided to do some testing on this, and think i've figured this out.

It appears that Commvault incrementals DO acknowledge *deleted* files as well as new and changed files.

I tested this at a simple level with a folder with 2 files in it, and did the following

* Ran a normal full backup on this folder (backed up 2 files)
* Deleted one file
* Ran an incremental backup
* Deleted the test folder
* Restored the test folder from latest data.

Now i thought that both files would be restored, but only 1 was. Therefore the incremental backup ALSO appears to index and identify deleted files, which is cleverer than a traditional incremental as i understood it.

I also repeated the above with a synthetic full test, and of course it worked correctly.

So the above observations, together with verify synthetic full option, looks like a definite way forward now )