Ask a small team if they have backups and the answer is always yes. Ask when they last restored one, how long it took, and who else knows how, and the room goes quiet.

A backup you've never restored isn't a backup. It's a hope with a cron job.

Disaster recovery sounds like something for banks with a dedicated team and a second data centre. It isn't. A small team needs a plan that fits on a couple of pages, uses tools you already have, and has actually been tested. Here's how I'd build one, step by step.

Step 1: name your disasters

"Disaster" is vague. Make it concrete. For most web apps, the realistic list looks like this:

• Someone deletes or corrupts data. A bad migration, a buggy job, a DELETE without a WHERE. By far the most common.
• A server dies or becomes unreachable.
• A cloud region or service has a major outage. Rare, but it happens.
• Credentials are compromised, and an attacker (or ransomware) deletes or encrypts what they can reach, including backups in the same account.
• A person is unavailable. The one who knows the server password is on a plane.

Notice that only one of these is about hardware. Most disasters are about mistakes, access and people.

Step 2: RPO and RTO, in plain words

Two acronyms do most of the work in disaster recovery, and they're simpler than they sound.

• RPO (Recovery Point Objective): how much data can you afford to lose? If you back up once a night, your RPO is up to a day of data. Everything entered after the last backup is gone.
• RTO (Recovery Time Objective): how long can you afford to be down? From "it's broken" to "users can work again".

Don't decide these alone. Ask the business: "If we lost today's payments and contract changes, what happens?" "Can staff work for an afternoon without the system? A day?" The answers set your targets, and your targets set your budget. A tighter RPO means more frequent backups or continuous replication; a tighter RTO means more automation and spare capacity ready to go.

Step 3: back up the right things, in the right places

The classic 3-2-1 rule still holds up: three copies of your data, on two different kinds of storage, with one copy off-site. In cloud terms, I'd translate it like this:

• The database is the crown jewel. On AWS RDS, turn on automated backups with point-in-time recovery, which lets you restore to a specific moment within the retention window. That's your best friend for the "bad migration at 2:14pm" disaster.
• Files (uploads, signed documents, generated PDFs) usually live in object storage like S3. Turn on versioning so overwritten or deleted files can be recovered.
• A copy somewhere else. Regular database dumps or snapshot copies to another region, and ideally another account with separate credentials. If one set of keys can delete production and every backup, you have one copy, not three.
• Configuration and secrets. The .env values, server configuration, DNS records and certificates. Code is in Git; these often aren't, and rebuilding them from memory is slow.

For Laravel apps, a package like spatie/laravel-backup can dump the database and files to a separate disk on a schedule, and notify you when a backup fails, which matters more than people think. Silent backup failures are a classic.

Step 4: write the runbook before you need it

At 2am during an outage, nobody thinks clearly. A runbook is a document that thinks for you. Keep it short, concrete, and somewhere you can reach when production is down (not only on the server that just died).

For each disaster from step 1, write:

1. How we notice: which alert, which symptom.
2. Who decides: who can declare an incident and approve a restore.
3. The steps: exact commands and console screens, in order. "Restore RDS to a point in time, as a new instance named...", "Point the app's DB_HOST to it", "Clear config cache and restart queue workers".
4. How we check it worked: log in as a test user, check the latest records, confirm jobs are processing.
5. Who we tell: staff, customers, and what we say.

Step 5: drill it

This is the step that separates a plan from a document. Pick a quiet day a few times a year and actually restore:

• Restore last night's database backup to a fresh instance. Time it. That's your real RTO for that scenario, and it's often longer than anyone guessed.
• Check the data: is it complete, is it the right date, do the files referenced in the database exist in storage?
• Point a staging copy of the app at it and click around.
• Have a different person run it each time, using only the runbook.
• Fix every gap you find in the runbook the same day.

Drills find the boring problems that ruin real recoveries: a backup that only contains half the tables, a restore that needs a permission nobody has, a missing environment variable, a database too large to restore within your target.

Step 6: protect access like it's data

Many disasters are really access problems. A few basics go a long way:

• MFA on every cloud, registrar, DNS and Git account.
• Credentials in a shared password manager, not in one person's head or browser.
• At least two people with admin access to everything critical, including the domain registrar, which is easy to forget until a renewal fails.
• A documented "break glass" account for emergencies, stored securely and tested.
• Least-privilege access for day-to-day work, so a leaked deploy key can't delete backups.

The small-team plan on one page

None of this needs a big budget. It needs an afternoon to write, a few hours to drill, and the discipline to repeat it.

When did your team last restore a backup for real, and what surprised you when you did?