Should a Borg Repository Use Append-Only Mode or Normal Access?
Use append-only when a backup client is less trusted than the repository and a separate trusted maintenance path exists. Otherwise, normal access is simpler and more transparent.
For a home server that pushes backups to another machine, the real decision is not whether append-only sounds safer. It is whether a compromised client must be prevented from reclaiming old repository data, who can run retention maintenance, and how recovery will work if archives are hidden or marked for deletion. Start with credentials and maintenance ownership, then test both backup and restore behavior before committing the repository to either mode.
Define Which Machine and Credential You Do Not Trust
List the source machines, repository host, SSH keys, service accounts, and administrator identities. Mark which identity performs ordinary backups, which identity performs retention maintenance, and which identity can log into the repository host. Append-only helps only when the less-trusted client is actually restricted at the repository boundary.
A remote append-only backup server is strongest when the client key is forced into a restricted Borg command and cannot obtain a general shell or maintenance credential.
If the same client stores the administrative key, schedules compaction, and can edit the repository configuration, the advertised boundary is mostly procedural. If the repository host itself may be compromised, append-only on that host is not an independent copy. Choose the mode only after the threat map shows who is separated from whom.
Verify What Append-Only Changes in Your Borg Workflow
Create a small disposable repository and run the exact commands your automation will use. Add two archives, list them, apply the planned retention command, attempt compaction with the client identity, then switch to the trusted maintenance identity. Record which data remains recoverable and which operations are merely reflected in the client's current view.
In an append-only repository, archives may no longer appear to the client after deletion or prune intent even though storage is not reclaimed until trusted maintenance permits it. That distinction must be understood before an incident.
The test passes only when the restricted client can create backups, cannot permanently reclaim protected history, and the trusted administrator can inspect the transaction state and restore the needed archive. If the operator cannot explain how to recover a hidden archive, append-only is not ready for production regardless of whether backup creation succeeds.
Choose the Mode That Fits Maintenance Ownership
Choose append-only when remote or exposed clients need to push backups, a separate protected identity can perform maintenance, storage can absorb the delay before compaction, and recovery has been rehearsed. Keep that maintenance credential off the ordinary backup clients and run it only from a hardened administrator path.
Choose normal access when the repository and client share one trusted administrative boundary, routine retention and space reclamation must run directly, and operational simplicity matters more than limiting a compromised client key. A warning about automatic append-only compaction is important: an automated trusted compactor can complete destructive intent created by a compromised client if it runs without review.
Use separate repositories when one group of clients is trusted and another is exposed, or when their maintenance schedules conflict. Do not weaken every client to the least secure shared model for deduplication convenience. The right choice is conditional: append-only protects a specific credential boundary, while normal access keeps maintenance direct.
Validate Backup, Restore, and Maintenance as One Cycle
Run the complete operating cycle before relying on the repository. Create two backups from the client, apply the intended retention policy, review the resulting state with the trusted identity, restore a sample directory to a separate location, and perform the planned maintenance step. Measure storage before and after so delayed reclamation is visible.
Repository access mode does not remove identity and mount-path checks. If Borg cannot find a moved repository, keep that repository path diagnosis separate from append-only behavior.
The mode passes when scheduled backups work, an earlier archive can be restored, the maintenance identity can review and reclaim space deliberately, and the same results persist after a client reboot. Roll back to the test repository if archive visibility is confusing, storage grows without a safe maintenance window, or the administrator credential is not truly separate.
Recommended products
Support & Tips
More to Read
How to Schedule Restic Backup, Forget, and Prune Jobs Without Lock Conflicts
A complete multi-host Restic schedule that separates frequent backups, scoped retention, physical prune, checks, retries, and restore validation.
How to Prevent Restic Prune Jobs From Blocking Scheduled Backups
A prevention plan for shared Restic repositories that separates backup windows from prune and keeps locking, retries, and alerts intact.
How to Clear a Stale Restic Lock Without Interrupting an Active Backup
A least-invasive Restic unlock workflow that protects active backups, removes only stale state, and confirms recovery under the normal schedule.
