Running a restore drill
A restore drill is a practice run: you restore a recent backup to a staging copy (a private copy of your site for testing), not to the live site, and check that it works. Do it before you ever need it, ideally a few time
The short answer
A restore drill is a practice run: you restore a recent backup to a staging copy (a private copy of your site for testing), not to the live site, and check that it works. Do it before you ever need it, ideally a few times a year and after any big change. It takes about an hour and it is the only way to know your backups are real.
What it means
A backup you have never restored is a hope, not a plan. Backups can quietly be incomplete (files but no database), missing the uploads folder where your images live, or stored on the same server that just failed. The first time you find out is usually the worst possible moment.
A drill removes the guesswork. You restore into a safe place, confirm the site loads, log in, check the latest order or post is present, and see that images display. You also learn how long the process takes and which steps are confusing, so a real emergency becomes a routine you have already done once.
A drill also tests the people, not just the files. It answers simple questions that matter at the wrong time: who has the console login, where the backup list is, and what to do if the newest backup turns out to be the broken one. Writing those answers down is half the value.
Common causes
- Nobody owns it. Everyone assumes the host, the developer or a plugin has it covered, so no one checks.
- Fear of overwriting the live site. Restoring feels dangerous, so it never gets tested. Restoring to staging removes that fear.
- The backup excluded the database or the uploads folder. Common with plugin backups set up years ago and never reviewed.
- Backups stored only on the server itself. If the server is lost, so are they.
- No definition of done. Without a short checklist, nobody can say whether the restored site is actually complete.
How to fix it
- Pick a restore point. In the management console (Plesk with WP Toolkit) go to Websites & Domains, then Backup & Restore, and note the date and time of a recent backup. Write down the most recent order number, post title or form entry on the live site at that time so you have something to compare against.
- Create a staging copy to restore into. Open WP Toolkit, find the site card and use Clone. This gives you a separate copy with its own address. On other hosts, use whatever staging tool exists. The principle is host independent: never drill on live.
- Restore into the staging copy. In Backup & Restore, choose the backup and click Restore. Pick what to restore, files, database or both, and direct it at the staging copy rather than the live site. VERIFY: whether a backup of the live site can be restored directly into the staging copy from the console, or whether support performs this step. If the console only restores in place, the alternative drill is to download the backup, extract it, upload the files with File Manager or SFTP, and import the database through phpMyAdmin.
- Run the checklist. Homepage loads. You can log in. The newest order, post or entry you noted in step one is present (for a store, go to WooCommerce, then Orders, and compare the latest order number). The Media Library shows images, not broken icons. A form submits. Go to Settings, then Permalinks, and click Save Changes, then open an inner page. Open Tools, then Site Health, and confirm there are no critical issues.
- Practise a single-file restore. Delete a harmless file on the staging copy, such as a theme’s readme, then restore just that file from Backup & Restore. Partial restores are what you reach for most often in real life.
- Drill the off-site copy too. In Backup & Restore, set up remote storage to your own Dropbox, Google Drive, Amazon S3 or FTP, and on the next drill restore from that copy instead. A backup held in two places is the one that survives.
- Record the result. Date, who did it, how long each step took, anything that surprised you. Put the next drill in the calendar, and repeat the drill after any major change such as a redesign, a PHP upgrade or a move to a new host.
- Clean up. Delete the staging copy, or keep it as your standing test site for plugin and PHP updates.
On WP Alpha
Backups run every two hours and restores are queued from the management console (Plesk with WP Toolkit). They are kept for 30 days, and a restore can be as small as a single file or as large as the whole site, so a drill can rehearse both the small fix and the full rebuild. VERIFY: how long a full-site restore typically takes once queued.
Staging sites are one click in WP Toolkit, which makes the safe version of the drill easy. You can also send your own backups to Dropbox, Google Drive, Amazon S3 or FTP as often as hourly for a copy that lives outside the platform. If anything in a drill does not behave, support is available 24/7 by live chat and ticket, and there is an urgent escalation form for a real outage.
