Syntehtic Backup Incremental Cannot use DeDuplicated Storage

[Peteski]

I'm just beggining to use dedupe in testing on BUE2014 and I've not really used it prior.

Basic testing of a Full+Incremental job to dedupe storage shows that both can use the same storage device without issue.

When I create a new synthetic backup, it allows me to select the dedupe storage device only for the full and synthetic full backups but not the incremental.

Why the difference? What is different about the synthetic that it's incremental cannot write to the same storage?

Thanks

Pete

[pkh]

This is a requirement of synthetic backups. The incremental backups must be on disk storage. See page 1168 of the Admin Guide. The dedup folder emulate a tape library.

[Colin_Weaver]

To be honest as one of the restore views where you select what to restore is point in time you don't need to run Synthetics as a restore from the point in time selections will re-assemble the media in the correct order within one job and in dedup storage everything is stored in one place so always online.

Basically just do standard full and incrementals into the dedup and use the point in time restore view to select from and the restore will work like a synthetic even though it is accessing multiple media behind the scenes.

This view works with all backup storage locations, BUT for tapes or removable storage that are not online you will see media insert requests. As long as eveything is online Backup Exec will just use it.

By all means test it - use a test folder with 1 file in

Create a full and incremental backup (in one definition) to deduplication with Synthetic disabled where the selection list is just that test folder.

Run the full

Put a second file into the folder and run the incremental

Then go and look at your point int time restore selections (note for BE 15 and later there is an obvious point in time wizard that will take you to the selections, I am not sure if we introduced this wizard for BE 2014 or if the default view is this pseudo synthetic view) if you see both files in one view then try a restore with both files selected to prove that both files are pulled back by one restore job.

[Peteski]

@pkh I knew that incrementals required disk based storage, I was just wondering why the synthetic wouldn't allow the compnent full and incremental to share the same disk but a regular full and incremental backup can share the same disk.

@Colin Weaver- thanks for pointing out the point-in-time functionality exists in the restore which obviates the need to run a synthetic full. It doesn't quite answer my question so much as moot it but that's good enough. I'll just skip the synthetic and use the point-in-time restore as it works as you said in BUE 2014. I restored a 64GB directory just fine with it as a test and it worked perfectly. Thanks!

[pkh · Accepted solution]

If you are using a disk storage, instead of a dedup folder, then the full and incrementals can be on the same disk storage.  In fact, this is the recommended configuration.

Note that the synthetic view that Colin described earlier is not the same as what you get when you do a true image backup which allows you do to synthetic backups.  When you do a restore from a true image backup, deleted files are not restored, whereas restoring from the synthetic view will restore deleted files because it is the traditional restore.

[Peteski]

@PKH thanks for the clarification on the true image backup. I read up on it and, yes, in BUE 2014 it appears that only synthetic incrementals would allow a point in time recovery where the deleted files stay deleted and moved files get backed up so they can be put back right where they should be. It's an important distinction such that I wish I could get my synthetic incrementals to the same dedup storage as now it appears I'll have to add yet more storage for them.