Repository Layout and Backends
Your repository naming and layout directly affect how easy restores are.
Quick Summary
Pick a repository layout that answers these questions quickly:
- Which environment is this? (prod/staging)
- Which host or service is this? (app-01/db-01)
- What data domain is this? (app/db/media)
If you already use rclone, think of RESTIC_REPOSITORY as the equivalent of a "remote + path", but Restic manages the internal snapshot structure.
What You Are Choosing
| Choice | You decide | Why it matters |
|---|---|---|
| Backend | local disk, SFTP, S3/B2/R2, etc. | durability, cost, performance |
| Repository path | a single unique path | prevents mixing environments or hosts |
| Naming strategy | consistent identifiers | makes restore selection predictable |
Recommended Layout
s3:my-company-backups/restic/
prod/app-01/
prod/db-01/
staging/app-01/
tip
Avoid putting unrelated systems into the same repository path. One repo per recovery boundary keeps your retention and restores safer.
Backend Examples
# Local
export RESTIC_REPOSITORY="/var/backups/restic/prod-app-01"
# SFTP
export RESTIC_REPOSITORY="sftp:backup@10.0.0.20:/data/restic/prod-app-01"
# S3
export RESTIC_REPOSITORY="s3:s3.amazonaws.com/my-company-backups/restic/prod/app-01"
Best Practices
- Use separate repositories (or at least separate repo paths) for prod vs staging
- Use explicit host naming with
--hostso snapshots filter cleanly - Prefer backends that support your durability goals (offsite for disasters)
tip
Use one repository path per workload boundary (for example: app, db, media).