Disaster recovery in a small team is usually one line in a document nobody has opened: backups are enabled. That statement is true and it is not an answer, because it says nothing about how old the data would be, how long the restore takes, or whether anyone has ever performed one.

The gap between having backups and being able to recover is where most outages become incidents. A backup that exists, is current, and has never been restored is a hypothesis, and the moment you test it is a bad moment to discover it was wrong.

Two numbers turn this from an opinion into a plan. How much data can you afford to lose, and how long can you afford to be down? Those are your recovery point and recovery time objectives. Until somebody in the business states them, every technical argument about backup frequency is unresolvable, because there is no criterion to argue against.

RPO and RTO in Plain Terms

Recovery point objective is how much data you can lose. Nightly backups mean an RPO of twenty-four hours: a failure at 5pm loses everything since the previous night. If that is unacceptable, the backup schedule is wrong, and no amount of care elsewhere compensates.

Recovery time objective is how long you can be down. This includes everything: noticing, deciding, provisioning, restoring, verifying and switching traffic back. Teams estimate the restore step and forget the other five, which is why real recoveries take several times longer than expected.

Both are business decisions rather than technical ones, and both cost money as they tighten. An RPO of five minutes needs continuous replication. An RTO of one hour needs infrastructure that can be rebuilt automatically, because nobody is going to configure a server by hand inside an hour under pressure.

The productive conversation is the trade. Tell the business what each level costs and let it choose, rather than picking a number in engineering and hoping it matches expectations that were never stated.

An Untested Backup Is Not a Backup

The failures that hurt are rarely the absence of backups. They are backups that turned out to be unusable.

Common causes, all of which are only visible on restore: the job has been failing silently for weeks because nobody watches success as well as failure; the dump captured the schema but not the data, or a subset of tables somebody added to an exclusion list; the file is encrypted with a key stored on the machine that died; the backup lives in the same account or region as the thing it protects.

That last one matters more than it used to. A backup in the same environment as production is protected against hardware failure and against nothing else. It does not survive an account compromise, an accidental deletion at the account level, or ransomware that reaches everything the same credentials can reach.

The only way to know a backup works is to restore it. Schedule it, do it quarterly at minimum, and time it. That timing is your real RTO, as opposed to the one in the document.

What Disaster Recovery Has to Cover

Data is the obvious part and rarely the slow part. The things that extend recoveries are usually the ones nobody listed.

The database, which everybody remembers. Uploaded files, which live somewhere separate and often have no backup at all. Configuration and secrets, which frequently exist only on the running machine. DNS and certificates, which cannot be recreated quickly if the account holding them is the thing you lost. The infrastructure itself, meaning the servers, networks and rules, which is fast to rebuild if it is defined as code and slow if it was clicked into existence.

And the knowledge of how it all fits together, which is the single largest determinant of recovery time in a small team. A system one person can rebuild from memory has a recovery time equal to that person’s availability, which is not a plan.

Write the inventory before the plan. Most teams discover at least one component with no backup at all while making the list, and finding it that way is considerably cheaper than the alternative.

A Plan That Fits on One Page

Long documents do not get read during an incident. Aim for something a tired person can follow at three in the morning.

It needs: who decides that recovery has begun, because hesitating over whether this counts as a disaster is a common source of delay. Where the backups are and how to reach them, including credentials that do not depend on the failed system. The restore steps in order, specific enough to follow without improvisation. How to verify it worked, which means a concrete check rather than the site appearing to load. And who to tell, internally and externally.

Keep it somewhere that survives the failure. A recovery plan stored only in the system it recovers is a recurring and entirely avoidable mistake.

The same reasoning applies to access. If one person holds the credentials for the hosting account, your recovery time is bounded by whether they answer the phone. Our Linux server hardening guide covers the access controls this depends on.

Proportionate, Not Perfect

A small team does not need a hot standby in a second region. The cost is real and the complexity introduces its own failure modes.

What most small teams need is considerably cheaper: backups in a separate account with credentials that production cannot use, a restore tested and timed on a schedule, infrastructure defined as code so it can be recreated without archaeology, and a one-page plan somebody has read.

That set covers hardware failure, accidental deletion, account compromise and ransomware, which is most of what actually happens. Everything beyond it is a decision about how much a further reduction in downtime is worth, and that is a question for the business rather than for engineering.

Mecanik reviews and builds this as part of our server security work. The first question is always the same, and it is not about technology: how long can you be down, and who decided that?

Related reading: Uptime SLAs That Mean Something , Software Supply Chain Security for Small Teams , AI Agents for Business: What They Cost and Where They Fail and Fintech Software Development UK: FCA, Rails and Cost .

Frequently Asked Questions

What do RPO and RTO mean? Recovery point objective is how much data you can afford to lose, so nightly backups imply an RPO of twenty-four hours. Recovery time objective is how long you can afford to be down, including noticing, deciding, provisioning, restoring, verifying and switching traffic back. Both are business decisions, and both cost more as they tighten.

Why is an untested backup not a backup? Because the failure modes are only visible on restore. Jobs fail silently for weeks when nobody monitors success as well as failure, dumps capture schema without data or omit excluded tables, encryption keys sit on the machine that died, and copies live in the same account as the thing they protect. Restore quarterly and time it.

Where should backups be stored? In a separate account or region, with credentials production cannot use. A backup in the same environment protects against hardware failure and nothing else: it does not survive an account compromise, an account-level deletion, or ransomware that reaches everything the same credentials can reach.

What do people forget to include in disaster recovery? Uploaded files stored separately from the database, configuration and secrets that exist only on the running machine, DNS and certificates held in an account that may itself be lost, infrastructure that was clicked into existence rather than defined as code, and the knowledge of how it fits together when only one person has it.

Does a small team need a hot standby? Usually not. The cost is real and the added complexity brings its own failure modes. Backups in a separate account, a tested and timed restore, infrastructure defined as code, and a one-page plan somebody has read will cover hardware failure, accidental deletion, account compromise and ransomware, which is most of what happens.