7 year data retention

[MGSPP]

Hi Guys,

The business I work for has given the requirement to backup our file server with a 7 year retention for accessing client files (stored on windows shares); I was hoping someone could provide valuable insight on how Veeam Backup and Replication 8.0 can efficiently and effectively achieve this task.

Background on our current configuration;

1. We have a total of 14 VMs (only 1 of them is a file server)
2. In total the backup size is 2.2TB
3. Backups are saved via iSCSI to an AWS Storage appliance running on VMware - and snapshots are created and replicated to S3 for off-site storage.
4. Datastore for the AWS volume is a local NAS, so we have instant/low latency access to the backup sets.
5. Restore points to keep on disk are set to 14
6. Schedule is to run the backup automatically everyday at 7:30PM

To add to the above, and as mentioned before - we have a requirement to retain (archive) files on the file server (approx 1TB in size) for 7 years.

What would be the best way to configure either a backup/copy job to achieve this task? The backup copy terminology is a tad confusing - would love to hear wha you guys have mustered up in your environment!

[PTide]

Hi,

With version 8 you can use our GFS retention policy in order to keep long term backups (weekly/montly/yearly). Backup copy job does not just copy files but copies only changed blocks thereby reducing the amount of data transferred and increasing speed and reliability. On the other hand it might be more convenient to use tapes for large backup files if you want to keep them for 7 years. We have a GFS for Tapes feature coming in v9.

How many restore points do you want to keep? Please describe your RPO.

Thank you.

[MGSPP]

Hi PTide thanks for the reply,

The requirement is as follows;

1. Retention period 7 years
2. Monthly intervals (84 months)

I'll be utilising AWS VTL to achieve the above.

Although - I need some guidance around how to configure Veeam to effectively and effectively implement the above requirements in the backup copy job.

Current plan was just to do 84 full monthly backups.

[Gostev]

It's very straightforward really, you just create a Backup Copy job, include the required VMs, and set 84 in Weekly backups in the job's schedule. Thanks!

[MGSPP]

Im assuming you meant 84 in months?

Also, wouldn't that do a full backup every month? so we'd have 84 full backups (and say the size of the backup set is 1tb, that would be 84TB by the end of 7 years)

[PTide]

Im assuming you meant 84 in months?

Yes, it should be "Month".

Also, wouldn't that do a full backup every month?

That would create a full backup .vbk file every month, correct. Once a month your backup copy job will synthesize a .vbk, set it aside, and mark it as a monthly backup. There is no way how you could keep monthly full backups for 7 years without having much space consumed. However, you might want to setup a copy job with an interval of 30 days and set it to keep 84 restore points. That would provide you with 1 Full + 83 incremental backups that take lesser space. The drawback of such approach is that you'll have to do a couple of tricks with PowerShell scripting in order to configure montlhy schedule without GFS option enabled. Otherwise you'll get your backups once in 30 days, not once a month. Also if you choose to have a forever incremental backup copy chain then if any of your incrementals get corrupted the whole chain will be rendered useless. Finally, I don't think that monthly incremental will be much smaller than full.

[Gostev]

Yes, sorry I mistyped.

so we'd have 84 full backups (and say the size of the backup set is 1tb, that would be 84TB by the end of 7 years)

Correct. Note that it's generally a bad idea to use disk for such a long term retention. Not just for costs reason (both upfront, and continuous for electricity and cooling), but also for reliability reasons (7 years is too much for spinning disks). This is why for long term archiving, you can't really beat tape.

[MGSPP]

Understood, fortunately we'll be utilising AWS VTL to achieve this instead of just storing on tape.

All the information here was much appreciated!

[veremin]

If you're willing to stick to Amazon VTL Gateway, wait till VB&R v9 is released as it brings support to for unknown media changer (required for proper VTL work). Thanks.

[readie]

For what it's worth, this is what we do to enable long term 'archiving'. Like you, we were put off by the thought of too many full backups of our two 3 TB each Fileservers.
Apart from daily backups and replicas that we keep for 7 restore points, we have three other jobs.
Fortnightly Backup Copy - keep 7 restore points - about 3 months back.
Quarterly (actually 100 days, as that is the maximum in the drop-down) Backup Copy - keep 3 restore points - about 8 or 9 months.
Annual - backup copy to USB HDs which are then locked away in a fireproof safe. Offline, but easily accessible if required. We now have two sets of these (haven't been doing it very long) so can go back over two years if required.
The fortnightly and quarterly are incremental, so about 6 or 7 TB each, for our two fileservers.

[netecs]

We have been doing something similar by keeping yearly backups, but only storing 6 weeks of data on disk. Essentially, we archive the job folder once a month via a different backup solution. We exclude the .vib files so we only grab the fulls. The second backup solution can write the data wherever you want with a different retention. To restore, simply write it back to a different folder and import it to Veeam.
Keep in mind that usually when 7 year backups are required, you only need to back them up. The dependency to actually restore the data is not necessarily dependent on you. So keeping 'live' copies of the data is wasteful and worth investigating.

[veremin]

@ Netecs

I'm just wondering why backup copy job with GFS retention policy didn't meet your requirements. Was there a specific reason or something?

Thanks.

[netecs]

v.Eremin,

Our other backup solution has longevity and owns the tape drives. This solution allows us to have a copy in an alternate medium and offsite backups.

Cheers, David

[veremin]

I got the idea of other solution managing the offsite copies of your backups. I was just wondering whether it provides some specific functionality that is missing in backup copy jobs; more like your feedback (if you have any) regarding potential enhancements of backup copy job functionality. Thanks.