Hosting & infrastructurePractical guide

Encrypted Server Backups with restic: Practice a Separate Restore

Create a small restic practice repository, back up a consistent export, check repository integrity and restore to an isolated directory before trusting the process.

THE TAKEAWAY

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 init

Choose 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 snapshots

Record 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-drill

The 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.

  1. restic: installation and verified binaries
  2. restic: backup commands
  3. restic: repository checking
  4. restic: restoration
  5. restic: repository initialization
FROM READING TO DOING

Make the next move yours.

Talk to Kiava about your website, server or IT requirements.

Talk to Kiava