Before you begin
- A completed service inventory and permission to handle its backed-up data.
- A selected backup set, its timestamp, software versions and authorized access to the recovery secrets.
- A separate target with enough space and access controls for the restored information.
- Two harmless witness accounts with different permissions, plus a known page and attachment.
- A named test owner and another maintainer who can review the result.
Decide what would count as a working notebook
Use the illustrative workshop wiki from the service inventory. Its success criteria are specific: an editor can find and change a test page, a reader can view permitted instructions, a private organizing book stays hidden, and an attached diagram opens. Use these checks as the test plan before opening the backup.
| Witness | Expected observation | Record during the drill |
|---|---|---|
| Reader account | Can read the permitted repair page; cannot edit it. | Pass/fail and the page checked. |
| Editor account | Can save a harmless change to the designated test page. | Change and resulting revision. |
| Restricted book | Unavailable to the reader through navigation and a direct link. | Account, path and observed access. |
| Witness diagram | Opens from its page with expected contents. | Filename and any mismatch. |
| Notification | Captured only in the isolated test destination. | Destination and number observed. |
Choose witnesses that existed when the selected backup was made. A newly created page cannot prove that an older backup is incomplete.
Identify the exact recovery set
Write the backup identifier and timestamp on the result sheet. Include application configuration, database data, attachments and the software information needed to interpret them. If their capture times differ, investigate how your backup procedure keeps them consistent before beginning the exercise.
For a restic repository, choose an explicit snapshot or carefully check the filters used with latest. Its --path option selects a snapshot; it does not limit the restored files. A restore can overwrite existing files, which is another reason to use an empty, dedicated target. restic restore documentation.
Distinguish repository checks from application recovery. A default restic check examines repository structure; check --read-data also reads stored pack data and can consume substantial transfer and time. Neither checks whether a member can use your wiki. restic integrity checks.
Make the test copy quiet before it starts
Keep production database hosts, storage paths and outgoing credentials out of the test configuration. Have the second maintainer compare every destination against the service map. Confirm that the target is separate before any restore operation that writes files or database objects.
- Restrict access to the people conducting the drill.
- Keep the production DNS records unchanged.
- Block outgoing delivery or replace it with an approved capture destination.
- Disable webhooks, scheduled integrations and queue workers until their test behavior is defined.
- Check that browser links and redirects cannot quietly take the tester back to production.
Treat the restored data as sensitive as the original. Isolation is an operational check to demonstrate, not a label attached to a directory. If you cannot verify the destinations or controls, stop before starting the application.
Bring back the pieces in a deliberate order
Follow the restore instructions for the installation method and versions in your inventory. For the BookStack example, the official procedure covers a separate database and file restore, retaining the original APP_KEY, and adjusting the application URL when the address changes. Container setups require the database restoration before the application container runs. BookStack restore sequence and configuration notes.
- Prepare the dedicated runtime and database target without starting ordinary member traffic.
- Restore the matching database and files; retain the original backup unchanged.
- Apply the test environment's addresses and restricted external connections.
- Check required file ownership and access against the application's installation instructions.
- Start the service with outbound actions still controlled, then run the planned witnesses.
Recovering the recorded version first keeps a routine drill focused. If the exercise also requires a version change, document its migration path and recovery point separately. Do not make an unplanned upgrade the remedy for an unexplained restore failure.
Check both what works and what stays forbidden
Run the reader and editor checks in separate browser sessions so an administrator session cannot conceal a permissions failure. Test an attachment through the page and its direct address. Search for a known phrase, follow an internal link and inspect one older revision that should exist in the backup.
If a check fails, record the first observable difference. A missing image suggests a different investigation from an unexpected login redirect or a forbidden database connection. Preserve relevant error evidence without copying private content or credentials into a general support note. Correct one identified cause and repeat the affected check; do not change permissions broadly just to make an error disappear.
Only exercise email against the chosen capture destination. BookStack offers a test email action and documents that some notification failures appear in logs instead of the user's page. Review that evidence as well as the visible result. BookStack email checks and failure behavior.
Leave an honest result for the next person
Service / test owner / reviewer:
Backup identifier / capture timestamp:
Application and database versions:
Isolated target / access restrictions:
Outbound actions disabled or redirected:
Test start / usable-service checkpoint / finish:
Reader / editor / private book / attachment results:
Search / links / revision / notification results:
Missing information or failed steps:
Corrective action / owner / next exercise:
Test data cleanup completed by:Enter observed times only after doing the work, and say which checkpoint each measures. A single successful rehearsal is evidence for that backup and procedure; it does not establish a recovery guarantee for another failure. Confirm cleanup of the test copy and its captured messages under the group's retention rules. Feed missing ingredients back into the inventory, and use portable data exports to prepare a separate path for moving the group's content.
Documentation behind this note
Use the documentation for the version you actually run. These examples are planning material, not a record of a test on a Hoszen VPS.