A backup you have never restored

Start by settling which kind of site you have, because there are two tests here. If your site sits on Wix, Squarespace or GoDaddy's builder, your host keeps the backups for you. There is no backup file for you to download. If it sits on WordPress with its own hosting account, or on any hosting account with a control panel, you can usually download a backup yourself. If you are not sure, sign in to whatever you pay for each month and look for a backups page. If there is no backups page, treat your site as the first kind.

"We have backups" and "we can restore" are two different sentences. It is easy to check the first one and never check the second. A backup you have never restored is a claim, not a safety net.

If your site is on Wix, Squarespace or GoDaddy's builder

Nothing from Step 1 onwards is for you to do, and there is no archive to download. Two smaller questions are left, and both fit in the gap between two appointments.

Get your own content out. Look in your settings for an export. What it covers differs between platforms. It is usually a list of products, orders, customers or posts rather than the whole site. Download it, open the file, and check that your newest entries are there. Anything the platform will not export is something somebody would have to type again.

Test the site history on a page you can afford to lose. Look in your editor for a site history or a version history. Do not test it on a page a customer uses. Make a new page and write one line in it. Keep it out of your menu. Delete it, then restore it from the history. If it comes back with its text, the feature works and you know where the button is. If there is no history, your host's support team is the only way back. Keep their number where you can find it.

The page you would least like to lose is the one with your phone number and your opening hours. An export you have never opened is the same claim as a backup you have never restored.

The restore test, for a site with its own database

Open your hosting control panel and find the backups page. Most show a list of dates with a status beside each one. A row marked successful says a job ran. It does not say the job produced anything you could put back.

The ways a backup can fail are ordinary. A nightly job can run without the database in it. A job can fail for weeks while the alert goes to an address nobody reads. A backup can restore correctly and still take longer than the day allows.

You can settle this yourself. Set aside one quiet morning this month and run the test below. It takes longer than the quick checks you can run on the site itself, and it answers a different question.

Step 1. Read the backup before you restore anything

Download the newest backup to your own machine and unzip it. You are looking for two things.

• A database dump. Usually a file ending in .sql, sometimes .sql.gz. If there is no database in the archive, you have a folder of files and nothing else. No pages, no products, no orders, no form entries.
• Your uploads. On a WordPress site that is wp-content/uploads, and on any other site it is the folder holding your photographs. Open it and check that the folders for recent months actually contain images.

Then open the .sql file in a plain text editor. Decompress a .sql.gz first. Search for a few words you published in the last week or two. Pick a short phrase with no apostrophes or quotation marks. Those are stored with a backslash in front of them, so an exact search will miss them. A dump from a large site can be too big for a basic editor. Search that one from a terminal with grep instead.

Step 2. Restore it somewhere that is not your live site

Three places work.

1. Your host's staging site. Many control panels have a "create staging site" button. Use it if you have it.
2. Your own laptop. Local is free, is made by WP Engine, and runs a WordPress site on your own machine. Nothing is published online. The download form asks for an email address.
3. A subdomain, such as restoretest.yourbusiness.com.au. Put a password on it so that customers and search engines never see it.

Do not restore over your live site to find out whether the restore works. That is not a test. That is the emergency, arranged on purpose.

Note the time you start, and the time the restored site first loads. Without that number you know the restore works, but not whether it is fast enough.

Step 3. Decide what "it worked" means before you look

Open the restored copy and check five things.

• The home page loads.
• Images load on a page, not just the page itself.
• You can log in to the admin.
• Something that reads from the database works: a booking form, a price list, a shop page, a list of enquiries.
• Your most recent real content is there. Find something you published last week.

If all five pass, you have a safety net, and you now know roughly how long it takes to put back.

What a bad result looks like

• There is no .sql file anywhere in the archive.
• The restored site shows a database connection error.
• Pages load and images do not. The uploads folder was not in the backup.
• The newest content is missing. The database was captured from a stale copy.
• The restore needs a plugin licence key, or a login that nobody currently at the business has.
• It worked, and it took the whole day, on a quiet morning with nothing at stake.

None of these mean you are in trouble today. They mean the list of green ticks was measuring the wrong thing, and now you know which thing. A login nobody still has is an account problem rather than a backup problem, and there is a list of the accounts worth checking.

What is not worth worrying about

Much of what looks broken on a restored copy is normal. Ignore all of these.

• Email does not send from the copy. Expected. Staging sites and local copies usually have no mail configured.
• A browser security warning on a local copy. Expected, unless the tool installed a local certificate for you. A copy on your laptop has no certificate for your real domain.
• Some links still point at the live domain. Normal. Addresses are stored inside the database, and restoring the database does not rewrite them. So a link can take you back to the live site without you noticing. That makes a failed test look like a passed one. Check the address bar before you decide a page loaded.
• A plugin says its licence is not valid on this domain. Normal. Licences are usually tied to the live domain.
• Analytics. A restored copy still carries your tracking code, so it can add test visits to your live reports. Put a password on the copy, or remove the tracking code before you click around. If the copy records nothing, that is fine. Either way it is not part of the test.

If the pages, the images, the database content and the login are all there, the test passed. Everything in that list is noise.

Step 4. Write four lines, then set the next date

Write down the date. Where you restored to. How long it took, start to finish. What was missing.

Four lines in a plain text file, kept next to your hosting details, is enough. The next person to run this then starts from what you found.

Then put the next one in your calendar, one quarter out. A restore test is only worth anything while it is recent. A plugin is added, a host is switched, somebody changes the schedule.

You will learn one of two things this month. Either the safety net is real, or it was only a claim. Both are better to know on a quiet Tuesday than on the day you need it.

We will run this test for you if you want it run. The test matters more than who runs it. Pick the morning and run it.