Back up the system.
Practise the recovery.

Inventory what the application needs

Begin with the application, not the backup tool. List its database, uploaded files, configuration, accounts or roles, encryption keys, and software versions. Add external dependencies such as DNS, identity providers, and object storage. A restored database may be unusable if a required file or credential is missing.

For each item, record its location, the method that captures it, and the check that will show it returned correctly. Keep this inventory outside the backup selection itself: otherwise an omitted file can disappear from both the backup and the list used to verify it.

Decide how much loss and downtime you can accept

Two targets help turn “we have backups” into a plan you can evaluate. They are requirements to measure against, not guarantees supplied by installing a backup tool.

Recovery point objective

How much recent data you can afford to lose. If a day of changes is unacceptable, one successful backup per day is not an adequate target by itself.

Recovery time objective

How long the service can be unavailable. Count time to detect the problem, obtain equipment, download data, restore dependencies, and check the application—not just the import command.

Use targets appropriate to the service. A disposable test environment and a household document store do not necessarily need the same treatment. Check the age of the newest usable backup, not just the configured schedule: a job that has been failing for a week leaves a much larger gap.

Separate copies by failure risk

A second folder on the same disk is not independent of that disk. Another disk in the same host still shares risks such as host loss, theft, power problems, and administrative mistakes. An independent copy should address the failure you want to survive.

The 3-2-1 approach is a useful starting point: three copies of the data, including the working copy; two different storage media or types; and one copy off-site. Evaluate the actual failure domains rather than treating the numbers as proof. Offline or immutable copies can add protection against deletion, but retention and access policies need to be configured and checked.

File synchronisation and replication can quickly copy an unwanted deletion or damaged file. They may be useful parts of a design, but they do not automatically provide historical recovery points. Likewise, RAID helps with certain hardware failures; it does not replace versioned, independent backups.

Encrypt sensitive backups and plan how authorised users will recover the decryption credentials. Store recovery material securely and separately, with access controls suited to its importance. Do not place the only usable key inside the encrypted archive that key is needed to open.

Capture data in a form the application can restore

Use the application or database’s documented backup procedure. Copying an active database’s data directory as ordinary files is not automatically a consistent backup. Logical exports, supported physical backups, and application-coordinated snapshots have different requirements.

If an application stores database records and uploaded files separately, consider whether they need to represent the same point in time. Depending on the software, that may require a maintenance mode, a coordinated snapshot, or another documented process.

For PostgreSQL, pg_dump creates a logical backup of a database. It does not by itself include all cluster-global objects such as roles and tablespaces. Record those requirements separately and follow the documentation for the versions you use. Avoid assuming a dump is portable to every older server version.

Practise the restore without overwriting the source

Create a separate destination with new storage and an explicit name. Confirm the destination is empty and that restore paths cannot resolve into the live application. Use an environment you own or are authorised to administer. A restore drill should not start by deleting the working copy.

Choose a specific backup identifier and record it. Restore required files and application data, then verify both. A checksum comparison can establish that a file matches a known baseline; it does not establish that you chose every required file or that the restored application works.

Check representative user actions in the restored system: open a document, read a record, or retrieve an upload. Compare content and relationships where practical. Record counts alone may miss a substitution: five wrong rows are still five rows.

Also test a known bad case in a disposable fixture—for example, a deliberately incomplete backup selection. The verifier should reject it for the expected reason. An unrelated permissions error is not evidence that the intended check worked.

Keep a useful recovery record

Write down the backup identifier and age, application versions, recovery destination, elapsed time, checks performed, and remaining problems. Capture observations rather than just “passed.” Keep credentials and personal data out of shared reports.

A local restore verifies a particular path. It does not necessarily test losing the whole host, downloading an off-site archive over a slow connection, or recovering access to the key store. Name those gaps and schedule separate tests where they matter.

Repeat the drill after meaningful changes to storage paths, application versions, authentication, or backup tooling. Retention rules also need review: do not discover during an incident that the only recovery point predates a migration or that an older required copy was removed.

Your next step

Recovery-readiness checklist

• Inventory: Database, files, configuration, keys, roles, and external dependencies are listed.
• Targets: Acceptable data loss and downtime are written down for this service.
• Copies: A usable copy and its recovery credentials remain accessible if the source host is lost.
• Consistency: The capture method follows the application’s backup requirements.
• Isolation: Restore storage is separate, and outbound side effects are controlled before startup.
• Verification: Files and representative application data are checked against known expectations.
• Repeatability: The recovery record includes versions, timing, gaps, and a reason or date to test again.