Encrypted backups you can actually restore.

Choose the repository boundary

Use a separate destination and credentials from the production server. Client-side encryption can protect stored copies, but the repository password or key must be backed up privately. Losing it can make every encrypted snapshot unusable.

Capture consistent data

Use database-native dumps or an application-supported snapshot procedure. Back up configuration, deployment instructions and the protected secrets required for recovery. Exclude transient caches only when you know they can be rebuilt.

Make deletion harder

Consider an append-only or immutable destination where the source machine cannot erase every historical copy. Keep retention and pruning credentials separate where possible. Encryption alone does not stop a compromised server deleting a writable repository.

Schedule checks and restore drills

Monitor job exit status and the age of the last good backup. Run repository integrity checks supported by the tool. Restore a sample regularly and perform a complete recovery rehearsal after major application changes.

Separate adding a copy from deleting history

An append-only destination can let the production server add snapshots while keeping deletion authority on a separate trusted machine. Retention still needs careful review: forged newer snapshots can undermine some calendar-based selection policies. Check the tool’s guidance, run a retention dry run and monitor capacity. Restic’s forget operation selects snapshots; pruning removes unreferenced stored data.

• Keep repository maintenance credentials off the production machine
• Run a retention dry run before allowing deletion
• Use a new empty target for each recovery exercise

restic check
restic snapshots
restic restore latest --target /srv/restore-drill

Official documentation: Restic retention and pruning

A restore drill with a pass condition

Choose one realistic failure: a deleted file, a lost database or a complete machine rebuild. Restore into a separate directory or isolated host. Verify file contents, permissions and the application’s ability to use them. Record elapsed time and any manual step that was missing from the runbook. A repository check confirms a different property from a working application restore.

• Do not restore over the live application as a first test
• Confirm that encryption credentials are recoverable independently
• Alert if the newest successful backup exceeds your recovery target

Build a recovery manifest before choosing exclusions

List the things that cannot be recreated by reinstalling a package: database content, uploads, application configuration, signing or encryption keys and deployment versions. Record the consistency method beside each item. A database dump belongs to a defined point in time; copying a busy database directory can produce a different result. Keep repository access, its passphrase and any Borg key export in a separate private recovery location. Test that a replacement machine can open the repository before making it the only recovery copy.

• State the recovery point objective: how much recent work may be lost. Set the schedule around that requirement.
• State the recovery time objective: how long a rebuild may take. Include database import and DNS changes in the rehearsal.
• Check that an exclusion meant for caches does not also remove uploads, container volumes or protected configuration.
• Use the documentation for the installed Borg major version; repository formats and commands are not interchangeable across all versions.

Official documentation: Borg: encryption, consistency and restoration

Check stored data as well as repository metadata

Restic’s default repository check and a read-through verification do different work. Schedule data verification with its bandwidth and runtime cost in mind. The example checks one defined fifth of pack files; subsequent scheduled checks must use the other fractions to cover the repository. A randomly selected subset does not provide the same coverage guarantee. Neither operation proves that the application can start with restored data.

restic check --read-data-subset=1/5
restic snapshots --host example-host
restic restore latest --host example-host --target /srv/restore-drill

Official documentation: restic: repository checks and data verification

Keep maintenance outside the compromised client’s reach

Borg append-only storage preserves committed segment data, but a client can still change the visible archive list; recovery and compaction require the documented administrative procedure. Restrict the remote backup credential to Borg’s server command, not an unrestricted shell or filesystem login that could bypass those protections. With restic, review keep-within guidance for append-only retention. Before any maintenance that can remove history, inspect repository health and preview the selection from a trusted machine.

• Monitor the age of the last successful copy, repository growth, cache space and free capacity on both ends.
• If a restore fails, preserve the original repository and logs before attempting repairs or cleanup.
• If the job succeeds but expected files are missing, inspect archive contents and exclusion patterns before changing retention.
• Finish the drill by opening files and running application checks in isolation; keep production destinations out of the restore command.

Official documentation: Borg: append-only operation and maintenance · restic: retention and append-only considerations