Backup & Restore Test Log

What this tool does

CM8-120 is a log of two different things kept deliberately side by side: the backup runs you take, and the restore tests that prove those backups are worth having. It works out how often your jobs succeed, which systems have never been restored, which restore tests have gone stale, and which restores take longer than the business can afford. It then prints all of that as a report you can hand to a board, an auditor, an insurer or a client.

Everything runs inside this one file. There is no account, no upload and no network request of any kind. That matters here: a list of what you back up, where the copies live and which systems are unprotected is exactly the document an attacker would most like to read.

A backup job is not a restore

This is the whole reason the tool exists, so it is worth being blunt about it.

A backup job reporting success means the backup software finished writing something without raising an error. It does not mean the data is complete. It does not mean the files are readable. It does not mean the database is consistent, that the encryption key still exists, that the media can still be mounted, that the restore target still exists, or that anybody in the building knows the procedure. Every one of those failures is common, and every one of them is invisible until the day you need the data.

A restore test means somebody took a backup, put the data back somewhere, and looked at it. That is the only evidence that recovery works, and it only covers what was actually restored.

What to log, and when

One row is one backup run. Log the runs that matter — the weekly full, the monthly archive, the failures — rather than every incremental of every night; a log nobody maintains is worse than none. For a nightly job, a monthly summary row plus a row for every failure is usually the right level.

When you carry out a restore test, attach it to the backup run you restored from by ticking the restore test box on that row and filling in the date, result and duration. That keeps the evidence with the thing it is evidence about.

Always log a failure, and always log a job that did not run at all. "Did not run" is the outcome people leave out, and it is the one that produces the gap in a retention chain that nobody discovers until a restore is attempted across it.

Backup types and what they give back

• Type — What it copies — What a restore needs
• Full — Everything, every time — One backup
• Incremental — Changes since the last backup of any kind — The last full plus every incremental since — one missing link breaks the chain
• Differential — Changes since the last full backup — The last full plus one differential
• Snapshot — Point-in-time copy of a volume or machine — The snapshot, and usually the platform that made it
• Continuous — Replicated or journalled as data changes — The replica, which will faithfully replicate a deletion too
• Archive — A long-term retention copy — The media, and hardware that can still read it

Type matters for recovery time as much as for storage. An incremental chain is quick to write and slow to restore, and the more links it has the more chances one of them is missing. Continuous replication protects against hardware loss but not against deletion, corruption or encryption by an attacker, because it copies those faithfully within seconds — which is why a retained, immutable copy is a different control from a replica, not a duplicate of it.

The backup success rate

The plain rate counts jobs that finished cleanly against jobs logged:

Partial runs, failed runs and runs that did not happen all count against it. That is deliberate: a run that skipped two of eleven servers did not back up eleven servers.

With count backups on never-restore-tested systems as failures switched on — which is the default — the headline tile uses a stricter measure:

The gap between the two numbers is the honest measure of how much of your estate is assumed rather than demonstrated. Switch the setting off to see the raw job figure; the tile description always states which basis is in force, and the report prints it.

Restore testing and the interval

Set an interval in Settings — 90 days suits many organisations, monthly for anything critical, annually at the outside for archives. For each system the tool finds the most recent restore test whose result was successful, and works from that:

Note what does not count. A partial restore does not reset the clock, a failed restore does not reset the clock, and a successful backup certainly does not. Only a restore that produced complete, usable data counts, because only that answers the question being asked.

A system tested but never successfully is shown separately from one never tried: the first has a known defect to fix, the second an unknown risk to measure.

Recovery objectives — RPO and RTO

Two numbers describe what recovery has to achieve, and they are frequently confused.

• Recovery point objective (RPO) — how much recent work you can afford to lose, measured in hours before the failure. It is set by how often you back up. A nightly backup means an RPO of up to 24 hours, whatever anybody would prefer.
• Recovery time objective (RTO) — how long the business can be without the system, measured from the failure to the service being usable again. It is set by how fast you can restore, which includes finding the media, building a target, restoring, checking and switching over.

Restore duration is entered in minutes because that is how people time a restore. Objectives are in hours because that is how the business talks about them. The tool converts before comparing — it never puts minutes and hours on the same side of an equation:

The second condition is not decoration. A restore that came back in two hours against a four-hour objective but left the calendars behind has not met the objective; it has failed inside the time allowed. The "recovery time against objective" chart draws those in red whatever the elapsed time.

Record the recovery point actually achieved too — how old the restored data turned out to be. It is regularly worse than the schedule implies.

Off-site, immutable and encrypted copies

Three checkboxes cover three different failures, and one does not substitute for another.

• Off-site — a copy somewhere the live system is not. It answers fire, flood, theft and the loss of a building. A disk beside the server is not an off-site copy, and neither is a replica in the same rack.
• Immutable or write-once — a copy that cannot be altered or deleted for its retention period, including by somebody holding administrator credentials. It answers deliberate destruction, now a routine part of the attacks that make backups matter.
• Encrypted — it answers a copy falling into the wrong hands, and creates its own risk: if the key is lost, the backup is gone. Store recovery keys somewhere that survives the failure you are protecting against, and test that too.

A system with no off-site copy is flagged as at risk whatever its job success rate, because one event at one location can take the live data and every copy of it in the same movement.

Reading the systems-at-risk table

A system appears in that table if any of four things is true, and the reason column says which:

• no restore has ever been attempted, or none has ever fully succeeded;
• the last successful restore test is older than the interval;
• no off-site copy is recorded on any run for that system;
• the last successful restore took longer than its recovery time objective.

Work down that table, not across the backup report. Every screen obeys the filters, but the days since a restore test are always measured against today — a test does not become fresh again by narrowing a date range.

Settings and what they change

Nothing here is hard-coded to a jurisdiction or an industry. The restore test interval and the two default objectives are yours to set, and a per-record objective overrides the default where one system is more demanding than the rest. The strict success-rate switch changes only the headline tile and its stated basis, never the underlying records.

What this tool cannot do

It cannot see your systems. It does not start a backup, read a backup file, verify a checksum, check that a retention chain is complete, confirm that an encryption key still exists or that a restore produced anything usable. It sends no reminder to anybody when a test falls due.

Everything in it is what somebody typed, so a row saying a restore succeeded is a claim worth exactly as much as the person who made it. The most useful discipline is to write the issues found even when the test passed — "recovered in full, but the runbook was wrong about the network configuration" is the sentence that makes the next recovery an hour shorter.

Printing and sharing

Print Report produces a report from whatever the current filter shows: header, the six headline figures, all four charts, the systems-at-risk table, the per-system summary, the full log and your closing notes. Print to PDF to circulate it. The scope line under the title states the filter in force, so clear the filters before issuing anything described as covering the whole period. Treat the output as confidential: it is a map of where your data is and where it is not protected.

Saving your work

Records, settings and the report header are written to this browser's local storage as you type, and the toolbar shows the time of the last save. That storage belongs to one browser on one computer: another browser, a private window, a second machine or a clean-up tool that clears site data will not have it.

Treat Export .json as the real save — one file containing everything, which Import .json restores anywhere. Export CSV gives you the log for spreadsheet work and includes every filtered record, not only those drawn on screen. Reset asks twice, then erases everything this tool has stored. There is no undo — and keeping the backup log's own backup only in the browser that holds it would be a poor advertisement for the discipline.

Accuracy & disclaimer

This tool records what you enter and calculates from it. It cannot tell whether a backup was really taken, whether a restore really worked, whether the data restored was complete, or whether the objectives entered reflect what the business actually needs.

Retention periods, encryption expectations, evidence requirements and testing frequency differ by country, sector, insurer and contract. This is an internal record-keeping and calculation aid — not legal advice, not a compliance assessment, not a certification, and not a substitute for a tested and rehearsed recovery plan.