Restic backup guide: encryption, snapshots, and restores

Restic is an open-source backup program that creates encrypted, deduplicated snapshots in a repository. It can write to local storage and several remote or S3-compatible backends. Each snapshot records the state of the selected paths at a point in time.

Restic encrypts repository data and metadata. The repository password is therefore part of the recovery system: losing it can make otherwise healthy backup data unusable.

A practical lifecycle includes repository initialization, scheduled backups, retention, periodic integrity checks, and restore tests. Each stage should produce an observable result rather than disappearing into unattended cron output.

Restic snapshots are incremental in storage use because unchanged data is deduplicated, but every snapshot still represents a complete recovery view. Retention commands select which snapshots to keep; pruning removes unreferenced data from the repository.

Choose retention from recovery requirements, not an arbitrary snapshot count. Preserve dense recent history and less frequent long-term points when that matches the risks you need to cover.

Selection and physical cleanup are distinct steps. Review which snapshots a policy would keep before allowing data removal, and avoid overlapping repository maintenance with another writer. The safest retention schedule is one whose effect is visible and whose credentials are no broader than necessary.

Restic can validate repository structure and, when requested, read stored pack data to verify it against recorded hashes. A metadata-only check is faster, while reading all data exercises the storage more thoroughly and may take substantial time on a large remote repository.

Neither form proves that the right source paths were selected or that a database export is application-consistent. Pair repository checks with coverage review and a restore into an isolated target. Open representative files and start restored applications or databases far enough to confirm that the recovery point is useful.

Repository-changing operations coordinate through locks. Do not respond to every interruption by removing locks blindly: first confirm that no backup, prune, check, or restore still owns the repository. Concurrent automation should have a clear overlap policy and enough runtime allowance for slow storage.

An interrupted backup does not make earlier snapshots disappear, but the expected new recovery point may be missing. Monitor the age of the latest successful snapshot rather than relying only on a scheduler exit code. That catches dead hosts and jobs that never started as well as commands that failed.

A repository URL and storage key are not sufficient without the repository password. Store a protected copy away from the source host, document how an authorized responder obtains it, and test that procedure without relying on an already authenticated production shell.

Use storage credentials with the narrowest practical scope for routine backups. Recovery may need a separate credential path, especially when the source host is suspected of compromise. The objective is to make normal operation constrained without leaving an incident responder locked out.

Document the repository location, required credentials, password retrieval process, and target paths. Restore into a separate directory first unless the recovery procedure specifically calls for an in-place restore. For databases, prefer an application-consistent dump or a database-aware procedure over copying live data files.

Record which snapshot was used, how long retrieval took, what was validated, and which manual decisions remained. That evidence turns a restore target into an estimate the team can defend and exposes dependencies that are easy to miss in a written runbook.