Backup integrity checks vs restore tests: what they prove

Run **backup integrity checks** and restore tests, then rehearse application recovery separately. An integrity check asks whether the repository can be read consistently at the coverage level you chose. A restore test asks whether a particular snapshot can be recovered through a specified workflow. Neither result, by itself, proves that your VPS and application will start with the right data during an outage.

A successful backup run establishes that backup work completed; it does not establish that you selected every necessary path, preserved a loadable database dump, retained the right recovery point, or can reach storage with your emergency credentials. Keep integrity-check evidence tied to its coverage and check time, restore-test evidence tied to its tested snapshot and mode, and application-drill notes tied to the recovery attempt.

• Repository integrity: Can the repository’s metadata—and, if selected, stored data—be checked? Metadata-only coverage does not read every backup-content object; a random sample cannot establish the integrity of the whole repository.
• Isolated restore: Can the selected snapshot yield readable files or, where supported, a database that loads into a temporary target? This tests one recovery path, not every snapshot or dependency.
• Recovery drill: Can an operator obtain the key and storage access, rebuild the service in isolation, restore its dependencies, pass application smoke tests, and measure the elapsed time?

For a VPS with application files, start with an isolated restore of a known snapshot and check that important files are present and readable. For a single PostgreSQL database, loading a logical dump into a temporary database answers a stronger question than merely reading the dump artifact. When the question is whether the whole service can recover, use a disposable server or environment and test the application against restored data.

For repository checks, metadata-only coverage is the lighter first signal; reading a random 10% of stored data adds sampled content coverage without proving the other 90%; checking all stored data provides broader read coverage but consumes more provider reads and bandwidth. This is a coverage choice, not a selection of a snapshot or a substitute for restoring one. A restore test also needs temporary disk space and provider bandwidth, so account for both before scheduling one on a constrained host.

In version 0.2.9, [Rested Backups](https://restedbackups.com) offers separate repository integrity checks and isolated restore tests, with independent verification history. Before using them, confirm that the enrolled agent is version 0.2.9 with verification-v1 capability; the repository is initialized and enabled; storage has been validated; the recovery key is sealed to the current agent; and a known snapshot exists. Reserve temporary disk space, and arrange temporary-database privileges if you intend to load-test PostgreSQL.

Open the repository’s Verification view. Run each type of check manually first, or choose independent 7-day or 30-day schedules for restore tests and integrity checks. For integrity, select metadata-only, a random 10% data sample, or all stored data. For a restore test, select file verification or PostgreSQL load testing where that mode is supported. Automatic verification is **off by default for existing repositories**; opening the page does not mean a schedule is active.

A filesystem restore test uses the latest known snapshot, restores it to a private temporary directory, uses restic verification, reads regular files, and removes the temporary data. For supported native and Docker **single-database PostgreSQL** backups, the load test can import the dump into a temporary database, query its catalog, and remove that database without importing into the live one. Other database recipes verify restored files or dump artifacts instead; a readable artifact alone does not prove its database can load.

Scheduled tests are queued when a capable agent checks in, and due backups take priority. Only one repository command runs at a time, so verification is not a replacement for the backup schedule. Scheduled verification is paused for disabled, billing-suspended, over-limit, revoked, debug, or recovering repositories. If a scheduled attempt fails, it waits until the next interval unless you fix the cause and retry manually.

After each run, review the latest attempt, last successful result, status, duration, and verification history for **each check separately**. Verification does not change the last successful backup time. For an integrity check, note whether it covered metadata only, a random 10% data sample, or all stored data, and when the check ran; it does not select a snapshot. For a restore test, note the snapshot tested and whether it used file verification or supported PostgreSQL load testing. An old successful restore test is not evidence about a newer snapshot.

If a check fails, first distinguish a test-environment failure from evidence about the backup. Confirm that the agent checked in, the repository is eligible to run, storage credentials and provider access still work, and temporary space or database privileges are sufficient. Then investigate the reported read, repository, restore, or database-load failure. Do not relabel a failed test as healthy merely because a backup ran successfully; correct the issue, retry manually, and retain the failed attempt in your review.

A successful all-data integrity check is evidence about stored data at check time, not an application recovery drill. A successful filesystem restore test shows that the tested snapshot’s regular files passed that workflow, not that your configuration and services will work together. A PostgreSQL temporary-database load test adds evidence that the tested dump loads and its catalog can be queried, but it does not prove application compatibility, complete recovery scope, or future restore success.

Verification should lead to an operational decision, not just another dashboard status. For a small VPS and single-database PostgreSQL service, rehearse recovery in a disposable environment with separate credentials and no route that could overwrite production. Your operator must be able to locate the repository, reach storage, and supply the saved recovery key; Rested cannot recover an encrypted repository if that key is lost.

Restore the chosen snapshot’s application files and configuration to the disposable target, then load the corresponding database backup into its isolated database. Apply the service’s documented startup order, check that required files and database objects are present, and run a representative application read and write that cannot affect production. Have the operator record the snapshot time, any missing dependencies, the time taken, and steps that were unclear. Stop and investigate if the dump will not load, expected data is absent, or the application fails its smoke test; remove the disposable environment and temporary credentials afterward.

Keep a short, reusable checklist: confirm backup freshness and scope → run a repository check and note its coverage and check time → restore and test a known snapshot and note its verification mode → drill the application in isolation and record the operator’s findings → assign the next fix. If you need a fuller rehearsal plan, use the [VPS restore test checklist](/blog/vps-backup-restore-test-checklist) alongside your [recovery documentation](/docs/recovery).