Define the service recovery objective, acceptable data-loss window and an isolated destination. Collect backup encryption keys, package/runtime requirements, configuration, database recovery files and DNS/network details. Keep the test copy disconnected from production jobs and external transactions.

1. Select a specific recovery point and record its creation time and included components. Confirm the backup is readable using credentials available outside the failed-server scenario.
2. Provision a compatible test machine or recovery environment. Recreate required storage mounts and permissions without exposing private data to unauthorized users.
3. Restore files, configuration and databases using their supported procedures. Keep application workers, mail delivery and scheduled integrations paused until the environment is safely isolated.
4. Start services in their dependency order and inspect logs. Test authentication, a known database record, uploads and a representative write using test data.
5. Measure the full elapsed recovery time, including provisioning, key retrieval and validation. Document missing steps, then correct the backup or recovery process.
6. Securely remove or retain the test copy under the intended data policy and repeat after major architecture or backup changes.

On an isolated Linux restore target, use a checksum manifest created from the backup you are testing. In this example the manifest contains relative paths from /srv/restore-test. Run the check there so the names resolve against the restored copy.

cd /srv/restore-test
sha256sum --check /srv/backup-manifests/site-files.sha256

Read the result: An OK result means that a listed file matches the recorded bytes. A missing file or failed checksum needs investigation before declaring the backup usable. The manifest must itself come from a trusted, protected source; a checksum file stored only beside compromised production data is not independent evidence.

Checksums do not test file ownership, application configuration, database recovery or a customer workflow. Continue with those separate checks on the isolated target. Keep test email, payment callbacks and scheduled tasks contained so a restoration rehearsal does not contact real customers.

Only during a deliberate cutover. During testing, isolate it so duplicate identity, scheduled emails or application transactions cannot interfere with the live service.

Confirm the recovered state matches the chosen backup time and the service meets its recovery objective. Check permissions, certificates, secrets and external dependencies. Record evidence of successful application behavior, not just a file count.

If a dependency or key is missing, keep the failure as a finding and update the recovery plan. Do not connect an unverified clone to production to see whether it works. If recovery requires information stored only on the failed server, move that information into a protected independent recovery record.

• Creating a controlled rsync backup over SSH
• Inspecting an unbootable Linux server from rescue mode
• Planning bootloader recovery on a Linux server
• Testing SSH configuration before reloading the service

• www.postgresql.org: Backup
• download.samba.org: Rsync
• Debian: Ch10.en