Why a successful backup can still be unrecoverable

A backup can finish successfully and still be unusable for the incident you face. The fastest safe check is to pick a specific recovery point, restore it somewhere isolated, and prove that the application can read its expected data. Before doing that, confirm you have the repository location, storage access, decryption key, and a target that cannot overwrite production.

Consider an application whose uploads moved from /srv/app to a Docker volume. A job still protecting /srv/app can report ninety successful runs while containing no recent uploads. The tool accurately backed up the path it was given; the recovery scope was wrong. Compare your backup definition with [current Linux server recovery targets](/blog/what-to-back-up-linux-server) and, for containers, [runtime volume and mount coverage](/blog/detect-docker-volume-mount-backup-coverage-drift).

A successful run is evidence of execution, not proof of application recovery. Correct scope, consistent data, intact storage, available credentials, compatible infrastructure, and an executable restore procedure must all hold. If any one is uncertain, investigate it before treating the green status as a usable recovery point.

After each deployment or migration, inventory application paths, named volumes, bind mounts, databases, configuration, and secrets needed for recovery. Map each item to a backup method and a restore destination. Check that separate filesystems were mounted when the job ran, exclusions and symbolic links behave as intended, and the backup identity can read the selected sources.

Do not reduce partial reads to a harmless warning: [restic documents a distinct exit status for incomplete source reads](https://restic.readthedocs.io/en/stable/040_backup.html). Investigate unreadable files and missing mounts, then inspect a restored recent upload or record. A snapshot and byte count cannot tell you that the source was stale.

A file-level copy of a running database is not automatically a usable database backup. Use an engine-supported logical, physical, or coordinated snapshot procedure and test its corresponding restore path. For PostgreSQL, [pg_dump](https://www.postgresql.org/docs/current/app-pgdump.html) produces a consistent logical export of one database; it does not by itself include every database or cluster-wide role. See [pg_dump versus pg_dumpall](/blog/pg-dump-vs-pg-dumpall) when defining scope.

Consistency can fail across components, too: a database record restored from noon may reference an upload recovered from midnight. Record the snapshot time or export boundary for each dependency, decide how much mismatch the application can tolerate, and test the combination. Physical or point-in-time PostgreSQL recovery has additional requirements, including the necessary write-ahead logs; choose it deliberately rather than assuming a logical dump provides point-in-time recovery.

Storage credentials let you reach backup objects; the repository password unlocks encrypted restic data. You need both. If every working restic repository password is lost, intact storage cannot recover the data. Keep approved recovery material off the protected host and test access from a clean environment without putting secrets in test logs.

Have a second authorized operator locate the repository, obtain storage access, and unlock it using the documented break-glass process. If recovery depends on one employee's device or an active session on the failed server, fix custody before an incident. The [backup encryption key ownership plan](/blog/backup-encryption-key-loss-recovery-ownership-plan) covers this failure mode in more detail.

Many recent snapshots do not help if corruption began before the oldest one. Choose retention using both the time you might take to discover damage and the recovery points you need. Before changing a policy, inspect which snapshots it would keep; [restic forget and prune](/blog/restic-retention-policy) are different operations, and pruning reclaims data no longer referenced by retained snapshots.

Also ask whether the same compromised account could delete both production and backups. Separate credentials, an independent copy, or storage protections may reduce that shared risk, but they change permissions, retention, and pruning behavior. Plan and test those trade-offs rather than assuming that versioning or immutability alone makes recovery certain; see [Object Lock, versioning, and the prune trade-off](/blog/immutable-restic-backups-object-lock-versioning-prune).

Recovered files still need compatible software, ownership, permissions, configuration, secrets, certificates, and network dependencies. A PostgreSQL dump may also depend on roles or extensions that must exist at restore time. Record which prerequisites live in the backup, which must be provisioned separately, and the order in which to bring up the database and application.

Keep the runbook current after application releases. A useful rehearsal starts with a clean target, rebuilds dependencies, restores data, and only then starts the application. Do not enable outbound mail, webhooks, or queued jobs in a test environment until you have controlled their side effects.