Backup Strategy for Your Own Site: Full vs. Incremental, Frequency, Storage Locations, and Restore Drills
1. What to Back Up: Databases and Files Need Separate Backups
Backing up your own site means backing up two things: the database and the files. The database holds your WordPress content — wp_posts, wp_options, wp_users — while the files are the images, theme, and plugin code in wp-content/uploads. These two change at completely different rates and need completely different backup methods. Backing them up together causes problems.
Export the database with mysqldump or wp-cli, and always include the –single-transaction flag so you don’t lock tables and disrupt your live site. Sync files incrementally with rsync, transferring only what changed instead of copying everything each time — a full copy of a 10GB wp-content directory takes over ten minutes, while an incremental sync takes seconds.
| Backup target | Change Frequency | Recommended tools | Backup method |
|---|---|---|---|
| MySQL database | May change hourly | mysqldump or xtrabackup | Incremental binlog every 4 hours, full dump daily |
| wp-content/uploads | New images added weekly | rsync | Incremental sync daily |
| Theme and plugin code | Changed a few times a month | git or rsync | Version control, full backup monthly |
| wp-config.php | Rarely changes | Store separately in a password manager | Back up on every change |
| nginx/site config | Changed a few times a month | Managed with git | Back up on every change |
Example scenario: an industrial equipment exporter’s WordPress site for overseas buyers gets 3 to 5 new inquiries and 2 to 3 new product images every day. A script exports the database every 4 hours, and rsync syncs files incrementally to offsite object storage at 3 a.m. daily. Over a week, database backups take up about 500MB and incremental file backups about 200MB, for a total storage cost under 20 yuan a month. This setup is more reliable than any paid backup plugin.
How to write the backup script — same approach as the automated ops ideas in crater Tech Stack: don’t rely on a GUI plugin. Use cron plus scripts, and send an alert when something fails.
2. Frequency and Retention: More Frequent Isn’t Always Better
A counterintuitive take: more frequent backups aren’t always better. Backing up too often eats up storage and IO, and it actually makes recovery messier—you’re staring at a pile of near-identical backups with no idea which one is clean. The right frequency depends on how fast your business changes: back up the database every 4 hours, because inquiries can come in at any time; back up files daily, because image uploads aren’t frequent.
Use a grandfather-father-son retention policy: keep daily backups for 30 days, weekly backups for 12 weeks, monthly backups for 12 months, and yearly backups for 3 years. That way you can restore an article you accidentally deleted yesterday, or roll back to a clean version from six months ago before the hack.
| Backup type | Frequency | How long to keep it | where it’s stored | Purpose |
|---|---|---|---|---|
| Database full backup | Daily at 3 AM | 30 days | Off-site object storage | Recover from everyday accidental deletion |
| Database incremental binlog | Every 4 hours | 7 days | Local + offsite | Minute-level recovery |
| Full file backup | Every Sunday at midnight | 12 weeks | Off-site object storage | Weekly rollback |
| File incremental rsync | Daily at midnight | 30 days | Off-site object storage | Daily rollback |
| Monthly archive | 1st of each month | 12 months | Glacier cold storage | Monthly compliance and long-term |
| Yearly archive | Every January | 3 years | Glacier cold storage | Annual audit and history |
Example: a site going global discovered on the afternoon of March 15 that its database had been injected with malicious content. With binlog incremental backups, you can restore the database to noon on March 15—the state before the attack—losing only half a day of inquiry records. If you only had daily full backups, you could only restore to 3 AM on March 15, losing a full day of inquiries. That’s the difference between 4-hour incremental and daily full backups.
3. Storage location: the 3-2-1 rule, offsite is mandatory
The 3-2-1 backup rule means: keep 3 copies of important data, on 2 different types of media, with 1 copy stored offsite. This isn’t theory—it comes from countless ransomware incidents. In real attacks, the attacker encrypts the local backups at the same time as the server—because the backups and the site are on the same machine.
How to choose your three storage tiers: the first tier is local backup, on another disk partition of the server—fastest to restore but least resilient; the second tier is offsite object storage, using AWS S3 or Alibaba Cloud OSS, with cross-availability-zone redundancy, so a single server failure won’t take you down; the third tier is cold archive storage, using S3 Glacier or OSS Archive—cheap but slow to restore, for annual compliance and long-term retention.
| Storage tier | Location | Recovery speed | Cost | Primary use |
|---|---|---|---|---|
| Local disk backup | Another partition on the server | Seconds | Free | Daily quick recovery |
| Off-site object storage | S3/OSS cross-region | Minutes | About ¥0.02/GB/month | Primary backup, synced daily |
| Cold archive | Glacier/OSS Archive | Hours to days | About ¥0.005/GB/month | Annual compliance and long-term |
| Offline media | Local hard drive/tape | Physical retrieval | One-time hard drive cost | Last resort for extreme ransomware scenarios |
Counterintuitive tip: never keep backup files inside the web directory. Many people put backups in wp-content/backup/, thinking they have an extra copy, but in reality an attacker who scans that path can download it directly, exposing every database and table name. The right approach is to store backups outside the web root, or upload them automatically to object storage after each backup and delete the local copy. For the cleanup process after a hack, see After your site gets hacked.
and CDN global acceleration One thing to watch: CDN cache is not a backup. It only copies your static content to edge nodes, and if the origin goes down, the CDN cache will expire too. Never treat CDN cache as a disaster recovery plan.
4. Recovery drills: run one every quarter to prove your backups actually work
The most overlooked part of any backup strategy is the recovery drill. Many companies run backup scripts for a year without ever restoring once, and only when disaster strikes do they discover the backup files are corrupt, the unzip password is forgotten, or the recovery process simply doesn’t work. In real incidents, more than 40% of backup restores fail, and the reasons fall into these three categories.
How to run a recovery drill: pick a maintenance window each quarter, pull the most recent backup from offsite object storage, restore it to a brand-new test environment, and run the full flow of “restore files, import database, configure nginx, access the site, verify the inquiry form submits.” Time the whole process and record your actual RTO (recovery time objective) and RPO (amount of data lost). For how to set RTO/RPO, see Disaster Recovery and RTO/RPO Definitions for Independent Sites.
| Drill steps | Action | Acceptance Criteria | Common failure points |
|---|---|---|---|
| 1. Pull the backup | Download the latest full + incremental backup from S3 | Download completes within 5 minutes | Object storage credentials expired |
| 2. Verify the archive | List files with tar -tzf | File count complete, no corruption | gzip archive corrupt, no checksum verified |
| 3. Restore files | Extract to the test environment’s web directory | Permissions correct: 755/644 | Permissions lost, site shows a blank page |
| 4. Import the database | mysql < backup.sql | Table count matches production | Wrong character set, garbled Chinese text |
| 5. Configure nginx | Copy the config and change the port | Domain is reachable | Rewrite rules lost |
| 6. Verify functionality | Walk through an inquiry form submission | Email received, record saved to CRM | SMTP password hardcoded in the config |
Example scenario: a team went six months without a recovery drill, and only when a server drive failed did they pull the offsite backup. Halfway through extraction it threw an error, because a gzip parameter in the backup script had been wrong for three months, and the two months of backups after that were all corrupt files. In the end they could only restore from an older, clean backup and lost two months of content. A quarterly recovery drill would have caught this in advance.
For how to set up backup monitoring, see Site monitoring and alerts: send a WeCom alert when a backup job fails, when backup file size drops sharply, or when the backup is more than 24 hours old. For the routine maintenance checklist, see Six Monthly Tasks for Site Maintenance.
FAQ
Which plugin should you use for independent site backups? Is UpdraftPlus enough?
How often should I back up? Do I need it every hour?
How do I put the 3-2-1 backup rule into practice?
How do I run a restore drill, and how often?
Should backup files be encrypted, and how do I store the keys?
How do you know if the backup script fails, and how do you get alerted?
Final thoughts
The worst mistake with backups is thinking “I installed a plugin, so I’m done.” The plugin runs every day and generates a backup file every day, but you’ve never once restored it. When something actually goes wrong, you discover the backup is corrupt, the password is lost, and the process doesn’t work. Half of a backup strategy is how to store backups; the other half is how to restore them, and the latter is ten times more important.
Three steps to get it done: first, build three layers of backups following the 3-2-1 rule, with one copy each locally, in off-site object storage, and in cold archive; second, set the frequency and retention policy, with incremental database backups every 4 hours plus a daily full backup, daily incremental file backups, and retention from 30 days to 3 years; third, run a restore drill every quarter, walking through the full restore process in a test environment and recording the actual RTO and RPO. Only after these three steps can you say you have backups.
One line worth remembering: a backup you’ve never restored is no backup at all. A backup script that runs for a year is worth less than one full restore drill, and in real incidents 40% of backups won’t open when it matters.