Why Backups Matter (and What “Good” Looks Like)
Sites go down for lots of reasons: plugin conflicts, hacked code, accidental deletes, corrupted databases, bad deploys, or host failures. A “good” backup is one you can restore quickly without guesswork. That means it’s complete, recent, offsite, versioned, and tested.
TL;DR: Follow the 3-2-1 rule — keep 3 copies of your data, on 2 different media/locations, with 1 offsite. Automate it, encrypt it, and test restores monthly.
What to Back Up
- Application files: themes/templates, plugins/modules, uploads/media, custom code.
- Database: content, users, orders, settings—typically MySQL/MariaDB for PHP apps or WordPress.
- Configuration: .env, wp-config.php, .htaccess/nginx rules, cron jobs.
- Secrets: API keys and tokens (store securely, not in plaintext backups).
How Often to Back Up
Frequency matches how often your data changes:
- Blogs/news sites: daily DB + weekly files (or daily if you post media often).
- eCommerce: hourly DB + daily files; consider point-in-time snapshots.
- Static sites: on deploy + weekly archive.
Where to Store Backups
- Primary copy: on the server (short retention, e.g., 3–7 days) for fast restores.
- Offsite copy: cloud object storage (S3, Backblaze B2, Wasabi) with versioning enabled.
- Optional third copy: another region/provider for disaster scenarios.
Retention Policy
Keep short-term frequent backups and fewer long-term archives:
- Daily for 7 days
- Weekly for 4 weeks
- Monthly for 3–6 months
Automation Options
Control Panel (cPanel/Plesk)
- Use native backup tools or your host’s snapshot service.
- Schedule, encrypt, and push to remote storage via SFTP/S3 where supported.
WordPress
- Choose a reputable backup plugin that supports incremental backups and offsite destinations (S3/B2/Drive).
- Exclude cache folders to reduce size and speed up jobs.
Custom/CLI
- Script mysqldump + tar/rsync; encrypt archives with gpg.
- Upload to S3/B2; enable lifecycle rules to auto-expire old backups.
Encryption & Access
- Encrypt at rest (server and cloud). Use object lock or immutability if available.
- Rotate credentials; store access keys in a password manager or vault.
- Limit who can download backups—treat archives as sensitive.
Testing Restores (The Part Everyone Skips)
A backup you’ve never restored is a risk. Create a recurring “fire drill” to restore to a staging site:
- Spin up a temporary database and import the latest dump.
- Extract files to a staging directory; configure .env for staging creds.
- Open the staging URL and sanity-check pages, logins, and key flows.
- Document gotchas (e.g., serialized URLs in WordPress) and script fixes.
Special Cases
eCommerce
- Backup more frequently during promotions; keep transaction logs if supported.
- Ensure your payment gateway/webhook configurations are backed up separately (docs + screenshots).
Media-Heavy Sites
- Consider object storage for uploads; it simplifies backups and reduces server disk usage.
- Use lifecycle rules to move older media to cheaper storage tiers.
Teams & Agencies
- Centralize policies; use consistent naming, schedules, and destinations across clients.
- Send reports/alerts for failed jobs; don’t assume “no news is good news.”
One-Page Backup Plan (Template)
Scope: Files (code + uploads), DB, config.
Frequency: Daily DB, weekly files (adjust for change rate).
Destinations: Server (7 days), S3 (4 weeks), Glacier (3 months).
Encryption: GPG at rest, TLS in transit.
Testing: Monthly restore to staging; document steps.
Alerts: Email on failure; dashboard review weekly.
FAQs
Are host backups enough? Treat host backups as a bonus, not your only copy. Keep your own offsite backups under your control.
How big will backups get? Use incremental backups, exclude caches, and compress. Object storage is inexpensive at scale.
How long should I keep backups? Depends on risk tolerance and regulation. A rolling 90-day window covers most sites.
Related: Zero-Downtime Migration · Website Security Checklist · Handy .htaccess Tricks
