Don't Lose Your Data: Backups and Disaster Recovery for Small Businesses

Most businesses think about backups exactly once: right after they lose data. A bad migration wipes a table, a server dies, an account gets compromised, someone deletes the wrong thing, and suddenly the question is not "do we have a backup" but "does the backup actually work." Those are very different questions, and far too many companies discover the gap between them at the worst possible moment.

This guide is about closing that gap before you need to. It covers what to back up, how to automate it, how to recover quickly, and the one discipline that separates real protection from false comfort: testing that your backups restore. The examples assume a typical small-business stack with a database and some files, on infrastructure like Vercel plus a managed database.

Start with the uncomfortable truth. The only thing worse than having no backup is having one you believe in that does not actually restore. Backups fail quietly: a job that has been erroring for months, a dump that is corrupt, a process that captured the database but not the uploaded files. Until you have restored from a backup and watched the system come back, you do not have a backup, you have a hope. Everything else in this guide is downstream of that.

The database is the obvious piece, but a working recovery needs everything required to stand the system back up. That means the database, the user-uploaded files and assets (which often live separately and get forgotten), your configuration and secrets stored securely, and your code, which should already be safe in git. Walk through what it would take to rebuild from nothing and make sure each piece is covered, because a database restored without its files is only half a recovery.

Manual backups get skipped, so automate them on a schedule and verify they ran. Then follow the 3-2-1 rule: at least three copies of your data, on two different kinds of storage, with one copy offsite. Critically, keep at least one copy in a separate account or location from production, because if an attacker or a mistake compromises your main account, backups sitting in that same account go down with it.

# nightly logical backup, shipped offsite to a separate account
pg_dump "$DATABASE_URL" | gzip | aws s3 cp - "s3://backups-offsite/db/$(date +%F).sql.gz"

A nightly dump means a bad event at 4pm can cost you the whole day's data. Point-in-time recovery (PITR), offered by most managed databases, lets you restore to any moment, the second before the bad migration ran. For anything holding real business or customer data, PITR is the difference between losing minutes and losing a day, and it is usually a setting you simply turn on. Keep the periodic dumps too, as a separate, portable copy you control.

Two simple questions size your whole strategy. Your Recovery Point Objective (RPO) is how much data you can afford to lose, measured in time, an hour, a minute, none. Your Recovery Time Objective (RTO) is how long you can be down while you recover. A storefront taking orders has a very different answer than an internal tool, and being honest about both tells you how often to back up and how fast your restore needs to be, which in turn drives the cost. Decide these deliberately rather than discovering them during an outage.

This is the step everyone skips and the one that matters most. Periodically restore a backup into a scratch environment, time how long it takes, and verify the data is intact and complete. This proves the backup works, surfaces the missing pieces (the files you forgot, the step that fails), and turns recovery from a panic into a rehearsed procedure. A restore you have practiced is fast and calm, one you have never tried is a gamble at the worst moment.

Backups need protection too. Keep them separate from production credentials, and make them immutable or versioned so that ransomware or a compromised account cannot simply delete or encrypt them, a backup an attacker can erase is no backup at all. For everyday accidents, soft deletes and short-retention snapshots let you undo an "oops" without a full restore. Defending the backups themselves is as important as making them.

When something fails, you do not want to be inventing the recovery process under pressure. Write a short runbook ahead of time: what to restore, from where, in what order, who is responsible, and how to verify success. Rehearse it during a test restore. The difference between a thirty-minute recovery and a lost day is usually not the backup, it is whether someone knew exactly what to do.

• Treat an untested backup as no backup, restoring is the only proof.
• Back up the database, the uploaded files, secured config, and code.
• Automate backups, verify they ran, and follow 3-2-1 with one copy in a separate account.
• Enable point-in-time recovery for anything holding real data.
• Define your RPO and RTO honestly, and let them drive frequency and cost.
• Test restores on a schedule, in a scratch environment, and time them.
• Make backups immutable or versioned so they cannot be deleted by an attacker.
• Write and rehearse a recovery runbook before you need it.

How often should I back up my data?

Often enough to meet your Recovery Point Objective, which is how much data you can afford to lose measured in time. A nightly dump means a failure late in the day can cost you the whole day, which is fine for some internal tools and unacceptable for a store taking orders. For real business or customer data, enable point-in-time recovery so you can restore to almost any moment, and keep periodic dumps as a separate portable copy as well.

What is the 3-2-1 backup rule?

Keep at least three copies of your data, on two different types of storage, with one copy offsite. The point is to avoid a single failure taking out both your data and its backup. The most important part for small businesses is keeping at least one copy in a separate account or location from production, because a compromised or mistaken main account can otherwise wipe the backups sitting alongside it.

Why test restores if the backups are running?

Because backups fail silently and you only find out when you try to use them. A job can error for months, a dump can be corrupt, or a process can miss the uploaded files while capturing the database. Restoring into a scratch environment proves the backup actually works, reveals the missing pieces, and turns recovery into a rehearsed, timed procedure instead of a gamble. Until you have successfully restored, you have a hope, not a backup.

What are RPO and RTO?

They are the two numbers that size your backup strategy. Recovery Point Objective is how much data you can afford to lose, expressed as a time window, while Recovery Time Objective is how long you can be down during recovery. Answering both honestly for your business, an order-taking store tolerates far less than an internal report, tells you how frequently to back up and how fast your restore must be, which together determine the approach and its cost.

How do I protect backups from ransomware?

Keep them out of reach of whatever could compromise production. Store backups in a separate account or location from your main system, and make them immutable or versioned so they cannot be deleted or encrypted even if an attacker gains access, because a backup that an intruder can erase offers no protection. Combined with tested restores and a runbook, immutable offsite backups are what let you recover from an attack instead of paying a ransom.

If your business runs on data you cannot afford to lose, tell me what you are running on and I will give you a straight read on whether your backups would actually save you.