How To Verify Website Backups Actually Restore

A backup file sitting in storage proves almost nothing on its own. It proves a process ran and produced a file. It does not prove the file is complete, that it can be turned back into a working website, or how long that would take if you needed it urgently. The only thing that proves a backup works is restoring it and checking the result — and most businesses have never seen that happen, because it's usually invisible unless something has already gone wrong.

This article is for a non-technical owner who wants to ask the right questions, not just take "we have backups" as a finished answer.

An untested backup is a hypothesis

Think of a backup as a claim rather than a fact until someone tests it. Files can be partially written. A database export can complete but reference tables or plugins that were never included. A backup can be stored correctly but the restore tool or credentials needed to use it can be missing, expired, or simply never tried. None of these problems show up by looking at a file list or a "backup successful" email — they only show up when someone actually restores the backup somewhere and checks that the site works.

The practical test is simple to describe and rarely done: take a backup, restore it into a separate, private copy of the site, and confirm the pages load, the database is intact, and nothing critical is missing. If nobody has done that for your site, you don't currently know whether your backups work.

RPO and RTO, in plain English

Two terms come up constantly in backup and disaster-recovery conversations, and they're worth understanding because they turn a vague worry into a specific, answerable question.

Recovery Point Objective (RPO) is how much data you can afford to lose, measured in time. The U.S. National Institute of Standards and Technology defines RPO as "the point in time to which data must be recovered after an outage" (NIST, SP 800-34). In practice: if your backups run once a day and something goes wrong five minutes before the next one, your RPO is roughly 24 hours — meaning a day's worth of orders, form submissions, or content changes could be gone.

Recovery Time Objective (RTO) is how long it takes to get back up and running. NIST describes RTO as the length of time a system can be in the recovery phase "before negatively impacting the organization's mission or mission/business processes" (NIST, SP 800-34). In practice: if a restore has never been tried, your real RTO is unknown, not zero — and "unknown" is a bad number to discover during an actual outage.

Ask any provider for both numbers as they apply to your site specifically, not as general claims. If they can't answer, that's the honest starting point for a conversation, not a reason to walk away — plenty of small business sites genuinely don't have this measured yet.

The 3-2-1 principle

A widely used baseline, and one recommended by the U.S. Cybersecurity and Infrastructure Security Agency for small businesses, is the 3-2-1 rule: keep three copies of your data, on two different types of storage, with at least one copy stored somewhere physically separate from the original (CISA, Back Up Business Data). The reasoning is straightforward — a single backup stored in the same place as the live site is vulnerable to the same failure (a compromised server, a hosting account issue, a mistake) that could take down the original. Two different media types and an offsite copy reduce the chance that one bad event destroys everything at once.

You don't need to interrogate the exact technical implementation, but it's fair to ask whether backups are stored somewhere separate from the live server, and whether more than one copy exists at any time.

A note on scripts and credentials

If a provider shows you a script or configuration used to run or test a restore, one thing is worth checking regardless of the technical detail: it should never contain a password, API key, or passphrase written directly into the file. Credentials belong in environment variables — values set outside the script, on the machine or system running it — so the script itself can be shared, reviewed, or stored in version control without leaking access to anything. A script with a real password typed into it is a script that leaks that password to anyone who ever sees the file, including in backups of the script itself. A safe pattern looks like this, illustrating the idea rather than any specific tool:

#!/usr/bin/env bash
# Restore test — reads the passphrase from the environment,
# never from a value written into this file.
set -euo pipefail

: "${BACKUP_ARCHIVE_PATH:?set BACKUP_ARCHIVE_PATH}"
: "${RESTORE_PASSPHRASE:?set RESTORE_PASSPHRASE in the environment, not here}"

backup-restore-tool --archive "$BACKUP_ARCHIVE_PATH" \
  --passphrase-env RESTORE_PASSPHRASE \
  restore latest --target /tmp/restore-check

echo "Restore complete. Now check the site actually works."

The point isn't the specific tool — it's the pattern: credentials come from the environment, the script fails loudly if they're missing, and nothing sensitive is stored in plain text next to the code.

What to ask a provider for as evidence

A specific, fair set of questions: When was a restore from our backups last actually tested, and what was the result? What is our current RPO — how much data could we lose if something happened right now? What is our current RTO — roughly how long would a real restore take? Are backups stored somewhere separate from the live server? How many recent backup copies are kept, and for how long?

If a provider can answer these with dates and specifics, that's a good sign. If the honest answer is "we haven't tested a restore recently," that's still useful — it tells you exactly what to fix first, and it's a more useful answer than false confidence.

What this doesn't promise

Verifying a restore once doesn't mean every future backup will also restore cleanly forever — configurations change, data grows, and testing needs to happen on an ongoing basis, not as a one-time exercise. A tested backup process significantly improves your odds in a bad situation; it does not make data loss impossible.

---

JagaWeb Care (RM450/month, excluding SST) includes verified backups as part of the retainer — meaning restores are actually tested, not just assumed to work — alongside monitoring, patching, and two content updates a month, with card checkout and no sales call. It's one option among several ways to handle this, not a guarantee that nothing will ever go wrong. More at jagaweb.my, sales@jagaweb.my, or WhatsApp jagaweb.my.