How Often Should Backup Repositories Be Compacted or Pruned?

Eva Wong

IceWhale author

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

How Often Should Backup Repositories Be Compacted or Pruned?

Run retention pruning on a predictable schedule—often after successful daily or weekly backups—but compact only as the backup tool requires and when reclaimable space justifies the I/O. Prune selects expired recovery points; compaction or repacking reclaims storage.

The commands and costs differ between Borg, restic, and other deduplicating repositories. A safe schedule must account for write churn, repository locks, remote bandwidth, free space, and how long maintenance blocks new backups. This distinction sets the measurement method, safety margin, and stop condition. This distinction sets the measurement method, safety margin, and stop condition.

Separate retention decisions from space reclamation

Pruning enforces the recovery-point policy. It should happen often enough that expired snapshots do not accumulate unpredictably, but only after the newest backup is verified and the keep rules are reviewed.

Compaction rewrites or removes repository packs and may transfer substantial data. Running it after every tiny prune can waste I/O, while never running it can leave deleted data consuming the destination.

Use dry-run output where supported and record the expected keep set. A schedule is unsafe if operators cannot explain which daily, weekly, and monthly points remain afterward.

Trigger maintenance from measurable conditions

Track repository growth, reclaimable bytes, free capacity, prune duration, compact duration, lock contention, and the age of the last successful check. These signals are more useful than a calendar alone.

A small home repository may prune weekly and compact monthly; a high-churn repository may need more frequent maintenance. The correct interval is the one that preserves headroom without overlapping backup or restore windows.

Use the table below as a starting policy, then replace it with observed durations and growth rates.

Observed state	Verdict	Next action
Retention changed; little reclaimable data	Prune only	Defer compaction
High churn; meaningful reclaimable space	Prune then compact	Run in protected window
Low free space or active backup	Unsafe now	Stop and clear the conflict

Build a safe maintenance sequence

Complete and verify the new backup, run prune in preview mode, apply the retention policy, then compact or repack if the tool reports worthwhile reclaimable space. Never delete repository files manually.

Prevent concurrent writers and confirm enough temporary space for repacking. On remote storage, estimate downloaded and uploaded bytes before starting a job that could exceed the maintenance window.

ZimaSpace’s interrupted-prune diagnostic defines the safe recovery boundary.

Linux Junkies’ Borg and restic workflow shows why prune and space reclamation are separate operations.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

Validate retention with an actual restore

List retained points after maintenance and restore a small recent item plus an older item from each retention tier. Repository integrity checks and restore tests answer different questions, so run both.

Monitor the next normal backup for stale locks, missing packs, or unexpected full uploads. A green prune log does not prove clients can resume writing.

Proceed when the keep set matches policy, checks pass, restores succeed, and maintenance fits its window. Stop if free space is too low for repacking, another writer is active, or the dry run removes the last required recovery point.