Self-hosted business tools on a private VPS
Backups matter most when the apps are self-hosted, so we plan both together.
Read this guide →
Cloud & Infrastructure / Deep Dive
Disaster recovery and backup solutions
Disaster recovery and backup solutions that restore: 3-2-1 copies, off-site replication, ransomware-resistant snapshots and a recovery path we test. A backup only counts once you have restored from it, so we prove every plan with a real restore.
SCROLL
If you've never restored from it, you don't have a backup
Most businesses think they have backups. What they usually 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 tried 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. Every backup target is verified by an actual restore, not by a green checkmark in the backup software.
This guide is part of our managed cloud hosting service. It covers the architecture and the trade-offs that decide which version 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 and monthly
What a real backup architecture covers
A serious setup is not one product. It is a set of layers, and each one defends against a different failure. Together they cover the four scenarios that take a business offline: hardware failure, accidental deletion, ransomware encryption and full-site loss.
- Local snapshots, for fast restores after accidental deletion
- Off-site replication, which survives a fire, theft or site loss
- Immutable (WORM) copies, which survive ransomware
- Application-aware backups of databases, mail and ERP
- Documented and tested restore procedures
What gets backed up, in priority order
Not everything needs the same protection. The recovery objective for a production database is hours. For archived marketing files it might be weeks. The plan reflects that: high-priority systems get frequent snapshots and fast restores, and low-priority data goes to cheaper, slower storage.
- Production databases (CRM, ERP, billing), with an RPO under 1 hour
- User files and shared drives, with daily snapshots
- Email mailboxes, daily and kept for 30+ days
- Server configuration and infrastructure-as-code
- Long-tail archives, weekly to monthly
Two media. One off-site. One immutable.
The ransomware-aware version of 3-2-1
The classic 3-2-1 rule predates modern ransomware. Today's attacks target backup repositories on purpose. They encrypt the live data, then walk the network looking for the backup share. Some wait for weeks, so older snapshots are already corrupted by the time anyone notices.
The fix is immutability. At least one copy of the backups is written to storage that cannot be changed or deleted within a retention window, even by an administrator. That can be a cloud bucket with object lock, a backup appliance with an immutable repository or an offline rotation.
What 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.
Off-site copy in a different region
Local NAS for fast daily restores
Recovery objectives drive everything
A backup plan written without numbers is decoration. Two numbers matter. RPO, the recovery point objective, is how much data loss is acceptable. RTO, the recovery time objective, is how long the business can tolerate the system being down.
A retail business taking live sales has an RPO measured in minutes and an RTO measured in hours. A small accounting firm might accept 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 or full rebuild) comes from the RTO. The cost falls out of the combination. Every plan we deliver states both numbers 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 gets you to a verifiable plan.
Book a recovery audit3-2-1 + immutable
Backup posture
Quarterly minimum
Restore exercises
Per system
Documented RTO and RPO
FAQ
Backup and recovery questions, answered
What teams ask before they trust a backup plan.
It depends on the recovery point objective of each 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 comes from one question: how much data loss can the business survive without a serious problem?
2
What is the difference between a backup and a sync?
A sync mirrors changes. If a file is deleted or encrypted on the source, the destination gets the deletion or the encryption too. A backup keeps point-in-time copies that survive whatever happened to the source. Many businesses think they have backups when they have a sync, which is a common reason ransomware events become unrecoverable.
3
Where should the off-site copy live?
Far enough away to survive a local disaster: a different building, a different city or a cloud region. A cheap and reliable option for most small businesses is encrypted nightly replication to an object-storage bucket in another region, such as S3, Backblaze B2 or a self-hosted MinIO. Larger setups add a second NAS in a different physical location.
4
How do we know the backups actually work?
By restoring from them on a schedule. Every plan includes quarterly restore exercises against a staging environment, with the result documented. You find problems by exercising the system, not by trusting the dashboard.
5
What happens during a real incident?
Each business-critical system has a runbook: who declares the incident, where the latest known-good backup lives, the steps to bring up a clean replacement host and the checklist to pass before users are allowed back. The runbook is what keeps a 4-hour outage from becoming a 4-day one. We deliver one with every recovery plan and rehearse it on the same cadence as the restore exercises.
6
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 connection. That is fine for a long RTO and painful for production systems. The standard design is a fast local copy for everyday restores plus a cloud copy for site loss.
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 and 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.
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 and professional email setup
Email is one of the most-recovered systems in real incidents, so the plan covers mailboxes too.
Read this guide →