A dashboard can report successful backups for months without anyone knowing how to recover the site. The useful question is practical: if the website stopped working today, who could restore a working version, and what information would they need?
Define what you need to recover
A Drupal recovery plan needs to account for the database, files, and the code and configuration needed to run them. Drupal’s backup guide describes the components to consider. Keep the backup procedure aligned with the way your hosting environment stores those components.
Start by listing business-critical data. A publishing site, a membership site, and a lead-generation site can have very different tolerances for lost changes. Agree how much recent work the organization could realistically recreate.
Give the recovery plan an owner
Record the backup location, retention policy, access process, and a second contact who can act if the usual maintainer is unavailable. Avoid a plan that depends on a single employee’s laptop or an undocumented personal account.
We recommend identifying which database and file snapshots belong together. Restoring a recent database with much older uploaded files can leave image references pointing at files that are not present.
Rehearse away from production
Restore a selected backup into an isolated environment. Confirm that important pages load, images appear, and an editor can open content. Keep external mail and other integrations isolated during the rehearsal. Record how long recovery takes and which steps required unexpected help.
- Can the backup be downloaded by the recovery team?
- Are the required runtime and database versions available?
- Are the configuration and credentials documented separately?
- Can the restored site complete a representative business task?
Review after changes
A hosting migration, new file store, or new integration can make an old recovery checklist incomplete. Add recovery review to those project handovers. The goal is a tested process that another person can follow under pressure.
Discuss backup ownership and restoration testing as part of your server support arrangements.