Why Does a GFS Retention Policy Delete More Restore Points Than the Keep Counts Suggest?
A GFS retention policy can delete more restore points than expected because keep counts describe time buckets, not a simple sum of independent backups.
Rules such as keep-last, daily, weekly, monthly, and yearly usually select representative restore points from overlapping periods. One backup can satisfy several time tiers, while another can fall outside all buckets because of its timestamp, source group, policy inheritance, or a recent policy change. Some tools process rules in a defined order or exclude already-selected backups from later tiers. Preview the exact schedule before running prune or compact.
List Every Restore Point With Its Policy Group and Timestamp
Export snapshot or archive IDs, source host, path, tags, completion status, local time, UTC time, and the policy applied to each group. Do not count all repositories or sources together.
Restic applies retention policies to groups of snapshots based on host, paths, and tags unless grouping is changed, so two visually similar restore points can be evaluated under different policies.
If the unexpected deletions affect only one host, path, or tag group, fix that group or selector rather than changing repository-wide retention.
Do Not Add Daily, Weekly, and Monthly Counts Together
Map each restore point to the period it represents. Mark whether the same backup is the selected daily, weekly, and monthly candidate.
Proxmox’s prune simulator shows overlapping retention buckets, including cases where one weekly candidate covers a period and later rules do not keep another backup from the same interval.
The expected total is therefore not always keep-daily plus keep-weekly plus keep-monthly. Count unique retained backup IDs after all rules are applied.
Check Rule Order and the Candidate Chosen for Each Period
Determine whether the newest, oldest, first, or last successful backup inside each period is selected. Compare this with the job’s actual backup time.
Borg describes its GFS-style prune rules and notes that calendar-boundary behavior can affect archives near the cutoff.
A job running just before and after midnight can create two backups that appear to be on different dates locally but occupy one policy window after timezone or scheduler conversion.
Inspect Inherited Policies at Repository, User, and Source Level
Export the effective policy rather than reading only the global defaults. Check per-source overrides, inherited values, tags, folders, and UI presets.
Kopia’s policy command supports inherited retention values per source, which can make the active rule differ from the repository-level setting shown elsewhere.
A local keep value of zero or a changed inheritance boundary can remove restore points even while the parent policy looks correct. Save the resolved policy with the audit.
Review Recent Policy Reductions and Cleanup Timing
Compare the current retention values with previous policy versions and the time of the last cleanup. Determine whether older points were immediately marked for expiration.
Microsoft documents that reducing retention affects existing recovery points during a later cleanup job rather than only future backups.
A delayed cleanup can make many deletions appear to happen at once. Preserve the policy-change record and the list of points marked before approving another run.
Check GFS Flags, Short-Term Retention, and Policy Conversion
Inspect whether weekly, monthly, and yearly flags remain attached and whether the short-term chain can still support the selected points. Review software upgrades and policy conversions.
Veeam warns that changing GFS settings can cause existing candidates to lose GFS status and then become eligible for ordinary short-term deletion.
Do not assume that a restore point’s old filename or full-backup role guarantees current long-term retention. Verify its active policy flag.
Run a Dry-Run or Simulator Before Prune and Compact
Freeze policy edits, export the current restore-point list, run the platform’s dry-run or simulator, and compare retained and deleted IDs with a manually reviewed sample.
The ZimaSpace article on large snapshot histories provides the adjacent recovery context; this article focuses on why retention math differs from a simple count.
The issue is resolved when the simulator, effective policy, and unique retained IDs agree across at least two calendar boundaries, and no required recovery window depends on a point marked for deletion.
Frequently Asked Questions
Are keep-daily and keep-weekly counts additive?
Not necessarily. The same restore point can represent both periods, or the retention engine can exclude already-covered candidates from later rules.
Can reducing retention delete existing restore points?
Yes. Many systems apply the new policy to existing points during the next cleanup rather than only to future backups.
Does prune immediately free repository space?
It depends on the tool. Some systems mark snapshots or archives first and reclaim shared data during a separate compact or garbage-collection step.
Recommended products
Support & Tips
More to Read
Why Does a Docker Volume Restore Recreate File Contents but Drop Extended Attributes?
A volume-restore diagnosis covering xattr inventory, tar and Rsync options, namespaces, destination support, privileges, labels, app metadata, and tests.
Why Does a Running Container Keep Its Old Memory Limit After the Compose File Changes?
A memory-limit diagnosis covering live cgroups, restart versus recreation, Compose fields, hard and soft limits, parent scopes, swap, and runtime heaps.
Why Does Restarting a Reverse Proxy Invalidate Every Session for One Self-Hosted App?
A session-loss diagnosis covering restart scope, cookie ownership, secret rotation, cache-backed sessions, sticky routing, auth gateways, and recovery.
