Backups exist for one moment: the day you need to restore. Everything in a backup plan should be judged by how quickly and completely you can get your data back.
The 3-2-1 rule
- **3** copies of your data: the live copy and two backups.
- **2** different types of storage, so one failure mode cannot take both.
- **1** copy in a different location, away from the main server.
Many teams now add a fourth point: one copy that cannot be changed or deleted for a set time (immutable or offline), which protects against ransomware and mistakes made with admin credentials.
Two numbers to decide first
| Term | Question it answers | Example |
|---|---|---|
| RPO (recovery point objective) | How much recent data can we afford to lose? | Daily backups = up to 24 hours of data |
| RTO (recovery time objective) | How long can we be down while restoring? | Four hours to bring the store back |
An online store taking orders all day may need hourly database backups; a company website may be fine with daily ones.
What to back up
- Website files and uploads.
- Every database, exported in a consistent state.
- Configuration: web server, PHP, cron jobs, environment files.
- Email, if it is hosted on the same server.
- DNS zone exports and SSL details, so you can rebuild elsewhere.
Retention
Keep several generations, not just the latest copy. A common pattern is 7 daily, 4 weekly and 3 monthly backups. Problems such as a hacked site or corrupted data are often found days later, after the most recent backups already contain them.
Test restores
- Pick a backup at random each month or quarter.
- Restore it to a separate server or a staging site.
- Check that the site opens, logins work and recent data is there.
- Write down how long it took: that is your real RTO.
A backup stored on the same server as the site is a convenience, not protection. If the server fails or is compromised, both are lost together.