What to know
- Practice with prepared consistent data and new private directories.
- Protect the repository password through a recovery-capable process.
- Restore separately and verify application data, not only job status.
Start with non-production practice data
This walkthrough teaches a restore exercise on a machine you control, using an installed restic package. Follow the official installation guidance for your platform. Choose new, private directories with enough space. Our example uses /srv/restic-practice as a repository and /srv/backup-export as prepared input; adapt ownership so the backup operator can read the source and write the repository.
Initialize the repository and protect the password
The repository preparation guide documents initialization and password handling.
restic -r /srv/restic-practice initChoose a strong repository password at the prompt and keep a separate recoverable copy in your password-management process. Do not put it into shell history or a public configuration. An encrypted repository without a recoverable key cannot serve your recovery plan. The local repository in this exercise is a teaching environment, not an off-site production backup.
Back up a consistent export
The backup guide describes snapshot creation. Prepare files and a database export or supported database-native snapshot first; copying live database files indiscriminately is not a consistency strategy.
restic -r /srv/restic-practice backup /srv/backup-export
restic -r /srv/restic-practice snapshotsRecord the snapshot ID, time and expected application data. Inspect the summary for skipped files and read failures. Ensure the prepared export does not accidentally include unrelated customer data.
Check and restore into a separate destination
Use the repository checking and restore documentation to distinguish integrity checks from a working application recovery. Replace SNAPSHOT_ID with the snapshot you deliberately selected:
restic -r /srv/restic-practice check
restic -r /srv/restic-practice restore SNAPSHOT_ID --target /srv/restore-drillThe destination must be a new protected test directory. Do not point a practice restore at the live website. A normal check does not read every data pack; plan the documented data-reading checks separately according to repository size and maintenance time.
Prove recovery and plan production storage
Open restored files and import the database export into an isolated test database. Verify a representative record and measure recovery time. For production, choose a suitable off-site backend, separate deletion permissions, retention policy and monitored schedule. Do not add prune or forget commands until retention and recovery requirements are agreed. Keep the exercise results with our wider backup and restore plan; a green job status is not the same as a tested recovery.
Sources & further reading
Primary sources supporting this article. The practical recommendations are Kiava’s general guidance and should be adapted to your project.
