A data backup strategy for a small business, in plain terms

Ask a small business whether it backs up its data and the answer is almost always yes. Ask what would be lost if the main system died at four o'clock this afternoon, and how long it would take to be trading again, and the answer is usually a pause. Those two questions are the entire subject. Everything else is product selection.

The useful part is that both questions already have precise names, borrowed from contingency planning rather than invented by vendors, and once you can put a number on each the shopping decision mostly makes itself.

The two numbers that define a backup strategy

NIST's Contingency Planning Guide, SP 800-34 Revision 1, defines them plainly. The Recovery Point Objective is "the point in time, prior to a disruption or system outage, to which mission/business process data can be recovered", and it is described as "a factor of how much data loss the mission/business process can tolerate during the recovery process". The Recovery Time Objective "defines the maximum amount of time that a system resource can remain unavailable before there is an unacceptable impact".

In ordinary language: RPO is how much work you are willing to lose, and RTO is how long you are willing to be down. They are different questions and they buy different things.

A nightly backup means an RPO of up to twenty four hours. That is a decision, and it is a perfectly reasonable one for a business whose data changes slowly. It is an unreasonable one for a business taking orders all day, and the point of naming it is that it stops being an accident of whatever the software defaulted to.

Three copies, two media, one elsewhere

The familiar rule of thumb is three copies of anything important, on two different kinds of storage, with one of them somewhere else. It survives because it defends against three different failures at once: the file being wrong, the device being dead, and the building being unavailable.

NIST puts the offsite half less memorably and more usefully, noting that "it is good business practice to store backed-up data offsite" and listing what to weigh when choosing where. The criteria are worth reading as a checklist because most small businesses only ever consider the last one.

• Geographic area: how far away it is, and whether the same disaster could take out both sites.
• Accessibility: how long retrieval takes, and the hours during which that is possible.
• Security: whether the transport and the facility meet the requirements of the data itself.
• Environment: temperature, humidity, fire prevention and power at the storage site.
• Cost: shipping, operational fees and any response and recovery services.

Substitute a cloud region for the warehouse and the list still works. "Could one incident reach both copies" is the question, and a second copy in the same account with the same credentials frequently fails it.

The most expensive mistake: retention is not backup

Plenty of small businesses believe they are covered because their email and files live in a managed cloud suite. Sometimes that is true. Often it is a misreading of what the tool claims to do.

Google's own Vault documentation says it directly: "Vault isn't a data archive." It is a governance and eDiscovery product. It also documents that once data is purged at the end of a retention period "it can't be recovered by users or admins", and that an export made from it "is available in Vault for 15 days, then the export is deleted". Those are the properties of a legal hold tool, not of a backup.

The general lesson is worth more than the specific product. Read what your provider says it guarantees rather than what the category name implies. Sync is not backup either, and for a specific reason: sync is excellent at propagating a deletion or an encryption event to every copy, quickly and faithfully.

Full, incremental, and why the difference matters at 4pm

Backups come in a full flavour and an incremental one, where the incremental captures only what changed. NIST notes the trade honestly: incremental backups "afford more efficient use of storage media, and backup times are reduced", but "to recover a system from an incremental backup, media from different backup operations may be required".

That sentence is where RTO gets decided in practice. A backup scheme optimised purely for cheap nightly runs can be genuinely slow to restore from, because the restore has to walk a chain. If your RTO is four hours, that chain is part of the four hours, and almost nobody has measured how long it takes.

The rehearsal is the whole thing

A backup that has never been restored is a hypothesis. The single highest value hour available here is to pick a normal Tuesday, restore something real to a scratch location, and time it.

• Restore one important file and confirm it opens and is current.
• Restore a whole system or database to a separate location, not over the top of production.
• Write down how long it took, then compare that number honestly against the RTO you claimed.
• Check who can actually perform the restore. If it is one person and they are on leave, the RTO is fiction.
• Repeat after any significant change to the systems being protected.

The last two catch more real failures than the technology ever does. Backups usually do not fail because the software was bad. They fail because a new system was added and never included, or because the only person who knew the procedure left.

A reasonable starting point

For a business without a formal plan, a defensible first version is short. List the systems that would stop trading if they vanished. Assign each one an RPO and an RTO in plain hours. Ensure every one of them has a copy that is not reachable from the same login as the original. Then rehearse one restore, and put the next rehearsal in the calendar.

This is deliberately not a product recommendation, because the correct product falls out of the numbers once the numbers exist, and choosing tooling before the numbers is how businesses end up paying for continuous replication of data they would happily lose a day of.

It is also worth knowing where the data actually lives before protecting it. Businesses running critical operations out of a spreadsheet have a backup problem that is really a systems problem, described in when a stock spreadsheet starts costing more than it saves, and the same is true of the pattern in the three tools training centres rebuild in spreadsheets.

The honest limits

None of this makes a business resilient on its own. Backups address data loss. They do not address a supplier going down, a payment processor freezing an account, or a key person being unavailable, and a business continuity plan is a broader document than this.

There is also a real cost to overdoing it. Continuous replication, long retention and frequent testing all cost money and attention, and a small business that buys enterprise recovery guarantees for data it could reconstruct from email in an afternoon has spent badly. The point of writing the two numbers down is as much about permission to spend less as it is about spending more. If the honest RPO is a week, say so, and buy accordingly. Choosing where the system should be more robust is the same judgement described in scaling a web app in the right order: the discipline is doing the cheap correct thing first and leaving the expensive thing until a number demands it.