One of the first features added to Veeam Backup & Replication was backup copy jobs, and with backup copy jobs, we added GFS. GFS stands for Grandfather, Father, Son. It is the term used for archival retention points originally in just backup copy jobs, but now it’s available in traditional backup jobs in more recent versions. These archival points allow customers to save a point-in-time full copies of their data in intervals of weeks, months, quarters and years. There are many reasons for these archival points, like keeping track of configuration changes and data retention compliance. Starting in Veeam Backup & Replication v11, there will be some changes to how GFS is handled in backup copy jobs and some new best practice configurations.
How backup copy GFS retention worked before V11
First, let’s look at how GFS in backup copy jobs work in versions before V11. Understanding how GFS works in previous versions of Veeam Backup & Replication will help clarify how to prepare for the update. When creating a backup copy job, there would be a forever forward incremental chain based on the configured retention policy. This chain would consist of one full backup point with a series of incrementals in front of it. This chain looks much like Ms. Pac-Man eating a never-ending chain of dots or incrementals. Each time the chain moved forward, the oldest incremental was merged into the full backup point. When GFS was enabled, during the job run day, which was supposed to be a GFS point, the backup file would be marked to save that point in time. The backup point in this scenario would be an incremental, but when the full backup point within the forever forward incremental chain reached this marked point, it would leave behind a full backup copy point. The downfalls to this method are that the retention policy would be applied based on the amount of backup points in the chain, not the age of these points. It also could delay the ability to offload GFS points tiered to cloud object storage. Finally, this required modifying the full backup files in place after they have been created, which prevents using WORM (Write Once Read Many) backup storage in principle.
What we changed in V11 (and why)
As you already know, V11 comes with a whole slew of game-changing new features. But it was almost a joke to see how the current backup copy job restore-point based retention and its full backup merges are not compatible with any of them:
- Immutable backups on Hardened Repository: not only did these require time-based GFS retention to correctly set the WORM unlock time, but they obviously cannot support backup file merges (because once the backup file is created, it is immutable).
- Immutable backup on SOBR Archive Tier: these, again, require time-based GFS retention to correctly set WORM unlock time.
- Background GFS retention: this too requires time-based GFS retention to ensure the retention can be processed correctly and independently of backup or backup copy job runs
The only workable solution for us was to make the backup copy GFS retention use the same approach as the primary backup job GFS retention, which unfortunately also meant some feature loss like quarterly backups, which were never available for primary job GFS in the first place. And while this is arguably one of the most disruptive changes we ever did in the product, you can probably see how we were forced to do it “for the greater good” while also considering that some feature loss can always be addressed later based on your feedback. Innovate and iterate! By the way, even if you don’t care about those new features (or at least not enough to cover the cons of this change), keep in mind, the new approach does have a number of less obvious benefits too:
- It is now impossible to fail the retention policy due to accidently creating an extra GFS restore point, because each GFS restore point is removed strictly based on its age.
- Dramatically improved reliability and performance without in-place backup file modifications.
- Much less bug-prone logic compared to restore point count-based retention. We never saw corner cases with nasty bugs stop coming even after many years with this feature…
How backup copy retention works in V11
At first, let me just start by saying that if you know how primary backup job GFS retention works in V10, then you already know everything about how backup copy job GFS works in V11, and you don’t really need read further — unless you want a recap.
In V11, the forever forward chain of backup copy job is replaced by a regular forward incremental chain based on the GFS configuration. The classic forward incremental chain means a full point will be created exactly on the days scheduled for GFS, with incremental points that proceed on the following days, with no daily merges within the chain. For this reason, it is highly recommended to have weekly GFS points scheduled to avoid long chains between synthetic full points, because this may significantly increase disk space usage by incremental restore points due to how classic incremental chains retention works: we cannot delete the entire chain until the last increment in chain is still under retention, because it is only usable with all previous backups in its chain starting from full backup.
Next, as noted above, due to re-using primary backup job GFS logic, backup copy GFS schedules will loose the quarterly option for backup points, leaving weekly, monthly and yearly.
This change will increase the number of monthly full backup points kept on the repository to simulate a quarterly backup cycle with monthly backups. However, this space requirement can be alleviated by leveraging other Veeam technologies; such as fast cloning on ReFS and XFS-based repositories, deduplication storage integrations, or by offloading backups to object storage — which we also do in a forever-incremental manner.
V10 to V11 retention settings checklist for existing customers
These changes will take immediate effect after upgrading to Veeam Backup & Replication v11, so it is recommended to look at all the configured backup copy jobs before updating. If GFS is configured on the backup copy job, make sure that weeklys are also configured to avoid long incremental backup chains between monthly fulls. If there are quarterly backups configured, the upgrade will convert those to three monthly backups for each quarterly and add that to the existing total of monthly GFS points. For example, if a job is currently configured with 1 yearly, 3 quarterly, 3 monthly and 4 weekly, the new GFS schedule will be 1 yearly, 9 monthly and 4 weekly after the upgrade. It is recommended to make these changes before the upgrade if possible, but it will not stop the upgrade from completing. Once the update is complete, it’s recommended to go back into the backup copy jobs to ensure that the new GFS retention settings are correct.
Conclusion
In Veeam Backup & Replication v11, backup copy GFS retention was changed to match primary backup job GFS retention to enable support for many new V11 features requiring time-based GFS retention. Existing customers should look at their backup copy jobs prior to upgrading to ensure the retention changes will not affect company retention policy or increase backup repository consumption due to extra monthly full backups converted from quarterly. But once you’re through this tough transition, you will be able to fully enjoy new Veeam Backup & Replication v11 features, like the new hardened Linux repository with immutability that helps protect your GFS restore points while on-site and pairs nicely with an all-new archive to the cloud tier for a simple off-site GFS deep archive holds. Check it out by downloading the trial for Veeam Backup & Replication v11.
