Backup monitoring checklist: size, age and integrity

Until someone restores it, a backup is a claim rather than a fact. Three measurements turn the claim into evidence: how recent it is, whether its size makes sense, and whether the contents can actually be read back. A useful backup monitoring checklist is built around those three questions, plus the discipline of restoring something at regular intervals rather than waiting for an emergency.

None of this requires expensive tooling. It requires deciding what "healthy" looks like for your data, and then checking against that definition on a schedule.

Age: recent enough to be worth restoring

Start by deciding how much data you can afford to lose. If your store takes forty orders a day, losing a day is painful but survivable; losing a week is not. That decision sets your recovery point objective, and everything about backup frequency follows from it.

Then check the age of your newest backup against that target. Two traps catch people here. The first is time zones: a job scheduled in one zone and a timestamp displayed in another can look several hours stale when it is fine, or fresh when it is not. Standardise on one zone for logs and note which it is.

The second is retention. Age matters at both ends, so check your oldest copy as well. A common pattern for small businesses is seven daily copies, four weekly and three to six monthly, which protects against a problem that was introduced quietly weeks ago. A retention policy that keeps only the last three days cannot help you recover from data corruption you did not notice immediately.

Keep at least one copy in a second location. The widely used guidance is three copies on two kinds of storage with one off-site, and for a small business that can be as simple as the server, a cloud bucket, and a periodic download.

Size: the single most revealing number

File size is a crude measure that catches a remarkable share of problems, because a healthy backup grows slowly and predictably.

Record the size of every run in a simple log, then compare each new backup against the previous one and against the average of the last week. Set a tolerance, for example twenty percent, and treat any deviation outside it as something to look at.

What a sudden shrink usually means

A truncated archive because the disk filled, a folder that stopped being included after a path change, a database dump that stopped early, or a table that failed to export. A backup half the usual size is almost never good news.

What a sudden jump usually means

Often something harmless but wasteful: a cache directory that started being included, log files piling up inside the site folder, or a staff member uploading video into the media library. Occasionally it is a sign of something worse, such as a compromise dumping files onto the server. Either way it is worth a look, because it also threatens your storage costs and your backup window.

Track the trend as well as the jumps. If your backup is growing ten percent a month, your storage plan and the time the job takes both need attention before they become the problem.

Integrity: prove the file can be read back

Size tells you something is there. Integrity checks tell you it survived the journey.

• Checksums: calculate a hash of the archive when it is created, and again after it reaches the remote destination. If the two differ, the transfer damaged the file. Store the hash alongside the backup.
• Archive test: most archive tools can test an archive without extracting it. Run that test as part of the job and treat a failure as a failed backup.
• Database dump sanity: a complete dump ends with a recognisable completion marker. Checking that the last lines look right catches dumps that stopped halfway, which is the most common silent database failure.
• Spot-check contents: list the archive and confirm that the directories you expect are present, particularly user uploads and any recently added folder.
• Encryption check: if backups are encrypted, verify that the key you hold actually decrypts them. A backup you cannot decrypt is not a backup.

Automate as much of this as your job allows and record the outcome in the same log line as the size and duration.

Coverage: is everything you would need actually in there?

Restores fail as often from missing pieces as from corrupt files. Walk through what a rebuild would need: application files, the database, user uploads, configuration files, scheduled job definitions, web server and virtual host settings, mail configuration, and a record of DNS entries.

Credentials and environment files need care. They are essential to a restore and sensitive, so they should be included but encrypted, and the key stored somewhere other than the backup itself.

Exclusions are worth documenting too. Caches, temporary directories and duplicated media are reasonable to leave out, but write down what is excluded so nobody assumes coverage that does not exist.

Restore sampling: the only real proof

Verification checks make failure less likely. Only a restore proves success, so build a light routine rather than an annual ordeal.

1. Monthly, small: pick one random file from a backup and restore it to a temporary location. It takes minutes and catches path and permission problems.
2. Quarterly, full: restore a complete copy to a staging server or a temporary instance. Bring the site up, log in, load a few pages and run a report that touches the database.
3. Time it: note how long the full restore took from decision to working site. That figure is your realistic recovery time, and it is usually longer than people assume.
4. Write the steps down: the person doing the restore in a real incident may not be the person who set it up. A one-page procedure with commands, locations and credentials saves hours.
5. Record the result: date, backup tested, what worked, what did not. Fix anything that did not before the next cycle.

Always restore into a separate environment, never over the live site. The point is to test the backup, not to gamble with production.

The checklist, by frequency

Pull it together into a routine somebody owns:

• Daily, automated: job completed, archive test passed, size within tolerance, heartbeat received, copy present at the remote destination.
• Weekly, two minutes: glance at the size trend and the newest and oldest timestamps.
• Monthly, ten minutes: restore one file, confirm retention is behaving, check remaining storage space.
• Quarterly, an hour: full restore to staging, time it, review coverage against the current site, confirm the encryption key still works.
• After any change: re-check coverage following a migration, a new folder, a database change or a plugin that stores files somewhere new.

Run one restore this month

If you do nothing else from this list, restore a single file from your most recent backup this week and note how long it took to find it. That one exercise usually reveals whichever link in the chain is weakest, and it costs almost nothing.

If your current arrangement cannot answer these questions, it is worth having someone look at it properly. Our team reviews backup coverage and restore procedures through the support desk, and you can ask an expert if you want a second opinion on what your host's included backups actually cover.

Frequently asked questions

How many backup copies should a small business keep?

Enough to recover from a problem noticed late. Seven daily copies plus a few weekly and monthly ones suits most business sites. The right number depends on how quickly you would notice data being corrupted or deleted rather than on storage cost alone.

Is a checksum the same as testing the backup?

No. A checksum confirms the file was not altered in transit or storage. It says nothing about whether the contents were complete when the file was created, which is why an archive test and a periodic restore are both needed.

Should I back up before every update?

Yes for anything significant: core upgrades, plugin or module changes, theme changes and database migrations. A pre-change snapshot is the fastest way back if the update goes wrong, and it is separate from your routine schedule.

How long should a restore take?

There is no universal answer, which is exactly why you should measure your own. Time a full restore to staging once, and use that figure when planning, because assuming half an hour and discovering it takes four changes how you respond to an incident.