Cloud & Infrastructure / Deep Dive
BACKUPS
A backup is only as good as the last successful restore. We build 3-2-1 systems with off-site copies, ransomware-resistant snapshots, and a tested recovery path.
If you've never restored from it, you don't have a backup
Most businesses think they have backups. What they actually have is one of three things: a single nightly snapshot on the same host that holds the live data, a sync-job to a cloud folder that mirrors deletions and ransomware encryption back to the destination, or a six-month-old backup nobody has ever attempted to restore. None of these survives the first real incident. A real disaster-recovery setup follows the 3-2-1 rule — three copies of the data, on two different media, with one copy off-site — and every backup target is verified by an actual restore, not just a green checkmark from the backup software. This guide covers the architecture and the trade-offs that decide which version of it is right for your business.
Copies of the data
3, on 2 media, 1 off-site
Restore test cadence
Quarterly or better
Snapshot retention
Daily / weekly / monthly
What a real backup architecture covers
A serious backup setup is not one product — it is a layered set of protections, each one defending against a different failure mode. Together they cover the four scenarios that take a business offline: hardware failure, accidental deletion, ransomware encryption, and full-site loss.
- Local snapshots (fast restore for accidental deletions)
- Off-site replication (survives a fire, theft, or site loss)
- Immutable / WORM copies (survives ransomware)
- Application-aware backups (databases, mail, ERP)
- Documented and tested restore procedures
What gets backed up, in priority order
Not everything needs the same protection. The recovery objective for the production database is hours; the recovery objective for archived marketing files might be weeks. The plan reflects that — high-priority systems get more frequent snapshots and faster restores, low-priority data gets cheaper, longer-cycle storage.
- Production databases (CRM, ERP, billing) — RPO under 1 hour
- User files and shared drives — daily snapshots
- Email mailboxes — daily, retained 30+ days
- Server configurations and infrastructure-as-code
- Long-tail archives — weekly to monthly
The ransomware-aware version of 3-2-1
The classic 3-2-1 rule predates modern ransomware. Today's attacks specifically target backup repositories — they encrypt the live data, then walk the network looking for the backup share to encrypt that too, sometimes after sitting dormant for weeks so older snapshots are already corrupted by the time anyone notices. The mitigation is to add immutability: at least one copy of the backups is written to storage that cannot be modified or deleted within a retention window, even by an administrator. That can be a cloud bucket with object-lock enabled, a backup appliance that exposes an immutable repository, or an offline rotation. The detail that matters is that the immutable copy is independent of the live system's credentials — if every account on the production network is compromised, the backups still survive.
Recovery objectives drive everything
A backup plan written without numbers is decoration. The two numbers that matter are RPO — recovery point objective, how much data loss is acceptable — and RTO — recovery time objective, how long the business can tolerate the system being down. A retail business doing live sales has an RPO measured in minutes and an RTO measured in hours; a small accounting firm might tolerate a 24-hour RPO and a one-week RTO on a non-billing system. The plan is designed backwards from those numbers: snapshot frequency comes from the RPO, the restore architecture (warm standby, cold restore, full rebuild) comes from the RTO, and the cost falls out of the combination. Every plan we deliver states both numbers explicitly and proves them with a tested restore.
When was the last time you tested a restore?
We will run a recovery exercise on your existing setup, document where it fails, and propose the smallest set of changes that get you to a verifiable plan.
Book a recovery audit3-2-1 + immutable
Backup posture
Quarterly minimum
Restore exercises
Per system
Documented RTO/RPO
FAQ
Frequently asked questions
Answers built for decision-makers who need clarity before committing.
It depends on the recovery point objective for the system. Production databases that drive billing or operations are usually backed up every 15 minutes to 1 hour. User files and shared drives are usually nightly. Configuration data and long-tail archives can be weekly. The right number for your business comes from one question: how much data loss does the business survive without a serious problem?
What is the difference between a backup and a sync?
A sync mirrors deletions and changes — if a file gets deleted or encrypted on the source, the destination gets the deletion or the encryption too. A backup keeps point-in-time copies that survive what happened to the source. Many businesses think they have backups when they actually have a sync, which is one of the most common reasons ransomware events become unrecoverable.
Where should the off-site copy live?
Anywhere far enough away to survive a local disaster — a different building, a different city, or a cloud region. The cheap and reliable option for most small businesses is encrypted nightly replication to an object-storage bucket in a different region (S3, B2, or a self-hosted MinIO). Larger setups add a second NAS in a different physical location.
How do we know the backups actually work?
By restoring from them on a schedule. Every plan we deliver includes quarterly restore exercises against a staging environment, with the result documented. A backup that has never been restored is, statistically, around 30% likely to fail when first tested — you discover problems by exercising the system, not by trusting the dashboard.
What happens during a real incident?
There is a documented runbook for each business-critical system: who declares the incident, where the latest known-good backup lives, the steps to bring up a clean replacement host, and the validation checklist before users are allowed back in. The runbook is what keeps a 4-hour outage from becoming a 4-day outage. We deliver one with every recovery plan and rehearse it on the same cadence as the restore exercises.
Is cloud-only backup enough?
It is enough for survival, but not for fast recovery. A pure cloud backup can take many hours to restore over a typical business uplink, which is fine for a long RTO but painful for production systems. The standard architecture is a fast local copy for everyday restores plus a cloud copy for site-loss recovery — the local copy makes restores fast, the cloud copy keeps you safe if the local copy is gone too.
A backup is a promise. Let's make sure you can keep it.
Send us your current setup — what runs where, what gets backed up, and how often. We will deliver an RTO/RPO map, the gaps, and the smallest plan that closes them.
Book a backup auditContinue exploring
Each guide stands alone, but the full picture is built from all four. Pair this with the related deep dives or jump back to the Cloud Hosting & Infrastructure pillar.
Self-hosted business tools on VPS
Backups become especially load-bearing when the apps are self-hosted — we plan both together.
Read this guide →Secure remote access without a static IP
Restore exercises are easier when the team can reach the recovery environment from anywhere.
Read this guide →Domain name & professional email setup
Email is one of the most-recovered systems in real incidents — the plan covers mailboxes too.
Read this guide →