Backup Copy vs Periodic Full

[Dotan]

Hello,

I apologize in advance for the lengthy question. I've been using Veeam B&R for 6 or so years by now. Currently running version 7.0.0.871 (Patch 4).

I am re-evaluating our firm's backup procedures. The ultimate goal is to have a long retention period, with minimal storage needed, at the highest possible reliability/recover-ability.

We have two NAS units onsite and we replicate nightly to a remote ESXi host. I am looking for guidance on achieving the following:
1. Save 90 daily backups on NAS1. I am thinking of using Reverse Incremental for that.
2. Economically save up to 7 years' worth of backups on NAS2.

Looking at our file server backup as an example, the VBK (reverse-incremental) is about 800GB and the daily VRB file is about 7GB.
- Can my requirement from #2 above be met by Backup Copy alone?
- If so, are those backup copies incremental backups following the initial full copy?
- If I lose one of the backup in the Backup Copy chain, can the other points past that lost file be used as a recovery point (unlike incremental backup jobs)?
- If losing a single file "breaks" the backup chain, should I opt for Periodic Full backups?

Is the following a sound plan? Please let me know if you can recommend a different approach.

1. Create a Reverse Incremental Backup job to save daily to NAS1, with a retention of 90 restore points.
2. Create a Backup Copy job that runs every 2 weeks, keeping 200 points (over 7 years if created every two weeks).

I am not sure how to utilize the GFS feature. If I check "Keep the following restore points for archival purposes", will those be kept regardless of the value in "restore points to keep" (200)? Are restore points consolidated into Monthly, Quarterly or Yearly as needed?

Can you estimate my storage needs based on the .BAK and .VRB file sizes above?

Thanks!

[dellock6]

Hi,
For local backups, I would take a look at the new forever forward incremental mode coming into V8, same space consumption as reversed incremental (one full followed by many increments as your retention) but with lower I/O impact on your storage. As per storage consumtion, space requirements is pretty easy: 800GB for the full + 89*7 GB per the increments = 1423 GB. I would then add another 800 GB for an additional full backup (you never know if you need to recreate a new chain) and some space for future growth.

For backup copy jobs, in order to keep 7 years you should definely look for GFS retention, a chain can have curruption at some point and you risk to loose a huge amount of restore points. On the other side, each restore point in GFS is a vbk file, completely indepent from the others.
Also space consumption is worse with the regular chain. Suppose for a moment you can keep a 7 years chain, with your numbers it would be something like 800GB + 2555 days of 7GB = 18685 GB, almost 17 TB. Add some periodic full has you said to avoid long chains, say one every 3 months, this is other 28 full backups over 7 years, adding 22400 GB, so the total is like 39 TB.

Say instead on GFS you want to save 8 weekly backups, 12 monthly backups and 7 yearly backups, the total would be 27 * 800 GB = 21600, 21 TB.

The whole idea of GFS is that many files and VMs are unchanged on a daily base, so in order to have a good retention you do not need to keep every single day of backup of the previous 7 years, but only few restore points saved periodically.

PS: "restore points to keep" refers only to the regular chain, not to GFS.

[Dotan]

Hi Luca,
Thank you for the detailed reply! I will implement and post back if I have follow up questions.