Backups 101: RPO, RTO, and the 3-2-1 Strategy for Hosting Reliability
Backups Are the Insurance Policy Everyone Forgets Until the Fire Starts
Every hosting customer talks about backups. Fewer actually verify that their backups work. The uncomfortable truth is that an untested backup is barely better than no backup at all. When a database corruption, accidental deletion, ransomware attack, or server failure strikes, the only thing that matters is whether you can restore your data to a known good state — quickly and completely.
This guide covers the fundamentals of backup strategy for hosted websites and applications: the concepts of RPO and RTO, the proven 3-2-1 backup rule, and the practical steps to implement a backup plan that holds up when it matters most.
RPO and RTO: The Two Numbers That Define Your Backup Strategy
Recovery Point Objective (RPO)
RPO answers the question: "How much data can we afford to lose?" It is measured in time. An RPO of one hour means that in a worst-case scenario, you lose up to one hour of data. An RPO of 24 hours means you could lose an entire day's worth of transactions, content updates, or user activity.
For a personal blog updated once a week, a daily RPO is perfectly reasonable. For an e-commerce store processing orders around the clock, losing 24 hours of orders is catastrophic. Your RPO should match the pace at which your data changes and the business impact of losing that data.
Recovery Time Objective (RTO)
RTO answers the question: "How quickly do we need to be back online?" An RTO of four hours means that from the moment of failure, you commit to having the site fully operational within four hours. An RTO of 15 minutes demands a much more sophisticated — and expensive — recovery infrastructure.
RTO is not just about restoring files. It includes detecting the problem, deciding to restore, executing the restore, verifying data integrity, and making the site public again. Every step takes time, and the total must fit within your RTO window. If you have never timed a full restore, your RTO is a guess, not a commitment.
The 3-2-1 Backup Strategy
The 3-2-1 rule is one of the most widely recommended backup strategies in the industry, and for good reason. It is simple, it accounts for common failure scenarios, and it scales from a single website to enterprise infrastructure.
- 3 copies of your data: The original production data plus two backup copies. One copy is not enough — media fails, corruption can be silent, and human error happens.
- 2 different storage media: Store backups on at least two different types of media or storage systems. If your production data is on SSD storage, keep one backup on a different server and another on object storage, a separate data center, or an offline medium.
- 1 offsite copy: At least one backup must be physically separate from your production environment. If your server room floods, burns, or is compromised by ransomware, your offsite copy survives. Object storage in a different geographic location is the most common offsite solution for hosting customers.
What to Back Up
A complete backup strategy covers every piece of data and configuration needed to rebuild your environment from scratch.
Database
For most web applications, the database is the most critical asset. It contains user data, orders, content, and configuration. Use your database engine's native dump tools (e.g., pg_dump for PostgreSQL, mysqldump for MySQL) to create logical backups that can be restored to any compatible server.
For larger databases, consider physical backups or continuous archiving (WAL archiving in PostgreSQL, binary logs in MySQL) that allow point-in-time recovery — restoring the database to any specific moment, not just the time of the last dump.
Application Files
This includes your website code, uploaded media, theme files, plugins, and any custom scripts. Use incremental backup tools that only transfer changed files — this reduces backup time and storage costs for large file collections.
Server Configuration
Web server configs, SSL certificates and private keys, firewall rules, cron jobs, environment variables, and any custom system configuration. Losing these means rebuilding the server from scratch by memory, which is slow and error-prone. Version-control your configuration files or include them in your backup set.
If you host email on the same server, mailbox data must be backed up separately. Email stores can be large, so plan storage and retention accordingly.
Backup Frequency: Matching RPO to Schedule
Your backup schedule should directly reflect your RPO targets:
- Database: Daily full dumps at minimum. For applications with frequent writes, add hourly incremental backups or enable continuous archiving.
- Application files: Daily incrementals are usually sufficient unless you deploy multiple times per day, in which case tie backups to your deployment pipeline.
- Configuration: Back up after every change. If you use configuration management tools or infrastructure as code, this is handled by version control.
Testing Your Backups: The Step Most People Skip
A backup you have never restored is a hope, not a plan. Schedule regular restore drills — at minimum quarterly — where you take a recent backup and restore it to a test environment. Verify that the site loads, the database is intact, user data is present, and everything functions correctly.
Time the entire process from start to finish. This is your actual RTO. If it takes four hours but your business requires a one-hour RTO, you need a faster recovery method — pre-staged servers, automated restore scripts, or a hot standby configuration.
Document each drill: what worked, what failed, how long each step took, and what you would do differently. These records are invaluable when a real disaster strikes and you are operating under stress.
Backup Security
Backups contain everything an attacker wants: database credentials, user data, payment records, API keys. Treat backup storage with the same security rigor as production.
- Encrypt backups at rest: Use GPG, AES-256, or your storage provider's encryption features. If a backup file is stolen or leaked, encryption ensures the data is useless without the key.
- Restrict access: Only the accounts and processes that create and restore backups should have access to backup storage. Use separate credentials, not your production database password.
- Protect against ransomware: Ensure that at least one backup copy cannot be modified or deleted by the production server. Immutable storage (write-once, read-many) or offline backups provide this protection.
Retention Policies
You do not need to keep every backup forever. Define a retention policy that balances recovery needs with storage costs:
- Daily backups: Retain for 7 to 14 days
- Weekly backups: Retain for 4 to 8 weeks
- Monthly backups: Retain for 6 to 12 months
This layered approach lets you recover from recent incidents quickly while still having older restore points for scenarios like silent data corruption that goes undetected for weeks.
Automation Is Not Optional
Manual backups are forgotten backups. Automate everything: the backup creation, the transfer to offsite storage, the retention cleanup, and the integrity verification. Use cron jobs, systemd timers, or your backup tool's built-in scheduling. Then set up monitoring that alerts you if a backup fails, is late, or is suspiciously small.
A backup that ran successfully yesterday and failed silently today is worse than useless — it gives you false confidence. Monitor actively and treat backup failures as incidents that require immediate attention.
The Bottom Line
Backups are the last line of defense against data loss, and the 3-2-1 strategy gives you a resilient, battle-tested framework to build on. Define your RPO and RTO based on real business impact. Automate your backups, encrypt them, store them offsite, and test them regularly. The time to discover that your restore process is broken is during a drill, not during a disaster.