What should a disaster recovery drill include when you have no ops team?

Why run a disaster recovery drill if restore tests already pass?

Restore tests prove the technology works. A drill proves the people and the process work too: that someone can find the runbook, has the access they need, makes the right decisions under time pressure, and tells customers what is happening.

Real recoveries often fail on those steps rather than on the restore.

Veeam's Data Trust and Resilience Report 2026 found that only 28% of organisations hit by ransomware fully recovered all affected data, despite 90% being confident beforehand. Drills are how you find out which group you are in before it matters.

Which disaster recovery scenarios should a small SaaS rehearse?

Start with the most likely scenario, a bad migration or a deleted table, then rehearse a broken release, leaked credentials, ransomware and, last, a region problem.

Start with the first scenario. It is the most likely, and it exercises the restore path you depend on most.

Who does what during a disaster recovery drill?

A drill needs four roles, a lead, an operator, a scribe and a communicator, and the operator should not be the person who wrote the runbook.

• Lead: makes decisions and keeps time. Usually the CTO.
• Operator: follows the runbook and runs the commands. Ideally not the person who wrote it.
• Scribe: writes down every step, time and problem as it happens.
• Communicator: drafts the customer and internal messages you would send for real.

In a team of five, one person may hold two roles. The point is that the operator is not the only person who knows how, so the drill tests the runbook rather than one person's memory.

How do you run a disaster recovery drill, step by step?

Run the drill in an isolated copy: announce the scenario, start the clock, follow the runbook, verify the data and the app, draft the customer message, then stop the clock and clean up.

1. Agree the scenario, the recovery target and a time box, such as half a day.
2. Confirm everything happens in an isolated copy. Production is never touched.
3. Start the clock and announce the scenario, for example: the orders table was dropped at 10:00.
4. The operator follows the runbook to restore to a point before the incident.
5. Check the data and bring a test copy of the application up on the restored database.
6. The communicator drafts the status update you would send customers.
7. Stop the clock when the application works and the data is verified.
8. Clean up the restored resources.

The RDS restore guide covers the technical steps for the most common scenario.

How do you protect AWS backups from ransomware or a malicious delete?

Make sure someone with your production credentials cannot also delete your backups.

Common measures on AWS include keeping backup copies in a separate account, restricting who can delete recovery points, and using AWS Backup Vault Lock, which can prevent recovery points from being deleted or changed before their retention period ends. Test that a restore from those protected copies works as part of the drill.

What should you write down after a disaster recovery drill?

After a drill, write down the total and per-step times against your target, every point where someone got stuck, runbook fixes with owners, and the date of the next drill.

• The total time against your recovery target, and the time for each step.
• Every point where someone was stuck, guessed or needed access they did not have.
• Runbook changes needed, with an owner and a date.
• Whether the customer message was ready in time.
• The date of the next drill. Once a year is a sensible minimum.

Keep the write-up with your restore test reports. Together they are strong evidence of recovery readiness, as described in the backup proof guide.

Is your small team ready for a disaster recovery drill?

Tick each item that is in place today.

How long should a disaster recovery drill take?

Plan for half a day for a small team's first drill, including setup and the write-up.

The recovery itself should fit inside your recovery time objective. If it does not, that is the most useful result the drill can give you. Later drills are usually faster, because the runbook gets better each time.

What is a tabletop exercise, and is it enough?

A tabletop exercise is a discussion where the team walks through a scenario step by step without touching any systems.

It is a cheap way to find gaps in roles, access and communication, and a good warm-up before a technical drill. It is not enough on its own, because it cannot reveal that a restore takes three times longer than expected or that a key permission is missing.