One of the features of Veeam Backup and Replication is the ability to not only perform an incremental backup job to local disk but then schedule a job to copy those increments to another location.
These backup copy jobs are forever forward incremental meaning that after the first full backup is created only incremental data from that point forward are copied. Once the incremental chain hits the set limit of restore points, after any new restore points is copied, the oldest restore point is automatically synthetically merged into the full backup file.
The default number of incremental restore points is 7 but this number can be increased. However, the longer the incremental chain is, the more data will be lost if the incremental chain is broken due to corrupt restore points.
Managecast increases this to 14 daily incrementals by default so that 2 weeks of daily increments are ready for restore.
For longer retention, Veeam recommends using a backup copy jobs built in GFS retention to keep X number of weekly, monthly, quarterly, and yearly full generations of the backup files.
This means that the backup copy job will create a copy of the most recent full backup file and archive it according to the retention policy. Because these GFS restore points are individual full backup files they do not rely the incremental change and will not be lost if the incremental chain is broken.
Unfortunately, this method can utilize a large amount of storage very quickly especially when it comes to long term retention. For example, if a backup copy job is set to keep 7 incremental restore points, 4 weekly, and 12 monthly backups it would need enough storage for the 7 incrementals, the current full backup file as well as 15 additional full backup files.
A useful tool to figure out how much storage is needed is this restore point simulator.
One option to cut down on the amount of storage used is to use deduplication on the target backup repository. Because the GFS restore points, or full backup copies, are copies of the same backup files they deduplicate extremely well.
Keep in mind that if the current full backup file is deduplicated it will severely slow down the process of merging the oldest incremental restore point and the current full backup file. To get around this Managecast only deduplicates files older than a 7 days. Meaning that the GFS restore points are only deduplicated a week after they are copied from the current full.
This way the backup repository is storing the daily incrementals, the current full backup file, and all of the deduplicated GFS full restore points. This takes up a little more than 2 times the full backup size plus the size of the incrementals.
Another important thing to note is that Deduplication will not work on the backup files if they are encrypted. Because encryption is changing the individual files, deduplication would no longer see the different backup files as similar data and would not deduplicate that data.
Depending on how much storage the backups take up this means that there needs to be a choice between either encrypting the backup files and a high cost long term retention policy, or keeping the long retention policy and being able to deduplicate the full backup files.
Summary: VEEAM is a great product, but for long-term retention requirements it can really explode the size of backup storage required. Managecast will be reviewing the new VEEAM v9.5 in combination with Windows 2016 and the advanced ReFS file system to see if new de-duplication efficiency (with combined encryption) will help solve these issues. Stay tuned!
Update: Check out our post on Veeam 9.5 ReFS Integration for longer term retention!
Interested in learning how Managecast can help your business with its cloud backup and disaster recovery solutions? Fill out this form for more information!