Restore Files and Directories
Quick Summary
Restic restores data into a target directory. In most cases the safest workflow is:
- restore into
/restore/... - inspect/validate
- copy/promote into the live location
Prefer restoring into a staging path first, then copy/promote the recovered files after you confirm they are correct.
Safe Restore Rule
Do not restore directly into a live production directory unless you have a clear rollback plan.
Restore to /restore/... first, verify, then apply the changes.
How Restic Chooses What to Restore
| You specify | Example | Meaning |
|---|---|---|
| Snapshot | latest or snapshot ID | which point-in-time to restore |
| Target | --target /restore/lab | where restored files will be written |
| Filters (optional) | --include "/srv/app/config" | which paths from the snapshot |
Restore Latest Snapshot
restic restore latest --target /restore/lab
After restore, inspect what you got:
ls -la /restore/lab
tip
If you are restoring a service, restore into a new directory and point the service at it first (if possible).
Restore a Specific Snapshot
restic snapshots
restic restore 3f1a7c4b --target /restore/snapshot-3f1a7c4b
Find a Snapshot by Tag/Host (Common)
restic snapshots --tag daily --host app-01
Restore Only Selected Paths
restic restore latest \
--target /restore/lab \
--include "/srv/app/config" \
--include "/srv/app/uploads"
note
The --include paths refer to the original paths from the backup.
They are restored under your --target directory.
Common Mistakes
| Mistake | What happens | Fix |
|---|---|---|
| Restoring into the wrong place | data lands somewhere unexpected | always use explicit --target |
| Restoring without checking snapshots | wrong restore point | filter with --tag/--host first |
| Restoring directly into live directory | overwrite production state | restore to /restore/... then promote |
tip
Use explicit restore targets like /restore/<ticket-id>/ so recovery steps remain auditable.