Backup Copy and NFS dedupe design

[luckyinfil]

I've been digging into the documentation in order to come up with a backup copy design for long term retention.

From the documentation, the "Restore points to keep" is a backup chain (is it reverse or forward incremental) to meet the desired retention settings:

The backup copy job constantly transforms the full backup file in the backup chain to meet the desired retention policy settings. The transformation process, however, has a side effect. In the long run, the full backup file grows large and gets badly fragmented. The file data occurs to be written to non-contiguous clusters on the storage, which slows down reading from and writing to the backup file.

That means, if I have 7 daily retention points (assuming the backup job is run daily), I will have a total of 6 VIB files and 1 VBK file. on the 8th day forward, one of these VIB files will be merged into the VBK and a new VIB file will be created, thus known as the "transformation of the chain".

On any VTL/dedupe appliance, this results in significant I/O onto the storage due to the read and writes. In my case, I'm expecting these transformations to not even finish due to how much data we are backing up.

Is there a way to avoid this transformation on the dedupe appliance? Is it possible to have the dailys on an alternate target backup copy repository than the weekly, monthlies, etc?

What is the recommended approach if I wanted to create back ups of 30 dailies, 84 monthlies, etc. ? If you're going to recommend backup copy jobs, then please consider the impact of the transformations into full VBKs on dedupe appliances.

[veremin]

Is there a way to avoid this transformation on the dedupe appliance? Is it possible to have the dailys on an alternate target backup copy repository than the weekly, monthlies, etc?

Nope, as that's the way GFS mechanism works. If this doesn't work for you, you can copy full backup file via copying tool on whatever basis you want to (weekly, monthly, etc.). Thanks.

[tsightler]

Well, it's really based on the dedupe appliance. With Exagrid will probably work OK because of the landing zone concept. With Data Domain, v8 should address this with DDboost support which offloads transforms to the appliance and eliminates the bulk of to rehydration penalty.

With other dedupe appliances, it can be a bigger challenge. The best option I've been able to come up is some creative Powershell if you're interested in hearing more about that let me know.

[luckyinfil]

another post of the issue i'm mentioning:

http://forums.veeam.com/veeam-backup-re ... 0transform

[luckyinfil]

Nope, as that's the way GFS mechanism works. If this doesn't work for you, you can copy full backup file via copying tool on whatever basis you want to (weekly, monthly, etc.). Thanks.

That's a pretty crappy alternative. When you advertise that Veeam works with all sorts of dedupe appliances such as Datadomain (which will only work if you have DDboost) and HP Storeonce (there's even a whitepaper out but it won't work due to the transform issue), it really gives a false impression of the capabilities of veeam.