The Tuesday Test: Proving One Backup Before You Need It

Most small teams have a backup schedule. It sits in a runbook, a vendor portal or the head of IT's head. What is often missing is the boring proof: a restore that someone actually completed, timed, checked and wrote down. Until that happens, your backups are just files with a reassuring label.

A half-day drill will not prove you can survive everything. It will prove something more useful: that one critical system can be brought back by the small team you already have, using the access and documentation you have now, without turning the day into an incident. That is the version worth doing.

Choose one system that would ruin the week

Do not scope 'all backups'. Scope one system. Pick the one whose loss would stop work quickly: the finance shared drive, the helpdesk, the CRM, the payroll export, the document store behind client work. Then write down why it matters and who owns it.

A useful test: if it vanished at 10am on a Tuesday, who would notice first, and what would they do? If the answer is 'everyone' and 'panic', it is a candidate. Keep the scope narrow enough to finish. You can add systems later.

Set the rules before anyone clicks restore

A drill needs a sandbox, not a gamble. Decide where the restore will land: an isolated environment, a test tenant, a separate drive, a clean folder. Make sure restoring there cannot overwrite live data or trigger old workflows. Check licensing and permissions in advance.

Then agree the guardrails:

• Who can approve the restore?
• Who holds the encryption keys or recovery passwords?
• Which users will validate the result?
• Who tells the rest of the business what is happening?
• What time does the drill stop, even if it is not finished?

That last one matters. A half-day drill that overruns is just an outage with better branding.

A workable half-day agenda

Leave slack. The point is not a perfect schedule; it is a realistic one. If the restore takes four hours, you want to know that before a real incident, not during one.

Test the vendor's claim, not their marketing

If your backup comes bundled with a SaaS product, 'backup included' can mean several things. Before the drill, ask:

• Which data is covered, and which objects are excluded?
• How often does it run, and what retention is actually switched on?
• Can you restore a single file, a mailbox, a database, or only the whole tenant?
• Where is the backup stored, and who can access it?
• How long does the vendor take to start a restore, and what do they need from you?
• What does the vendor not restore, such as permissions, integrations or metadata?

Get the answers in writing, then test the bits you can. A support article is not a recovery plan. A successful restore of a sample file is a start; a successful restore of the thing your team actually needs is better.

Time the ugly bits

The clock should start when you decide to restore, not when the progress bar appears. Record:

• time to find the right backup and recovery point;
• time to get access to the restore console;
• time to restore the data;
• time to fix permissions, links, integrations or missing configuration;
• time for a real user to confirm the system is usable.

Those middle steps are where drills usually fail. The restore completes, but the shared drive has broken shortcuts, the CRM has no email connection, or the helpdesk cannot see historical tickets because the search index is still rebuilding. Write those down. They are the useful findings.

Define 'done' before you start

'Restore succeeded' is a vendor message, not an acceptance test. Agree what usable means for this system. Examples:

• A named user can log in and open three representative files.
• A sample record can be found, edited and saved.
• Permissions look right for two different roles.
• Integrations send a test notification.
• The data owner signs off the sample.

Keep the test small and repeatable. You are not rehearsing every workflow; you are checking that the recovered system is fit for the next working day.

Write it down so the next person can repeat it

The evidence pack does not need a glossy certificate. It needs to be honest and legible. A one-page summary plus attachments will do:

• date, scope and system version;
• backup ID or recovery point used;
• restore location and who approved it;
• timeline with actual times;
• what worked, what did not, and what you skipped;
• acceptance sign-off from the data owner;
• screenshots or logs of the key steps;
• vendor ticket references;
• next actions with owners and dates.

Store it with the runbook, not in someone's inbox. If a client, insurer or auditor asks, you can show the drill, the result and the follow-up. That is more convincing than a badge.

After the drill, fix one thing

A drill that produces a long list and no change is theatre. Pick the highest-risk finding and fix it while the detail is fresh. Update the runbook. Add the missing permission. Chase the vendor about the excluded metadata. Then book the next drill, even if it is only a single-file restore.

The goal is not to become a disaster recovery team. It is to make sure the small team you already have can finish the restore, explain what happened and hand the evidence to the next person. That is a backup you can trust.