Backups that actually restore: a practical plan for small teams

A backup plan is only real if someone has restored from it recently. For a business without dedicated IT staff, it comes down to three habits: keep a written list of what you would actually need to reopen the doors, hold at least one copy that an attacker holding your admin password cannot reach, and put a restore test on the calendar like any other recurring obligation. Everything below is how to set those three things up, and most of it is a day of focused work rather than a project.

Start with the list, not the tool

Most teams buy backup software first and then discover, mid-incident, that half of what they needed was never in scope. Reverse the order. Open a document and write down everything that would have to exist again for the business to operate on Monday morning. Be concrete: not "the website", but the database, the uploaded media directory, the environment variables, the DNS zone, the TLS certificate arrangement, the payment provider keys and the deploy pipeline.

Four categories usually cover it. Data: databases, file storage, mailboxes, CRM records, accounting ledgers. Code: your repositories, which are usually safe on a hosted service but not always mirrored anywhere else. Configuration: server settings, infrastructure definitions, firewall and access rules, DNS, scheduled jobs. Access: who holds the accounts, where the recovery codes live, which registrar the domain sits with. That last one is the quiet killer. Plenty of recoveries stall not because the data was gone but because the only person who could log in to the hosting account had left the organisation.

Write the list once and review it whenever you add a system. If a tool holds data you would miss, it belongs on the list, even if it is a spreadsheet on someone's laptop.

RPO and RTO, without the jargon

Two numbers turn a vague worry into a decision you can act on.

Recovery point objective (RPO) is how much recent work you are willing to lose. If you back up nightly at 2am and the server dies at 5pm, you have lost a day of orders, invoices and customer messages. Your RPO is 24 hours. Ask the person who would have to re-enter that work whether 24 hours is acceptable. Often the answer for the accounting system is yes and for the order database is emphatically no.

Recovery time objective (RTO) is how long you can be down before the consequences become serious. Restoring a large database from cold archive storage over a slow connection is not a one-hour job, no matter what the marketing page implied. RTO is what tells you whether you need a warm standby or whether a slower, cheaper restore is fine.

Set both per system rather than for the business as a whole. Tightening RPO and RTO costs money and complexity, so spend it only where the loss is real. A simple grid keeps everyone honest:

Fill this in for your own systems and you have most of a disaster recovery plan already. It also makes vendor conversations short: you know what to ask for instead of comparing feature lists.

Think 3-2-1, then add what ransomware demands

The old rule still works. Keep three copies of anything you care about, on two different kinds of storage, with one off-site. The production copy counts as one, so in practice that is your live data plus two backups, one of them somewhere else entirely.

Ransomware changed the emphasis. Modern attacks look for backups first, because a victim with no clean copy has far fewer options. If your backup target is a network share the file server can write to, or a cloud bucket whose delete permission is held by the same credentials the application uses, it is not really a second copy. It is the same copy in two places.

So add one more requirement: at least one copy must be immutable. Object storage with object lock or write-once retention, a separate account with its own multi-factor authentication, and a pull-based schedule where the backup system reaches into production rather than production pushing out with delete rights. Add a genuinely offline copy if your data will fit on rotated encrypted drives that live somewhere other than the office.

Two more habits pay for themselves. Turn on alerting for backup failures and for backup jobs that succeed but finish suspiciously fast, which usually means they backed up nothing. And keep at least one restore path that does not require your primary identity provider, because if an attacker owns your single sign-on, an admin console you cannot log in to is not much help. This is the same territory covered in our work on security and compliance.

The question is not whether you have backups. It is whether anyone has restored from one this quarter.

Retention: how far back you can reach

Frequency answers "how much can I lose". Retention answers "how far back can I go". They are different problems, and retention is the one that saves you from slow-moving damage: a corrupted record, a bad migration, a quiet deletion that nobody notices for six weeks. If you only keep seven days, all your copies contain the same problem.

A grandfather-father-son pattern is enough for most small businesses: keep daily backups for a few weeks, weekly backups for a few months, monthly backups for a year or more. Then check that shape against three constraints. Legal and tax obligations may require certain records for a set number of years, so confirm what applies to you in your province and industry. Privacy rules push the other way, because personal data you no longer need should not sit in an archive forever, and a deletion request has to reach the backups too, usually through a documented policy that ages them out. Cost pushes the same direction, since long retention on hot storage is expensive while cold tiers are cheap to store and slow to read.

Write the retention decision down alongside the RPO and RTO grid, including which archives contain personal data and when they expire. Storage design and lifecycle rules sit close to how the rest of your cloud infrastructure is put together, so it is worth settling both at once.

Test the restore, on a schedule

This is the step almost everyone skips, and the one that separates a plan from a folder of files. Restores fail for dull reasons: an encryption key nobody recorded, a database dump written with a version that will not import, a backup that contains the application but not the uploads directory. You want to find those on a Tuesday afternoon, not during an outage.

Run this cycle:

1. Pick a target from your list and a specific point in time, such as "the orders database as of last Thursday".
2. Restore it into a scratch environment that is fully separate from production. Never test by restoring over live data.
3. Verify the content, not just the exit code. Open a record you recognise, check row counts, load a file, confirm the most recent entries are actually there.
4. Time it, from the decision to restore through to a working system, and compare that against your stated RTO.
5. Write down what went wrong or was confusing, fix it, and update the runbook the same day.

Do a small file-level restore monthly, a full database restore quarterly, and once a year hand the runbook to someone who did not build the system and let them try it unaided. That last exercise finds the assumptions nobody knew they were making.

Write a runbook a stranger could follow

Recovery documents get written for the person who wrote them, which is exactly the person who may be unreachable when it matters. Aim the runbook at a competent stranger under stress. Keep it short, ordered and specific, and store it outside the systems it recovers: a printed copy, plus a document in a service unrelated to your main provider.

It should answer, in order:

1. Who decides that this is an incident, and who they call next.
2. Where each backup lives, with the exact account, region, bucket or device named.
3. How to obtain credentials and encryption keys, and who holds the break-glass access.
4. The restore steps for each system, in the order dependencies require, with real commands rather than descriptions.
5. How to verify success, including what "working" looks like to a customer.
6. Who to notify: staff, customers, your payment provider, and any privacy regulator if personal data was exposed.

Add a page listing what changed after each test, so the document ages with the system instead of drifting away from it.

How OlDevs helps

We have built and maintained production systems from Vancouver since 2014, and recovery design is part of how we hand work over: one accountable team, a working demo every week, and clients owning all code, designs, accounts and IP, so nothing about your recovery depends on us staying in the picture. Typical engagements start with an inventory and an RPO and RTO grid, then automated backups with immutable off-site copies, a scheduled restore test that runs whether or not anyone remembers, and a runbook written for the person who will actually be holding it. We do the same work when we design your data and database layer from the outset, because retention and restore paths are far cheaper to get right early.

If you want an honest look at what would happen to your business if a server disappeared tomorrow, request a quote. We reply to every enquiry within one business day.