move Optimal compressed backup files to dedupe appliance

[jveerd1]

We are in the proces of targeting and moving some backup copy jobs to a new deduplication appliance. The backup copy jobs have a retention policy of 13 weekly (copy every 7 days) incremental restore points and 4 quarterly full backup files. The source backup job has the Optimal compression setting, the backup copy job has the Auto (thus Optimal) compression setting.

We would like to get the best possible dedupe rate on the full backup files in the backup copy job. To do that, we need a way to decompress the full backup files before storing them on the deduplication appliance. Besides that, it would be nice if we could do item-level recoveries on the backup files, but this is not a requirement.

Possible ways to achieve our goal:
-use the Extract Utility and save the virtual machine files on the new deduplication appliance
-use Instant Recovery to mount the Optimal compressed full backup file one by one and run a backup job on that Instant Recovered VM targeting the new deduplication appliance
-....???

We could use some out of the box thinking to achieve our goal. Is there somebody in the forums who has a better (more efficient) way of decompressing and moving the full backup files?

[foggy]

Joeri, I'd suggest to re-point the job to another repository and change compression settings to get the best dedupe rate for all subsequent full backups. As for existing backup files (in case you do no want to copy them to the dedupe device in a compressed format), you can either leave them where they currently are, until the new chain reaches required retention, or restore/backup them with the required settings, as you've mentioned (again, you'd need to handle their retention manually, since they will not be a part of the backup copy job chain anymore).

[jveerd1]

Alexander, we have tested the restore/backup scenario, because we need to decompress as much of the backup copy chain as possible to raise the dedupe ratio. We cannot leave the complete chain on the current storage device. The scenario works, but as you wrote we have to take care of the retention policy manually. But that's not a big deal to us.

Since the restore/backup scenario to decompress the backup files is only using Veeam components, it might be fairly easy for your developers to create a Decompress Utility. Would be nice if they could figure out a way to retain the retention policy.

We are still looking for new (better) ideas how to decompress backup copy files. If anybody has figured out a nice solution, please post.

[mongie]

I've only recently realised that there is a "decompress before storing" option for repositories. Unfortunately, while it would help going forward, its not going to help with your legacy backups.

-- My feature request --
Allow backup copy jobs to process an existing backup chain, processing the historical backups and using the GFS settings to build out retention from day one.