Restic S3 backup checklist: build and prove recovery

A useful restic S3 backup checklist starts by defining what you must recover and how you will prove it. Creating an encrypted repository and seeing a successful upload is necessary, but it does not show that you captured the right data, retained the right snapshot, or can rebuild the service under pressure. Treat the S3 repository as one component of a recovery procedure.

Before configuring credentials or schedules, name the recovery target: a single deleted file, an application deployment, a database at a recent point in time, or an entire Linux host. Then decide who can access the storage account, who holds the repository password or recovery key, where a restore may safely be written, and what evidence will count as a successful test. This prevents an apparently healthy backup job from concealing an incomplete recovery plan.

Write down the maximum acceptable data-loss window and the maximum acceptable service interruption. These are commonly called the recovery point objective (RPO) and recovery time objective (RTO). They are planning decisions, not properties automatically supplied by restic or S3: backup frequency affects the former, while restore size, database recovery steps, credentials, and testing affect the latter.

Inventory the persistent state on the server rather than assuming the application directory is sufficient. Common omissions include user uploads, generated assets, environment or deployment configuration, TLS material, scheduled-job state, and data stored outside the code checkout. For containers, inspect the volumes and bind mounts actually used by the running workload; Docker distinguishes managed volumes from bind mounts, and both can hold state that a replacement container will need. The Docker volumes documentation (opens in a new tab) is a useful reference when tracing where persistent container data lives.

Do not treat a live database data directory as an ordinary file tree unless the database engine and your recovery design explicitly support that approach. For many small-team PostgreSQL workflows, produce a database-aware backup artifact first and then protect that artifact with restic. PostgreSQL documents logical and physical backup methods, their scope, and their different restore procedures in its backup and restore documentation (opens in a new tab). Your chosen method must match the database objects and recovery behavior you need.

Revisit this map after migrations, Compose changes, new mounts, changed upload locations, or new databases. Backup coverage can drift while the job remains green because restic can faithfully back up yesterday’s path list even after the live service begins writing elsewhere.

Create or select storage under an account your team owns or controls, then give each repository a distinct prefix. A per-repository prefix limits accidental overlap between unrelated environments and makes it clearer which credentials and retention rules affect which recovery data. Record the bucket, region or endpoint, prefix, and any storage-provider settings in the recovery runbook; the repository location itself is recovery-critical information.

Grant the identity used by the backup host only the object-storage actions the repository requires, scoped to the intended bucket and prefix. In practice, a repository needs to list objects and read, write, and delete objects as its operation and pruning policy require; the exact policy syntax depends on the provider and configuration. Review the Amazon S3 User Guide (opens in a new tab) alongside your provider’s IAM documentation rather than copying a broad account-level policy into production.

Initialize the repository only after you have a safe way to preserve the repository password or recovery key outside the server being protected. Restic encrypts repository data, and the password is required to access it; losing it can make the encrypted repository unusable. Use the Restic documentation (opens in a new tab) to confirm repository URL syntax, credential configuration, and commands for your installed restic version.

Keep production and non-production data in separate repositories when their access, retention, or recovery requirements differ. Separation reduces the chance that a staging credential can affect production backup objects and gives each environment its own operational history. It is not a replacement for correctly scoped IAM permissions, protected credentials, or tested restores.

Run any database-aware export before the restic backup captures its output, and make failure in that export stop the backup workflow rather than silently protecting an old artifact. Likewise, make sure the agent host is online and can read the selected paths when the schedule runs. A scheduled job that never starts, loses storage access, or backs up stale export files needs a visible failure signal, not merely a cron entry.

Set retention according to the recovery points you need to keep across short incidents, delayed discovery, and longer business cycles. Retention removes snapshots from the policy view; cleanup of no-longer-referenced repository data is a separate operational concern. Before changing retention or pruning, identify the oldest snapshot you may need and confirm that no legal, operational, or recovery requirement depends on it.

For a small fleet, Rested Backups (opens in a new tab) can keep encrypted restic schedules, run outcomes, snapshots, and restore work visible in one workspace while the team retains control of its configured storage and recovery key. That visibility is useful for spotting a missed run or repeated failure, but it does not remove the need to define scope, maintain storage permissions, and test the service-level restore.

Monitor both explicit command failures and missing expected runs. A job can be absent because a host was offline, a scheduler was disabled, credentials changed, or a deployment removed the backup configuration. Review recent run history and snapshot freshness against the schedule you chose, then investigate deviations before the next incident makes them consequential.

A restore test should begin by selecting a specific snapshot and end with evidence that the recovered data works for its intended purpose. Restore into an isolated directory, host, container, or database target. Inspect files, ownership, permissions, and configuration; for a database, perform the documented restore procedure and run safe application or database checks against the restored copy.

Repository integrity checks are valuable evidence that stored data can be read and validated, but they answer a narrower question than application recovery. A healthy check does not show that the backup included every required path, that a database artifact can be loaded, or that the restored application has its dependencies and credentials. Combine repository checks with contained restore tests and record both results.

Record the snapshot identifier or timestamp, restore target, commands or workflow used, elapsed time, validation performed, failures found, and corrective actions. This turns a restore test into an operational artifact: the next person does not have to rediscover the bucket location, password owner, database order, or application checks during an incident. For a more detailed practice run, use this VPS backup restore test checklist.

The next concrete step is simple: choose one current snapshot this week, restore it somewhere safe, and verify one real workload outcome. If that test reveals missing data, permissions, keys, documentation, or time, fix the plan and repeat it; the useful backup is the one your team can actually recover.