Evidence, Not Faith: Testing a CMS Backup on a Quiet Afternoon

Most UK web teams have a backup schedule, a vendor dashboard and a vague sense of comfort. What many do not have is a recent, first-hand answer to a simple question: if the site vanished this afternoon, could we actually bring it back? That is not a criticism. Restore drills sound like something for enterprise teams with a spare data centre and a change advisory board. In reality, a small web team can test the basics in an afternoon, on a target that cannot upset anyone, and end up with something far more useful than a green tick in a backup console.

A backup you have never restored is a rumour. It might be true. It might be complete. It might include the media library, the form entries and the redirect rules. But until you have performed a restore and checked the result, you are running on faith. Faith is fine for many things. It is a poor disaster recovery strategy.

Start with a rumour you can disprove

Pick one site, one backup and one quiet window. You are not trying to simulate a full disaster. You are trying to answer three questions: can we restore the content, how long does it take, and what breaks along the way? Write those questions down before you start. It keeps the exercise honest and stops it turning into a general CMS tidy-up.

Choose a backup from the last week or so. If your provider keeps daily snapshots, pick one from a normal day, not the day after a big content migration. You want a representative restore, not a stress test. If you have a runbook, open it. If you do not, that is the first finding: the runbook is the one-page note you are about to write.

Pick a target that cannot hurt anyone

Do not restore over production. Do not restore over the site your communications team is updating. Do not do this on a Friday at 4:59pm because someone found a spare hour. Use a staging environment, a local copy, or a throwaway subdomain that is blocked from search engines. If your host offers a one-click clone, use it. If not, create a separate database and a separate uploads directory.

The target should be isolated enough that a mistake is boring. That means no shared email sending, no live payment keys, no production cron jobs firing at real customers. If your CMS makes that hard, note it. A restore drill that risks sending password reset emails to the entire user base is not low-stakes.

Freeze, clone, and start the clock

Before you restore, note the time. Then restore the database and the uploads. If your backup tool splits those into separate steps, do them in the order your runbook recommends. Start a simple timer. You are not trying to set a world record. You are trying to get a realistic number for the next conversation about recovery time.

While it runs, resist the urge to fix things. The point is to observe, not to improve. If the restore asks for credentials you do not have, write that down. If it warns about a version mismatch, write that down. If it takes 40 minutes when you assumed 10, that is not a failure. That is the drill working.

Restore the database, then the awkward bits

A database restore is the headline act, but it is rarely the whole show. Once the database is in place, check that the CMS boots. Log in as an admin. Open the homepage. Open a deep page with an image. Then start looking at the parts that do not live in the main content table.

Media libraries are a classic quiet breakage. The database may know about an image, but the file may be missing if uploads were not included or the path changed. Open a few recent PDFs, hero images and thumbnails. Check that image styles or thumbnails regenerate. If your CMS uses an external image CDN, confirm that the restored site is pointing at the right place.

Forms are next. A restored form may look fine but post to the wrong endpoint, or lose its entries because they lived in a separate table. Submit a test entry on staging. Confirm it appears in the CMS and that any notification email goes to a safe test inbox, not a public mailbox.

Redirects deserve their own check. Many UK organisations have years of redirect rules built up after site moves, campaign pages and renamed services. Restore the redirect table and test a handful of old URLs. If the redirects live in a plugin, a module or the web server config, check that too. A missing redirect is not always obvious until someone clicks an old link from a printed leaflet.

Scheduled tasks and integrations are where restore drills get interesting. A restored site may still have cron jobs pointing at production, or a newsletter integration still wired to the live list. Pause what you can. Check what fires. Note anything that needs a manual switch before the site could safely go live.

Finally, check users and permissions. Can an editor log in? Can they publish? Can they see the media library? If your restore has changed user IDs or roles, note it. The same goes for API keys, search indexes, sitemaps and cache settings. These are not glamorous, but they are the difference between a site that loads and a site that works.

Write the one-page recovery note

When the drill is done, write a single page. Not a 30-slide deck. Not a wiki page that nobody reads. One page with: the date, the backup used, the target environment, the total restore time, the steps that worked, the steps that needed a workaround, and the things that broke. Add names for the two people who can answer questions. Put it somewhere the whole team can find it.

This note is the real output. It turns a vague assurance into a shared fact. It also gives you a checklist for next time. If the restore took longer because the uploads were in a different bucket, fix that before the next drill. If the form entries were missing, find out whether they are backed up separately. If the redirects were incomplete, add them to the backup scope.

Run it again before you need it

A restore drill is not a one-off ritual. Put a reminder in the calendar for six months' time, or tie it to your next CMS upgrade. Keep it small. Keep it safe. Keep the note updated. The goal is not to become a disaster recovery specialist. The goal is to know, with reasonable confidence, that the backup you are paying for is more than a rumour.

If you do nothing else this quarter, book two hours, pick a staging site and restore one backup. Then write down what happened. Your future self, probably on a bad Tuesday in 2026, will thank you.