Restore it somewhere else. Then call it a backup.

Define the smallest complete service

For a static site, the essential set may include published files, web-server rules and domain settings. A database-backed application also needs a compatible database copy and its configuration. Include uploads and any secrets required for recovery, but store secrets in an authorised private system rather than in the public archive.

Create an isolated destination

Use a separate directory or test host where recovery cannot overwrite the working site. Make sure the restored copy will not send live customer messages, accept transactions or start scheduled jobs unexpectedly. Isolation is part of the plan, not a step to improvise after the restore has begun.

Recover with the instructions another person would receive

Start from the saved backup and written steps. Note every undocumented assumption: a missing package, an unknown password, a permissions change or a file excluded from the archive. If you have to rely on memory, add that step to the runbook. The exercise is testing the procedure as much as the data.

Check a complete request

Open the recovered home page, a deeper page and a media file. For an application, verify the critical operation using test data. Check the configuration needed for the intended hostname and HTTPS before any real cutover. Extracting an archive successfully is not the same as recovering a working service.

Record the result and improve the next copy

Write down the backup date, restore duration, checks performed and missing pieces. Keep the drill result with the private operations notes. Correct the backup job or documentation and rerun the failed check. Avoid turning an approximate rehearsal duration into a guaranteed recovery commitment without considering the conditions of a real incident.

Put it into practice