Most people think data loss is something that happens to “other people.” Then one bad update, one hacked WordPress instance, or one dying SSD proves them wrong.
You do not get a warning before your database gets corrupted, your VPS provider kills your node, or a junior dev runs `rm -rf /` in the wrong shell. The only thing that stands between you and permanent loss is a working backup strategy. Not “backups somewhere.” A strategy.
The short version: the 3-2-1 rule means you keep 3 copies of your data, on 2 different types of storage, with 1 copy stored offsite. For most web hosting and digital community setups, that means: production data, local/nearby backups (same provider, different storage), and one independent offsite copy (another provider or your own hardware in another location). If you are not testing restores regularly, you do not really have backups.
What the 3-2-1 Backup Rule Actually Means
The 3-2-1 rule is not some marketing buzzword invented by a backup vendor. It comes from old-school storage practice, built from people losing data in real incidents and learning the hard way.
Here is the core idea:
- 3 copies of your data: the live data plus at least two backup copies.
- 2 different storage types: for example, block storage and object storage, or SSD and HDD, or cloud storage and physical disks.
- 1 offsite copy: stored with a completely separate provider or in a different physical location.
If all your “backups” live in the same data center and under the same provider account as your production system, you do not have a backup strategy. You have a single point of failure replicated three times.
The rule exists because things fail in clusters:
– Hardware fails in batches.
– Providers suffer outages that affect entire regions.
– Hackers delete both your live data and backups in the same account.
– Human mistakes are often repeated across environments.
You break the blast radius by splitting copies across media, providers, and locations.
Why Web Hosts and SaaS Dashboards Are Not Your Backup Strategy
Most people in hosting learn this when their provider says “We are sorry, that node is gone.”
Shared hosts, managed WordPress platforms, and even some VPS providers like to say “we keep daily backups.” That sounds safe. It is not.
- Provider backups are there to protect them first: for disaster recovery, legal, and compliance reasons. You are a side benefit.
- Retention is often poor: 1-7 days with no clear guarantee. Ransomware, hacks, or slow-burning data corruption can go unnoticed longer than that.
- Access is limited: some providers only restore the entire account, not individual databases or directories.
- Same control plane: compromised credentials can wipe live data and backups in the same click.
If the same login that manages your production server can also delete your backups, then one compromised password can erase everything you own.
For serious projects, provider-level backups are only one layer, not the entire plan. You still need your own independent strategy based on the 3-2-1 rule.
Breaking Down the “3” in 3-2-1: Copies That Actually Matter
Numbers alone do not help. Three useless copies are still useless. The copies need to be:
– Recent enough to be useful.
– Consistent (no half-written database dumps).
– Accessible under pressure.
– Isolated from the blast radius of common failures.
1. The Primary Copy: Your Live Data
This is what you already have: the production database, app files, user uploads, configuration, and infrastructure-as-code (if you are disciplined enough to keep it).
For a typical web hosting / community setup, this means:
| Component | Example | Why it matters for backups |
|---|---|---|
| Application files | PHP, Node, Python, compiled binaries | Often replaceable from repo or package manager, but version mismatch can break restores. |
| Database | MySQL/MariaDB/PostgreSQL | Contains the real business value: users, posts, transactions, content. |
| User uploads | Images, documents, media | Usually unique, not reconstructable easily. |
| Configs & secrets | nginx configs, .env files, TLS certs | Missing configs turn a restore into guesswork. |
| Infra definitions | Terraform, Ansible, Docker Compose | Rebuilds are much faster if infra is versioned. |
Backing up only one of these is half a backup.
2. The Local / Nearline Backup Copy
This is usually a backup that lives either:
– On the same host, in a separate directory or disk.
– On a separate volume (for example, block storage attached to your VPS).
– Inside the same provider, but on dedicated backup storage (for example, object storage bucket in the same region).
The upside:
– Fast restores.
– Easy to set up.
– Useful for “oops” events where the server and provider are intact.
The downside:
– Hardware-level failure, account compromise, or serious provider issues can still wipe everything.
– Ransomware that hits the live system can encrypt these too, if not protected.
This copy exists for speed and convenience, not ultimate safety.
3. The Offsite Backup Copy
This is the insurance against worst-case scenarios:
– Region-wide cloud outage.
– Account hijack at your main provider.
– Legal or policy issues that lead to account closure.
– Crypto locker on your primary environment.
Offsite can mean:
– Another cloud provider (for example, production on DigitalOcean, offsite on Backblaze B2).
– Your own NAS sitting in your office or home, pulling backups via VPN.
– Encrypted archives shipped to cold storage (for bigger setups).
If your offsite copy is with the same provider, in the same region, billing, and IAM system, it is not truly offsite. It is just “another folder” from the attacker’s point of view.
The offsite copy should survive:
– Your main provider disappearing.
– Your root password being leaked.
– An employee going rogue with production access.
What “2 Different Storage Types” Really Looks Like
Storing three copies on three folders of the same SSD does not meet the 2 in 3-2-1. The idea is to avoid failure modes that hit all copies at once.
Realistic options in hosting / community setups:
- Block storage + object storage: VPS disk for production, S3-compatible object storage for backups.
- SSD + HDD NAS: production on SSD VPS, backups on spinning disks in your own NAS.
- Cloud + physical disks: primary in the cloud, offsite as encrypted archives on USB drives rotated offsite.
Storage type differences matter because:
– SSD failure behavior is different from HDD.
– Object storage has different durability and failure characteristics than attached volumes.
– Snapshots at provider level are not the same as downloadable archives.
Snapshots alone are not a 3-2-1 strategy. Many providers store snapshots in the same infra layer. If that layer breaks, all snapshots go silent at once.
Aim for at least one copy that you can physically hold or move, and at least one that does not share a storage backend with your primary environment.
Reliability, Redundancy, and Why RAID Is Not a Backup
RAID, high availability, and multi-AZ clusters are about uptime, not about historical recovery.
RAID helps when:
– A disk dies.
– You want the system to keep running during a hardware component failure.
RAID does nothing when:
– You delete a table by accident.
– A cron job wipes the uploads directory.
– Bugs corrupt data gradually over two weeks.
– Someone gains root access and runs a destructive script.
All mirrored and redundant setups will faithfully copy your mistakes and corruption.
RAID copies your data mistakes faster. Backups give you a way to step back in time before the mistake.
If your hosting provider advertises “triple-replicated storage” and you think you can skip backups because of that, you are confusing durability of bits with reversibility of mistakes.
Designing a Practical 3-2-1 Backup Plan
The best plan is the one you can actually keep running without thinking about it every day. That means:
– Automation for backup creation.
– Clear retention policy.
– Logging and simple alerts.
– Documented restore procedure.
Below is an example for a mid-sized community site running on a VPS with MariaDB or PostgreSQL, some media uploads, and a single-region deployment.
Step 1: Decide What Must Be Backed Up
Make a short inventory:
- Databases: all schemas that hold content, user data, logs you care about.
- Uploads: any user-generated files not stored on external object storage already.
- Configs: web server, app configs, environment files, crontabs.
- Infrastructure metadata: Docker Compose files, deployment scripts, infra-as-code repos.
You do not need to back up:
– Build artifacts that you can regenerate from source.
– Large caches that can be rebuilt quickly.
– Linux base system if you can rebuild from image scripts.
Clarity here reduces backup sizes and restore time.
Step 2: Define RPO and RTO
RPO (Recovery Point Objective): how much data loss you accept in time.
RTO (Recovery Time Objective): how long you can afford to stay down.
For example:
| Type of project | Typical RPO | Typical RTO |
|---|---|---|
| Small forum / community | 4-24 hours | 4-12 hours |
| Busy e-commerce | 5-15 minutes (binlogs / WAL) | 1-2 hours |
| SaaS with paying users | 1-60 minutes | Minutes to a couple of hours |
Stricter RPO usually means:
– More frequent backups or continuous log shipping.
– More storage used.
– More complex restore procedure.
Define these honestly before choosing tools.
Step 3: Map 3-2-1 to Concrete Locations
Example implementation:
- Copy 1 (live): VPS on Provider A, running the app and database on local SSD.
- Copy 2 (local backup): Daily encrypted database dumps and tar archives to object storage bucket on Provider A in the same region.
- Copy 3 (offsite backup): Nightly sync from Provider A object storage to Provider B object storage in a different region, with versioning enabled.
For more security-conscious teams:
– Add a weekly offline backup: encrypted archive to external disks, moved off premises.
If an attacker gets full access to Provider A, they should still have a very hard time reaching your backups on Provider B.
This means:
– Different credentials.
– Different IAM structures.
– Ideally a different identity provider.
Step 4: Pick Your Tools and Formats
You do not need fancy backup software for a single server, but you do need consistency.
Common building blocks:
- Database backups:
- MySQL/MariaDB: `mysqldump` for logical, `xtrabackup` for physical hot backups in larger setups.
- PostgreSQL: `pg_dump` / `pg_dumpall`, or base backups + WAL archiving for point-in-time recovery.
- File backups:
- `rsync` to a mounted backup volume or remote server.
- Tar archives (`tar.gz` or `tar.zst`) for compact, consistent snapshots of directories.
- Transport and storage:
- S3-compatible tools: `rclone`, `aws s3 sync`, provider-specific CLIs.
- Native snapshot tools for quick local rollbacks, but not as the only backup.
- Encryption:
- Client-side encryption with GPG or age.
- Server-side encryption at rest on object storage as a second layer.
File format advice:
– Prefer text-based SQL dumps for small/medium databases; easier to inspect, portable.
– For big databases, use dedicated backup tools that support streaming and compression.
– Keep backup archives compressed, named with timestamps, and immutable once written.
Step 5: Plan Retention and Versioning
Not all copies should stick around forever. You want a retention scheme like:
- Hourly backups kept for 24 hours.
- Daily backups kept for 7-30 days.
- Weekly backups kept for 2-3 months.
- Monthly backups kept for 6-12 months, offsite.
Use object storage lifecycle policies to:
– Transition older backups to cheaper storage tiers.
– Expire very old backups automatically.
Do not keep only the latest backup. Many failures are discovered long after they start. You often need a point from last week, not last night.
The right retention length depends on:
– Legal requirements.
– Storage cost tolerance.
– How often you deploy breaking schema changes.
Security: Backups Are a Target Too
Attackers increasingly go after backups first, then encrypt or wipe production. Ransom is more convincing when they know you cannot restore.
Common problems:
– Backups stored with the same admin credentials as production.
– Long-lived API keys with full read/write/delete on storage.
– No encryption, plain SQL dumps and configs in a bucket anyone who breaks in can read.
Good practices:
- Use separate accounts for backup storage where possible.
- Lock down IAM:
- One key for writing backups (no delete permission).
- Another, stored offline, for delete/management.
- Encrypt at source:
- Encrypt dumps before sending them to remote storage.
- Keep keys in a password manager or hardware token, not in plain text on the server.
- Enable bucket-level protections:
- Versioning.
- Object lock / immutability if supported.
- Server-side encryption.
If your backup system can delete yesterday’s backups automatically, a compromised backup system can delete all of them manually. Give it write-only access wherever possible.
Think of backup credentials as high-value secrets. Rotate them regularly and monitor unusual access.
Testing Restores: The Step Everyone Skips
A backup that has never been restored is a theory, not a safety net. Real incidents often reveal:
– Corrupted archives that never finished uploading.
– Dumps created with the wrong options.
– Missing grants, extensions, or configs that make the restored app unusable.
You need a recurring restore test. Not just once when you set up the cron job.
What a Real Restore Test Should Cover
At least once per quarter for smaller projects, more often for critical ones:
- Provision a clean environment: fresh VM or staging cluster.
- Pull a random backup from offsite storage, not just yesterday’s.
- Restore:
- Database schemas and data.
- Uploads and config files.
- Run the app and verify:
- Logins work.
- Recent content appears as expected for that backup date.
- Background tasks start without crashing.
Measure:
– Time from “disaster” to “service restored” (RTO).
– Any missing documentation or manual steps.
If a junior team member cannot restore the system by following your docs, you do not have a reliable disaster recovery plan.
Document:
– Where backups live.
– Encryption password or key retrieval process.
– Exact commands or scripts in the right order.
Store that documentation offline and in version control.
Special Cases: Databases, Media, and Configuration Drift
Not all data behaves the same. Treat these categories differently.
Databases: Consistency and Point-in-Time Recovery
Databases are the hardest part to back up safely because of ongoing writes. You want:
– Consistent snapshots.
– Options for point-in-time recovery if your RPO is aggressive.
For MySQL/MariaDB:
- Small/medium:
- Nightly full `mysqldump` with `–single-transaction` for InnoDB.
- Incremental backups with binary logs for tighter RPO.
- Larger:
- Use Percona XtraBackup or similar for hot physical backups.
For PostgreSQL:
- Use `pg_dump` or base backups via `pg_basebackup`.
- Enable WAL archiving to allow point-in-time recovery.
Checklist:
– Back up not only data, but also users/roles, extensions, and custom configuration where relevant.
– Record database version; major version mismatches complicate restores.
Media and User Uploads
Media storage tends to grow indefinitely and is often on slower disks or object storage.
Suggested approach:
- Put uploads in object storage from day one, not on local disks.
- Use versioned buckets for “near” backups.
- Periodically replicate buckets to another region/provider.
- Monitor size and access patterns to estimate restore time.
Media rarely changes once written, so incremental syncing works well. The risk is more about accidental deletions or provider outages than corruption.
Configurations and “Snowflake” Servers
If your servers are configured by clicking around control panels or running one-off commands, backups of configs become more critical. You will forget what you changed.
Better approach:
– Treat server and app setup as code, stored in Git.
– Rebuild instead of backing up entire OS images where possible.
– Keep:
– Web server configs.
– App configs.
– Deployment scripts.
– Cron definitions.
If you insist on snowflake servers:
– Take periodic full system snapshots.
– Complement them with file-level backups of `/etc`, home directories, and service configs.
Common Bad Assumptions That Lead to Data Loss
You hear the same flawed logic after nearly every serious incident.
“My host takes care of backups for me”
What it often really means:
– They have some form of backup.
– They do not guarantee restore time.
– They may charge for restores.
– They do not promise completeness.
Their goals are different than yours. You care about business continuity, not just infrastructure continuity.
“We use Git, so we do not need backups”
Git covers:
– Source code.
– Some infrastructure definitions if you are disciplined.
Git does not cover:
– Databases.
– User uploads.
– Generated content.
– Secrets (or at least it should not).
Git is great, but it is not a universal time machine.
“Cloud storage is durable, so why bother with more copies”
Providers talk about “11 nines” of durability for object storage. That describes bit preservation inside their system, not protection against:
– Human deletion.
– Account suspension.
– Compromised credentials.
– Misconfigured lifecycle rules wiping objects.
Durability numbers mean your bits probably will not rot on their disks. They do not mean you always keep access to those bits.
“We never had a problem so far”
That is pure survivorship bias. The world is full of projects that disappeared quietly because they did not have backups when they needed them.
Age of hardware, team changes, complexity, and traffic all increase the odds of failure or mistake. Past luck does not project into future safety.
Cost vs Risk: How Much Backup Is “Enough”?
Backups cost money and time. So does permanent loss.
When deciding how far to go:
| Factor | Low impact project | High impact project |
|---|---|---|
| Direct revenue from site | None or minor | Significant (payments, subscriptions) |
| Legal / compliance risk | Low | Regulated data, contracts |
| Tolerance for downtime | Can be offline for a day | Minutes to an hour |
| Tolerance for data loss | Can lose a day of posts | Cannot lose transactions |
Patterns:
– Hobby project: daily backups, simple offsite copy, minimal retention.
– Active community: multiple daily backups, weekly offsite rotation, tested restores.
– Revenue-critical platform: continuous log shipping, multi-region, staged DR drills.
Err slightly on the safe side. Storage is cheap compared to rebuilding trust and content.
Bringing 3-2-1 Into Your Existing Stack
No need to rebuild everything in one week. You can layer 3-2-1 in stages.
Phase 1: Get Any Automated Backup in Place
Within a day you can:
- Set up nightly database dumps to a local disk or bucket.
- Archive uploads directory daily.
- Enable provider snapshots for quick rollbacks.
This does not satisfy 3-2-1 fully yet, but it protects against many routine mistakes.
Phase 2: Add True Offsite Storage
Next, add:
- A separate provider bucket with:
- Write-only credentials from production.
- Versioning and lifecycle rules.
- A cron or scheduler using `rclone` or similar to sync nightly backups to that bucket.
Now you have:
– Live data.
– Local / same-provider backups.
– One offsite copy on a different platform.
This is a functional 3-2-1 layout.
Phase 3: Add Testing, Documentation, and Refinement
Once the basics work:
- Schedule quarterly restore drills.
- Document steps and store them with your other operational docs.
- Adjust retention after watching storage growth for a few months.
- Review IAM policies and keys at least twice a year.
Backup maturity is not about how shiny your tools are. It is about how calmly you can say “restore from last Tuesday, 14:00” and know exactly what to do.
Backups are not optional because failure is not hypothetical. The 3-2-1 rule gives a simple structure that survives real-world incidents: hardware failure, human error, platform outages, and security breaches. Even if you dislike process and hate extra costs, 3-2-1 is cheaper than explaining to your users that everything they contributed for years is gone.
