Backup retention policy: GFS, immutability windows and how long to keep each kind of backup

Backup retention policy: how long to keep backups

A backup retention policy states, for each class of data, how long restore points are kept on each copy and for what reason. Our suggested default for most systems in a mid-size company is daily restore points for 30 days and monthly full backups for 12 months under a grandfather-father-son (GFS) scheme, with yearly fulls only where a documented business or legal reason asks for them, and an immutability lock equal to the short-term retention.

Operational restore points bring a system back after a failed change, a deletion, corruption or an attack, so they are dense and recent. Long-term points show a past state months or years later, for an audit or a dispute.

NIST SP 800-209 (October 2020) recommends a data protection plan that sets frequency and retention for each tier, with “48 hourly snapshots, 30 daily backups” as its example, and tracking of copies “including affirmative deletion of no longer needed ones”.

For the providers listed in its Article 1, such as cloud, data centre and managed service providers, Implementing Regulation (EU) 2024/2690 asks in Annex point 4.2.2(f) for backup plans with “retention periods based on business and regulatory requirements”. ENISA’s technical implementation guidance of June 2025 gives no figure; for retention it refers to point 3.2.5 on logs, where it adds “Delete data when the retention period ends.”

Operational restore points and dwell time

Short-term retention decides how far back a system can be rolled back day by day; Veeam’s version 13 user guide says it “defines how many restore points you want to retain on disk and, thus, how ‘far’ you can roll back.”

Its lower bound is the time damage stays unnoticed. Mandiant’s M-Trends 2026 report of 23 March 2026 puts the global median dwell time of its 2025 investigations at 14 days. After an attack, the restore point has to predate the intrusion, not only the encryption, as our guide to ransomware recovery in the first 72 hours explains. A logic error that has written wrong data since the last release needs a point from before the change in the same way. Thirty days of daily points cover the median with a margin, and the monthly GFS fulls reach further back at a coarser interval.

Dating an intrusion needs logs, so their retention belongs in the same policy. Point 3.2.5 of the implementing regulation asks for logs to be kept and backed up “for a predefined period”, and Mandiant warns that a 90-day log retention leaves the start of an intrusion that lasted nearly 400 days out of view.

GFS retention in Veeam: weekly, monthly and yearly fulls

Veeam’s user guide describes grandfather-father-son (GFS) retention as storing backup files “for weeks, months and even years”. In Veeam Backup & Replication, the Retention policy field at the Storage step of the backup job wizard takes the short-term retention in days. The Configure button next to Keep certain full backups longer for archival purposes opens the long-term (GFS) settings; in the console wizard, select that check box first.

Veeam’s user guide says GFS does not create “any special new backup files”. It flags full backups the job has written as weekly, monthly or yearly, and flagged fulls ignore the short-term retention until their own period ends. A monthly point is therefore one full backup, the state of a single day in that month.

The fulls to flag come from the forward incremental chains with periodic synthetic or active fulls that a hardened repository requires anyway, as our Veeam hardened repository guide describes. On XFS with Fast Clone, Veeam “references existing data blocks on volumes instead of copying data blocks between files”, so keeping a synthetic GFS full costs only the blocks no other retained backup holds. Active fulls do not use Fast Clone and take their full size, as the same guide notes.

Backup copy jobs keep “all restore points created during the specified number of days” and have GFS settings of their own. In version 13.1, a scale-out backup repository with a performance tier and an archive tier, but no capacity tier, can also copy GFS points to the archive tier when they are created, and Veeam notes that copy and move policies can be combined “to apply different retention per tier”. Which copies to keep is the subject of the 3-2-1-1-0 backup rule.

Restoring one old monthly or yearly point per test cycle shows whether the encryption keys and application versions it depends on are still available; NIST SP 800-209 lists encryption key retention among the items of a data protection plan.

How immutability periods interact with retention

A locked restore point cannot be deleted before its lock expires, whatever the retention says. Veeam deletes a forward incremental chain only when its last increment has left the retention, and on a hardened repository the lock runs from the chain’s last restore point, so with daily runs and weekly fulls a 30-day lock keeps each chain on disk for about 36 days.

A 30-day short-term retention keeps the chain for the same 36 days, so under that lock it costs no more disk than 14 days of retention, and the policy matches what the disk holds. Weekly GFS fulls kept for four weeks add nothing either, because they fall inside those 36 days.

On a hardened repository, Veeam’s user guide for version 13 (page updated 8 September 2026) sets the lock of a full backup with a GFS flag to the longer of the repository’s immutability period and the GFS lifetime, as our article on what immutable backup protects against also sets out. A yearly full kept for three years therefore stays on disk for three years and cannot be deleted early, either to reclaim space or for an erasure request.

Retention schedule by data class

Retention per class is agreed with the system owners in the same conversation as the recovery tiers in our guide to RPO and RTO: each owner states how far back a restore must reach and which records must be kept.

Our suggested starting values for a mid-size company, not a standard; the owners’ answers replace them, and the archive column follows the legal department’s retention schedule. Immutable configuration backups from Veeam’s What’s New in 13.1 (11 August 2026).

Our security and backup assessment reviews infrastructure, access and backups and ends with a risk map and a prioritised action plan. Send us your job list with the retention settings of each job through the form below.

Capacity for GFS retention: a worked example

The disk a retention policy needs depends more on how many blocks differ between retained fulls, and on block cloning, than on the number of points. Take the example from our hardened repository guide, a 10 TB full backup file with 0.5 TB of increments a day and weekly synthetic fulls with Fast Clone. Keep 30 days of daily points under a lock of the same length, then add 12 monthly and 3 yearly GFS fulls. The change rates between GFS fulls in the table are our assumptions for this example, not measured values.

Our arithmetic with assumed change rates, not a measurement; daily chain from our Veeam hardened repository guide; 80 per cent fill limit from Veeam’s Backup & Replication best practice guide.

Without block cloning, or with active fulls, each GFS full is a complete file of about 10 TB, and the 13 older fulls need about 130 TB instead of 24.5 TB. The assumed monthly difference of 1.5 TB fits databases that rewrite the same blocks every day; where changes spread across the data it can be much higher, so measure it on the current repository before sizing.

Eurokommerz holds the contract and supplies the hardware under the solution, with delivery and warranty under European law. Write to us with your source data size, daily change and retention targets through the form below.

GDPR storage limitation and erasure requests in backups

Article 5(1)(e) of the GDPR requires personal data, in backups as in production, to be kept in a form that identifies people “for no longer than is necessary for the purposes for which the personal data are processed”, and Article 17 obliges the controller to erase personal data “without undue delay” where one of its grounds applies. Article 32(1)(c) at the same time lists the ability to restore the availability of and access to personal data in a timely manner after an incident.

The EDPB’s report “Implementation of the right to erasure by controllers”, adopted on 10 February 2026, sets out what 32 supervisory authorities found in their coordinated enforcement action of 2025. Half of the responding authorities raised concerns about deletion in backups, and many controllers had no specific procedure for erasure requests there, relying on automatic deletion or on the backups’ retention periods. The report calls backup an important tool to protect the integrity of personal data in incidents such as ransomware, and states that, depending on technical settings and risks, “it might not always be advisable to modify or delete information from back-ups”. In that case it expects procedures that keep track of erasure requests and comply with them on restored systems, as much as possible, after a breach that affects the integrity of the systems. It also recommends that controllers verify erasure and be able to demonstrate it. The EDPB may consider more guidance on erasure in backups, including what “without undue delay” means there.

An image-level backup cannot be edited record by record, and an immutable one cannot be changed before its lock expires, so the procedure works around the copies:

1. Keep a register of erasure requests, with dates and the systems concerned, outside the systems and backups it covers.
2. Before a restored system with personal data goes back into use, re-apply every erasure registered since its restore point, and record that this was done.
3. Limit browsing and restores of backups with personal data to the backup administrators.
4. Document in the record of processing activities how long each backup layer keeps personal data, GFS points and locks included; Article 30(1)(f) asks the record for “the envisaged time limits for erasure”.

Legal retention periods differ by country

Retention duties come from contract, commercial, tax, social and archiving law, among others, and they differ between Member States and between sectors; the EDPB report describes periods that stem from “a variety of European or national laws or regulations”. Article 17(3)(b) of the GDPR excludes erasure to the extent that processing is necessary to comply with a legal obligation under Union or Member State law. Which periods apply, and whether Implementing Regulation 2024/2690 binds the company, is a legal assessment for the legal department, and the backup policy takes the resulting schedule as its input.

For periods of several years, an archive system or the application itself is usually a better place than image backups. A yearly VM backup brings back the operating system and application version of that year together with every record of that day, including records erased since then, while an export of the records the law requires stays searchable and lets the backup expire on schedule.

What we do

Under our cyber resilience service, on one EU contract with Eurokommerz, our engineering partner Vixen.UNO sets up Veeam-based backup, with a recovery site in Baltneta’s Tier-3 data centres in Lithuania and target RPO and RTO fixed in the SLA, and runs regular test restores to verify backup integrity. The paid technical assessment reviews security and backup and ends with a risk map and a prioritised action plan; its price is fixed before work begins. Where we or our partners process personal data on your behalf, a data processing agreement is provided on request, with subprocessors named in the contract, as our security and compliance page describes.

FAQ