Very long term retention for Backup Copy jobs

[hoffmp]

One of my clients has been served with a “stop destruct” legal order as part of a patent dispute. They have interpreted this to mean that they must never discard a nightly backup. Grandparent/Parent/Child archiving is not sufficient – they want to keep every single one.

In order to make this as affordable as possible for them, I’m using Veeam Backup and Replication’s “Backup Copy” job to push the nightly incrementals to Amazon Cloud Storage via Amazon’s Storage Gateway virtual appliance. The Veeam proxy server sees this as an iSCSI attached volume (Z: in this case). The proxy server treats this as it would any other repository, and the Storage Gateway Appliance does all of the heavy lifting and caching to/from to the Amazon cloud. I’m actually impressed with how easy it was to set up and configure.

So far so good. But I’m becoming concerned about how far I can push this design. My plan was to switch out the underlying Amazon storage volume (behind the Gateway Appliance) with new ones at regular intervals, thereby keeping the content indefinitely. At worst, each volume change will generate another VBK (I’m assuming) and then continue on writing VIB files.

The key question is: “How frequently should I be performing these volume switch-outs?” is the key question, recognizing that there’s probably a balance between efficiency and reliability lurking out there somewhere. Once a year would be ideal, but that seems overly optimistic to me. Once a month would be ok, but I’d rather go longer than that if possible. At what point does the sheer number of VIB files dependent upon an underlying VBK file become a bad practice from a reliability/stability point of view? What else should I be watching for as this ramps up?

Thanks very much in advance for any assistance you can provide.

[dellock6]

Hi, I think this setup allows first of all to avoid the biggest problem with such design, which is the transform occurring when the retention period is reached,so it may work...

For the rotation, with the new options in v9 (you don't say which version is in use...) like corruption guard and health checks, I believe a chain can be extended even more than before, but I would also check how much time does it take to do an active full once you switch to a new bucket, both in terms of time and price in aws.

[hoffmp]

Thanks. We're currently running v8 (although I've been pushing for v9 - no technical impediments, just getting the approvals needed in this environment)

The largest of the servers is < 2 TB of disk space, so even writing the full backup when the media rotates shouldn't be terrible