Before diving into specific backup tools, it's worth understanding the industry-standard framework for reliable backups: the 3-2-1 rule. This guide explains it and how to apply it practically on a VPS.
What Is the 3-2-1 Rule?
- 3 total copies of your data (the original plus two backups)
- 2 different storage media/locations (not all copies on the same disk)
- 1 copy stored off-site, away from your primary infrastructure
Why Each Number Matters
Why 3 Copies?
A single backup can itself become corrupted or fail. Two independent backups dramatically reduce the odds that both fail simultaneously.
Why 2 Different Media/Locations?
If your VPS's disk fails entirely, a backup stored on that same disk is useless. Storing backups on genuinely separate storage protects against hardware-level failures.
Why 1 Off-Site Copy?
Protects against events affecting your entire primary location — a data center outage, a compromised account affecting all resources at one provider, or a catastrophic misconfiguration cascading across co-located systems.
Applying 3-2-1 on a VPS Practically
| Copy | Location | Example |
|---|---|---|
| 1 (Original) | Your live VPS | Production database and files |
| 2 (Local backup) | Same VPS, different volume, or provider snapshot | Nightly mysqldump stored locally |
| 3 (Off-site backup) | A different server or provider entirely | Synced via rsync to a separate backup VPS or object storage |
Common Mistakes That Violate 3-2-1
- Relying solely on provider snapshots — these typically live on the same underlying infrastructure as your VPS
- Backing up to a second directory on the same disk — doesn't protect against disk failure
- Never actually verifying the off-site copy is current and complete
What Counts as "Off-Site" for a VPS?
- A separate VPS with a different provider or in a different region
- Object storage (S3-compatible) in a different location
- A local machine you control, for smaller-scale projects
Backup Frequency Guidelines
| Data Type | Suggested Frequency |
|---|---|
| Databases (active application) | Daily, or more frequently for high-transaction systems |
| Application files (rarely changing) | Daily or weekly |
| User-uploaded content | Daily |
| Full server snapshot | Before major changes, plus a regular schedule |
Retention Policy
A common pattern: keep 7 daily backups, 4 weekly backups, and 3–6 monthly backups — balancing storage cost against how far back you might realistically need to recover from.
The Backup You Haven't Tested Isn't a Backup
The 3-2-1 rule is necessary but not sufficient — see How to Test and Verify Your Backups Actually Work for the equally important step most people skip.
Getting Started
- See How to Set Up Automated VPS Backups (rsync, cron & Off-Site Storage) for the file/database backup implementation
- See How to Back Up to Object Storage (S3-Compatible) for the off-site destination
- See How to Test and Verify Your Backups Actually Work to close the loop
Related Articles
- How to Set Up Automated VPS Backups (rsync, cron & Off-Site Storage)
- How to Back Up to Object Storage (S3-Compatible)
- How to Test and Verify Your Backups Actually Work
