Almost everyone has backups now. Your phone syncs to the cloud, your laptop copies itself to a drive or a service, your website has a plugin with a reassuring green tick. And almost nobody has ever pressed restore.
That gap is where the bad day lives. A backup is not a file — it is a claim that a file can be turned back into a working thing. Until you have tested the claim, all you own is a folder and some optimism. The good news is that testing it is a small job, and you only have to do it properly once to know whether your setup is real.
Here is how to run a restore drill on the three things most people back up, without putting the originals at risk.
Why backups fail (it is rarely the backup)
When a restore fails, it is usually for one of five boring reasons:
- It was backing up the wrong thing. Photos, yes; the app data, no. Website files, yes; the database, no.
- It stopped weeks ago. A permission changed, a password expired, a drive filled up, and the failure notice went to an inbox nobody reads.
- The copy is on the same device as the original. A backup on the same laptop, or on the same server as the website, dies with it.
- The archive is damaged or encrypted with a key nobody can find. Encryption is good. Encryption with an unrecorded key is a very secure way to lose your data.
- Nobody knows the procedure. The backup is fine; the person who knew how to use it left, and the restore takes six hours of guessing.
Notice that four of the five are only discoverable by trying. That is the whole argument for a drill.
Drill 1: your phone (15 minutes)
You do not need to wipe your phone to test its backup. You need to prove the backup contains what you think it contains.
- Open your backup settings and check the date of the last completed backup. Not "backup is on" — the actual date. If it is older than a week, that is your first finding.
- Look at what is included. On both major phone platforms, the list of included items is visible in settings, usually per app. Confirm the things you would actually cry about — photos, messages, authenticator app, notes — are ticked.
- Test the authenticator specifically. Two-factor codes are the single most common thing that does not come back after a restore, and losing them locks you out of the accounts you most need during an emergency. Make sure you have recovery codes saved somewhere that is not your phone.
- Restore one item to prove the pipe works: recover a deleted photo from the cloud bin, or re-download a file. Small, safe, and it confirms you can actually reach the archive.
If you have not set the phone side up properly yet, start with how to back up your phone and come back to this.
Drill 2: your laptop (20 minutes)
- Pick three files you would hate to lose — a document, a photo, something from a project folder.
- Open the backup and find them. If you cannot find them, that is the finding: your backup is not covering what you assumed.
- Restore them to a new folder on the desktop, never over the originals. This is the safe way to test: you end up with a copy, and nothing existing is touched.
- Open each restored file. A file that restores but will not open is not a restore.
- Check the dates. If the newest version in the backup is three months old, your schedule is broken even though the backup "works".
Two extra checks worth doing once: confirm one copy of your data lives somewhere physically separate (a second drive kept elsewhere, or a cloud service), and write down how you would get in if your main computer were gone — which account, which password, which recovery method.
Drill 3: your website (the one people skip)
Website backups are the most likely to be untested and the most painful to get wrong, because a website is really two things stuck together: the files (the theme, the plugins, the uploads) and the database (the pages, the posts, the orders, the customers). A backup of one without the other restores to a broken site.
A safe drill, in order:
- Find where the backups actually live. If the answer is "on the same hosting account as the site", fix that first — one compromised or suspended account takes both.
- Download the most recent backup to your own computer. If you cannot download it, you do not really control it.
- Confirm it contains both a files archive and a database dump. Open the archive and look. This one check catches the most common website-backup failure of all.
- Restore it somewhere that is not your live site — a staging site, a local environment, or a temporary subdomain. Never practise on production.
- Click around the restored copy: log in, open a page you edited recently, check images load, submit a form. That is what "the restore worked" means.
- Write down how long the whole thing took. That number is your real recovery time, and it is the number to quote when someone asks how bad an outage would be.
If a restore reveals that your recent work is missing, that is not a wasted afternoon — that is the finding, discovered on a calm Tuesday rather than during an incident. And if a restore is ever needed because something malicious got in, restoring alone is not the end of the job: the what to do after a data breach checklist covers the password and account side that a file restore does not touch.
When to hand the website drill to someone else
The phone and laptop drills are genuinely DIY. The website one is where most people stall, because it needs somewhere safe to restore to, and because doing it properly means repeating it after every significant change — not once a year when you remember.
If the site is a business asset running on WordPress, that repetition is a reasonable thing to buy rather than to promise yourself. WPCare, a WordPress maintenance and support team based in Malaysia, is one example of the model: its published approach is continuous snapshots kept off the site's own server, scheduled weekly updates rather than ad-hoc ones, and staging environments available so changes are tried somewhere safe first. The reason that combination matters is exactly the point of this article — off-site copies survive the thing that killed the original, and a staging environment is what makes a restore drill possible at all.
Whoever you use, including a plugin you run yourself, ask the same two questions you would ask a friend who offered to hold your spare key: where is the copy kept, and have you ever opened the door with it?
FAQ
How often should I run a restore drill? For a personal phone or laptop, once or twice a year and after any big change — new device, new backup tool, new account. For a business website, after any change to hosting, the backup tool or the database, and ideally as part of a regular maintenance routine.
Is a cloud sync the same as a backup? No, and this trips people up constantly. Sync copies changes in both directions — including deletions and damage. If a file is corrupted or a site is compromised, sync faithfully copies the problem. A backup keeps older versions you can go back to, which is the part that saves you.
How many copies do I need? The common rule of thumb is more than one copy, on more than one kind of storage, with at least one kept somewhere else. You do not need to be precious about it; you do need one copy that would survive the loss of your home, office or hosting account.
My host says they take backups. Is that enough? It is a good start and not a complete answer. Ask three things: how far back the copies go, whether you can download one yourself, and how long a full restore takes. If you cannot download a copy, your recovery depends entirely on someone else's availability on your worst day.
The bottom line
Backups are cheap and confidence is free; only a restore tells you the truth. Do the phone drill this week, the laptop drill next, and put the website one in the calendar — or give the website to a team that runs it as a matter of routine. For a WordPress site, WPCare is worth a look on exactly that basis: off-site copies, a staging environment to restore into, and a schedule that does not depend on you remembering.
