A Solid Backup Strategy for Your Site (Practical Guide)
The 3-2-1 backup rule, backup types, frequency, where to store, and how to test restores, sleep easy even if your server dies tomorrow.
Backups are the thing you don't think about, until the day you desperately need them. Cyber attack, botched update, accidental deletion, disk failure, deletion by an employee, ransomware: we've seen every one of these with clients. The difference between catastrophe and a footnote is a recent, restorable backup.
Why backups matter more in 2026 than ever
- Ransomware attacks: up 71% in 2024–2025 (IBM Security report)
- PDPL and legal liability: lost customer data = possible fine
- ZATCA: invoices must be retained for 6 years
- Reliance on external SaaS: your data in a third party's hands
- Insider threats: 60% of data loss stems from human error
The golden 3-2-1 rule
A globally adopted strategy (recommended by US-CERT):
- 3 copies of your data (original + two backups)
- 2 different storage media (e.g., server + cloud)
- 1 copy off-site
In 2026, many add the 3-2-1-1-0 rule:
- 3-2-1 as above
- +1: an "Immutable" copy (can't be modified) against ransomware
- 0: zero errors after testing
Backup types
1. Full backup
A copy of everything. Big, slow, but easiest to restore. Recommended: weekly.
2. Differential
All changes since the last full backup. Smaller, faster. Recommended: daily. Restore: full + latest differential.
3. Incremental
Changes since the last backup of any type. Smallest, fastest. Recommended: hourly for high-traffic sites. Restore: full + chain of all incrementals to the target date.
4. Snapshot
A point-in-time picture of the whole system (used by AWS, Azure, VMware). Recommended: before any major update. Advantage: near-instant restore.
What to back up
A comprehensive list:
- Site files (
/public_html,/var/www) - Databases (MySQL, PostgreSQL, MongoDB)
- Mailboxes (IMAP folders)
- Server config (Nginx, Apache, crontabs, iptables)
- SSL keys and certificates
- Config files (.env, wp-config.php)
- API keys and env vars (in a separate vault)
- User-uploaded content (uploads/)
- Logs for audit purposes
Where to store
| Location | Pros | Cons | Approx. price |
|---|---|---|---|
| Same server | Fast | Useless if server dies | Included with hosting |
| Internal other server | Fast, private | Needs management | SAR 100–500/month |
| AWS S3 | Cheap, reliable, off-site | Some setup | $0.023/GB/mo |
| Backblaze B2 | Cheapest ($0.005/GB) | Slower than S3 | $0.005/GB/mo |
| Cloudflare R2 | No egress fees | Relatively new | $0.015/GB/mo |
| Google Drive / Dropbox | Easy | Size limits, not built for backups | Variable |
| External disk | Under your control | Manual, forgotten | One-time |
Best 2026 combo:
- Local copy (fast restore)
- Cloudflare R2 or Backblaze B2 (off-site, cheap)
- Monthly immutable copy on S3 Glacier (archive)
Frequency by site type
| Type | Recommended frequency | Retention |
|---|---|---|
| Brochure site | Daily | 30 days |
| Active blog | Every 6 hours | 30 days |
| E-commerce store | Hourly (databases) | 90 days |
| SaaS platform | Every 15 min + real-time DB replication | 180 days |
| Financial app | Real-time + healthy daily | 7 years |
The critical step: test restores
An untested backup = no backup. Every 3 months:
- Spin up a staging environment (separate subdomain)
- Restore the latest full backup
- Verify data and file integrity
- Document the time it took
- Identify failure points and fix them
A real test = full restoration, not just checking that the file exists.
Automation: ready-made bash script
#!/bin/bash
DATE=$(date +%Y%m%d-%H%M)
BACKUP_DIR=/backups
S3_BUCKET=my-bucket
# Database
mysqldump -u user -p'pass' dbname | gzip > $BACKUP_DIR/db-$DATE.sql.gz
# Files
tar -czf $BACKUP_DIR/files-$DATE.tar.gz /var/www/html
# Email
tar -czf $BACKUP_DIR/mail-$DATE.tar.gz /var/mail
# Upload to cloud
aws s3 cp $BACKUP_DIR/ s3://$S3_BUCKET/ --recursive
# Delete old copies
find $BACKUP_DIR -mtime +30 -delete
# Success notification
curl -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" \
-d "chat_id=$CHAT_ID&text=Backup OK: $DATE"
Run daily via cron:
0 3 * * * /usr/local/bin/backup.sh > /var/log/backup.log 2>&1
cPanel incremental backups
Every BestHost plan includes:
- Daily full backup
- 30-day retention
- One-click restore from cPanel
- Stored separately from the primary server
- Monthly off-site copies on R2
Strategy against ransomware
Ransomware is your backup's worst enemy. If it hits your server, it'll encrypt your backups too if it can reach them. Protection:
- Immutable backups: cannot be modified for a set period (S3 Object Lock)
- Network isolation: keep backups on a fully separate server
- Separate accounts: use a different IAM user for backups
- Air-gapped copies: physical disk disconnected from the internet
- Monthly testing: make sure backups can actually restore
Common mistakes
- Backups on the same disk: disk dies, you lose everything.
- No encryption: backups contain sensitive data, encrypt with GPG or AWS KMS.
- Never testing: discovering the corrupt backup mid-crisis.
- Keeping very old copies: storage cost with no benefit. Stick to a retention policy.
- Not backing up server config: restoring files alone isn't enough.
- Same-region storage: backups in us-east-1 + server in us-east-1 = region risk.
- Not documenting restore procedures: in a crisis you won't have time to learn.
Bottom line
Backups are cheap. Restoring from disaster without one is an unrecoverable loss. Start with 3-2-1, automate it, and test restores quarterly. BestHost customers get automatic daily backups with 30-day retention, included in every plan. For advanced needs (immutable, real-time replication, 7+ year retention), contact sales.