A backup is a candidate for recovery, not proof of recovery. Test whether a different authorized operator can restore the website into a clean environment, verify it, and roll back without depending on the failed system or one person’s laptop.
Define what must be recoverable
| Layer | Backup evidence | Restore test |
|---|---|---|
| Code | Repository and tagged release | Clean clone builds the expected artifact |
| Content | CMS export or source files | Pages, metadata and internal links return |
| Database | Versioned encrypted dump | Schema and a non-sensitive sample restore |
| Assets | Object-storage or media copy | Referenced images and downloads load |
| Configuration | Documented variables and provider settings | New environment starts without hidden local files |
| DNS and domain | Zone export and registrar inventory | Recovery operator can reconstruct records safely |
| Credentials | Approved vault and recovery owners | Two authorized people can access required systems |
Do not put live secrets inside the backup archive or test report. Record secret names and recovery locations, then inject values through the approved secret manager.
Run the smallest meaningful drill
- Choose a release and recovery objective.
- Create an isolated target that cannot overwrite production.
- Restore code, content, database, assets, and configuration from documented sources.
- Verify representative pages, forms, redirects, canonical tags, email routing, and access control.
- Record start time, usable time, data point restored, failures, and manual interventions.
- Delete or secure the temporary environment.
- Assign owners and deadlines for every gap.
The NHN Cloud ransomware response guide explicitly includes restoration testing and documentation. CISA likewise recommends offline or protected backups and regular testing rather than assuming stored copies are usable.
Test independence, not only integrity
A valid archive can still be useless if the encryption key, DNS account, package registry, or build instructions disappeared with the same vendor. Ask:
- Is there more than one authorized recovery operator?
- Are backup credentials separate from production credentials?
- Can the copy survive deletion or compromise of the main account?
- Are runtime versions and dependencies pinned?
- Can the organization renew the domain and hosting during recovery?
- Is the most recent acceptable data point known?
Record two recovery objectives
Recovery point objective asks how much recent change the organization can lose. Recovery time objective asks how long the service can remain unavailable. Write them as business decisions, then choose backup frequency and drill scope accordingly. A daily content site and a frequently updated transactional service should not inherit the same answer by habit.
Finish with a signed result
The report should name the tested backup, environment, operator, elapsed time, restored data point, checks passed, gaps, and next drill date. Do not write “backup verified” when only download or archive extraction was tested.
The useful promise is precise: this specific copy restored these specific website functions under these conditions. Repeat the drill after major platform, ownership, or deployment changes.
Need a clearer first step for your website?
Start with the situation and outcome. We will help define the scope and next step.