Backup and Disaster Recovery for Small Business: A No-Nonsense Guide

Here's a question I ask every small business owner I work with: If your main server died right now, how long until you're back up? And how much data do you lose?

Most people don't have a good answer. Some have a vague sense that "backups are running." A few have an external hard drive plugged in somewhere. Almost nobody has tested a restore. That's a problem, because the backup you've never tested is the backup that doesn't work when you need it most.

I run a 3-node Proxmox cluster with daily automated backups, offsite replication, and n8n-driven alerting. Every backup is verified. Every failure triggers a notification. This isn't theory — it's what I run in production every day. Here's how to build the same thing for your business.

Your "Backups" Probably Aren't Backups

Let me describe the backup situation I see at most small businesses:

• A backup job was configured once, years ago, by whoever set up the server
• Nobody has checked whether it's still running
• The backups go to a drive on the same machine, or maybe a NAS in the same room
• Nobody has ever tested a restore
• There's no alerting — if backups fail silently, nobody notices for weeks

This is not a backup system. This is a hope-based disaster recovery plan. And hope is not a strategy.

A real backup has three properties: it's automated (no human has to remember to run it), it's offsite (survives the building burning down), and it's tested (you've actually restored from it). If your backups don't meet all three criteria, you're exposed.

The 3-2-1 Rule

The gold standard for backup strategy has been around for decades, and it still holds up:

• 3 copies of your data (the original plus two backups)
• 2 different media types (local disk plus cloud storage, for example)
• 1 copy offsite (physically separate from the others)

In practice, for a small business, this looks like: your live data on the server, a local backup on a dedicated backup node or NAS, and a copy replicated to cloud object storage like Backblaze B2 or Wasabi. The local backup gives you fast restores for everyday issues (accidental deletion, bad update). The offsite copy is your insurance policy against catastrophic loss.

RTO and RPO: The Two Numbers That Matter

Disaster recovery planning comes down to two metrics, and you need to understand both before you design anything:

RPO (Recovery Point Objective) — How much data can you afford to lose? If your backups run nightly at 2 AM and your server dies at 4 PM, you've lost 14 hours of work. Your RPO is 14 hours. For some businesses, that's fine. For an e-commerce shop processing orders all day, it's catastrophic.

RTO (Recovery Time Objective) — How long can you be down? If it takes you 8 hours to rebuild a server from scratch, provision the OS, reinstall applications, and restore data, your RTO is 8 hours. That's 8 hours of no email, no file access, no customer-facing applications.

Think of RPO as "how much data you lose" and RTO as "how long you're down." Both cost money. The question is how much you're willing to spend to reduce them.

For most small businesses, a reasonable target is an RPO of 24 hours (nightly backups) and an RTO of 2-4 hours (restore from a recent backup to replacement hardware or a VM). If you need tighter numbers than that, you're looking at more frequent snapshots, hot standby servers, or replication — which costs more but is absolutely doable.

A Practical Backup Stack

Here's the exact stack I use and recommend for small businesses. Every tool is free and open source. The only cost is the offsite storage, which runs $20-50/month depending on how much data you have.

Server and VM Backups: Proxmox Backup Server or Restic

If you're running Proxmox (and if you're reading this blog, you probably are or should be), Proxmox Backup Server is the obvious choice. It does incremental backups of VMs and LXC containers with deduplication, so after the first full backup, subsequent runs only transfer what changed. It's fast, it's efficient, and it integrates directly with the Proxmox web UI.

If you're not on Proxmox, restic is the best general-purpose backup tool I've found. It handles encryption, deduplication, and retention policies out of the box, and it can push backups to local storage, SFTP, or cloud object storage directly.

My setup runs daily backups across all three Proxmox nodes, with one node designated as the backup target. Retention is 7 daily, 4 weekly, and 3 monthly snapshots. That gives me granular recent recovery plus long-term archive, without eating a terabyte of disk.

Offsite Replication: Rclone to Backblaze B2

Rclone is essentially rsync for cloud storage. It supports every major provider — Backblaze B2, Wasabi, S3, Google Cloud Storage, you name it. I use it to replicate backups from the local backup node to Backblaze B2 every night after the primary backup completes.

Backblaze B2 costs $6/TB/month for storage and $0.01/GB for downloads. For a typical small business with 500GB of backup data, that's about $3/month for storage. Even with a few terabytes, you're under $50/month. Compare that to the cost of losing your data entirely.

The rclone command is straightforward:

• rclone sync /backup/proxmox b2:your-bucket-name/proxmox --transfers 8 --fast-list

Add --bwlimit 50M if you need to avoid saturating your upload bandwidth during business hours. Schedule it for after midnight and let it run.

Automation and Alerting: n8n or Cron

The automation layer is what separates a backup system from a backup script someone ran once. You need two things: scheduled execution and failure alerting.

For scheduling, cron works fine for simple setups. A cron job at 2 AM that triggers the backup, followed by the rclone sync, is perfectly reliable. But I prefer n8n for the alerting layer — it's a self-hosted workflow automation tool that can monitor backup job outputs and send notifications via email, Slack, or webhook if anything fails.

In my setup, n8n watches for backup completion. If a backup doesn't finish within its expected window, or if any step returns a non-zero exit code, I get an alert immediately. I've caught disk-full conditions, network timeouts, and credential expirations this way — all before they became actual data loss events.

Restore Verification: The Part Everyone Skips

This is the one that matters most, and it's the one that almost nobody does. A backup file that can't be restored is worthless. You need to periodically verify that your backups actually contain valid, restorable data.

For Proxmox backups, this means doing a test restore to a temporary VM or container, verifying the data is intact, and then cleaning up. For restic, the restic check command verifies backup integrity, and restic mount lets you browse the backup contents as a filesystem.

I run automated restore verification weekly. A script spins up a temporary LXC container from the latest backup, runs a few basic health checks (can the database start? are the config files present? does the web application respond?), and then destroys the container. If any check fails, n8n fires an alert. The whole process takes about 10 minutes and costs nothing.

Common Disasters and How Each Is Handled

Hardware Failure

A disk dies, a power supply blows, a motherboard gives up. This is the most common disaster and the easiest to handle. Restore from the local backup node to new or replacement hardware. With Proxmox Backup Server, restoring a full VM or container takes minutes, not hours. RTO: under 1 hour if you have spare hardware. RPO: whatever your backup frequency is — typically the last 24 hours.

Ransomware

This is where offsite, immutable backups save you. If ransomware encrypts your production server and your local backup node (which it will try to do), your Backblaze B2 copy is untouched because it's authenticated separately and ideally uses B2's object lock feature for immutability. Wipe the infected systems, rebuild from the offsite backup. RTO: 2-4 hours. RPO: 24 hours. You lose a day of work instead of everything.

Accidental Deletion

Someone deletes a critical file, drops a database table, or runs rm -rf in the wrong directory. This is the most frequent "disaster" in practice. Local backups with daily retention make this a 5-minute fix — just pull the file or database from yesterday's snapshot. This is why granular retention (daily snapshots for a week) matters more than just having one big backup.

Natural Disaster

Fire, flood, theft — anything that takes out the physical location. Your local backups are gone along with the primary server. This is exactly what the offsite copy is for. Spin up a temporary VPS in the cloud, restore from B2, and you're running again while you deal with the physical recovery. RTO: 4-8 hours (limited by download speed and cloud provisioning). RPO: 24 hours.

What It Actually Costs

One of the biggest misconceptions about disaster recovery is that it requires enterprise budgets. Here's what this stack actually costs:

• Proxmox Backup Server — Free (open source)
• Restic — Free (open source)
• Rclone — Free (open source)
• n8n — Free (self-hosted)
• Backblaze B2 storage — $6/TB/month (~$3-30/month for most small businesses)
• Dedicated backup hardware — A used mini PC with a large drive, $100-300 one-time

Total ongoing cost: $20-50/month for most small businesses, plus a small one-time hardware investment. That's less than a single hour of downtime costs most businesses, and orders of magnitude less than what you'd pay for a managed backup service like Veeam or Datto.

When You Need Professional Help

This guide gives you a solid framework, but there are situations where you should bring in someone who does this regularly:

• Compliance requirements — If you're in healthcare (HIPAA), finance, or handle EU customer data (GDPR), your backup and recovery procedures need to meet specific standards. Getting this wrong has legal consequences.
• Complex environments — Multiple servers, database replication, distributed applications — the more moving parts, the more ways a restore can go wrong.
• You've never tested a restore — If the idea of restoring from backup makes you nervous, that's a sign you should have someone walk through it with you before you need to do it under pressure.
• You need tighter RTO/RPO — Getting below a 1-hour RTO requires hot standby infrastructure, automated failover, and careful testing. This is doable but not trivial.

I help small businesses design and implement exactly this kind of backup infrastructure — tailored to their specific needs, tested thoroughly, and documented so they understand what they have. If your current backup situation makes you uneasy, let's talk about it.