A backup is only useful if it is complete, protected from the failure that affected production, and recoverable within the time your team needs. This runbook shows small teams how to set backup frequency, estimate storage and operational costs, define recovery targets, and test restoration for WordPress sites, databases, VPS applications, uploaded files, email, and DNS.
Overview
A practical website backup strategy has four parts: what you copy, how often you copy it, where you store it, and how you prove that restoration works. Treating “the website” as one folder is a common mistake. A production site may include application code, a database, uploaded media, environment variables, container definitions, server configuration, email data, domain records, and certificates or renewal settings.
Start by writing a short inventory for every production service:
- Application files: WordPress core and plugins, themes, custom code, or the deployed application.
- Database: posts, users, orders, settings, and other frequently changing records.
- Uploads and generated assets: media libraries, customer files, exports, and build artifacts that cannot be recreated easily.
- Infrastructure configuration: Docker Compose files, environment-variable names, reverse-proxy configuration, firewall rules, cron jobs, and deployment scripts.
- External services: DNS records, email configuration, object-storage settings, payment integrations, and monitoring details.
Backups do not replace version control, staging, security updates, or a documented deployment process. They provide a recovery path when an update fails, a server is lost, data is deleted, or an account is compromised. A provider snapshot may be convenient, but it should not be the only copy if the snapshot is stored in the same account, region, or failure domain as the live server.
For a broader view of hosting choices, compare your backup requirements with the operational features discussed in the managed WordPress hosting comparison. Teams running self-hosted applications can also use the open-source hosting requirements checklist to identify which application state must be included.
How to estimate
Estimate a backup plan from recovery objectives rather than from a provider’s default setting. The two key measures are the recovery point objective (RPO) and recovery time objective (RTO).
- RPO: the maximum amount of recent data the team can afford to lose. If the RPO is 24 hours, a daily backup may be acceptable. If losing several hours of orders or submissions is unacceptable, use more frequent database backups or another replication method.
- RTO: the maximum acceptable time to restore service. A simple brochure site may tolerate a manual restore. A busy application may require documented automation, a prepared replacement server, or a hosting plan with faster recovery options.
Use this basic planning sequence:
- List each data set and its current size.
- Choose a backup frequency that fits its RPO. Databases and uploads may need different schedules from static files.
- Choose retention periods for recent, weekly, and monthly recovery points.
- Estimate stored data using the number of copies, expected growth, and whether backups are full, incremental, or compressed.
- Add transfer, storage, snapshot, monitoring, and labor costs where your provider or tooling charges for them.
- Run a restore test and record the elapsed time, missing dependencies, and any manual steps.
A simple storage estimate is:
Estimated storage = backup data per copy × retained copies + overhead for growth and metadata.
This is only a planning estimate. Deduplication, compression, incremental chains, database dump size, and provider billing rules can change the result. Check whether the hosting provider counts snapshots, backup storage, restore traffic, or cross-region transfer separately. Do not treat an advertised retention period as proof that every file and database is included.
Inputs and assumptions
Record the following inputs in a small spreadsheet or operations document. Update it whenever a site, server, or provider changes.
| Input | What to record | Why it matters |
|---|---|---|
| Data sets | Files, database, uploads, configuration, email, DNS | Prevents important dependencies from being omitted |
| Current size | Size of each data set and monthly growth estimate | Supports storage and transfer planning |
| RPO | Maximum acceptable data loss by service | Sets backup frequency |
| RTO | Maximum acceptable outage by service | Sets restoration procedure and tooling |
| Retention | Daily, weekly, and monthly copy counts | Balances recovery options against storage use |
| Location | Provider account, region, or external storage destination | Reduces the risk of a shared failure |
| Access | Encryption, credentials, recovery keys, and named owners | Protects backups and makes recovery possible |
Use encryption in transit and at rest when supported, restrict backup access to the people and systems that need it, and store recovery credentials separately from the production server. A backup that an attacker can delete with the same credentials as the live site is weak protection against account compromise. Consider an immutable or otherwise deletion-resistant copy when the risk justifies the additional complexity.
For WordPress, include the database and wp-content, while confirming whether themes, plugins, uploads, and configuration files are captured separately. For a VPS or Docker deployment, preserve image references, Compose files, bind-mounted volumes, reverse-proxy configuration, secrets-management instructions, and the commands needed to provision a replacement host. Do not copy live database files blindly while the database is running; use a consistent dump or provider-supported backup method.
Worked examples
Example 1: Content site with moderate change
Assume a WordPress site has 8 GB of uploads, a 1 GB database, and 1 GB of application and configuration files. The team chooses daily database backups, weekly full site backups, and four weekly recovery points. For planning, assume one full copy is 10 GB and each retained weekly copy is also estimated at 10 GB. Four retained copies require approximately 40 GB before growth, metadata, and provider overhead. The team should add a growth allowance rather than planning to the exact current size.
The restore procedure should cover a clean WordPress installation, database import, uploads restoration, configuration, domain routing, HTTPS, scheduled tasks, and an administrator login test. A staging restore is preferable because it validates the backup without changing production.
Example 2: Small VPS application
Assume a Docker application has a 3 GB database, 12 GB of user uploads, and 2 GB of configuration and deployment files. The database changes throughout the day, while the application image can be rebuilt from version control. The team could use frequent database dumps, daily copies of uploads, and version-controlled infrastructure files rather than repeatedly copying disposable container layers.
The resulting estimate should separate storage by data type. If the team retains seven daily upload copies and four weekly full recovery points, the upload portion alone is estimated as 12 GB × 7 for daily copies plus 12 GB × 4 for weekly copies, before compression and deduplication. The database estimate should use the actual dump size and selected frequency, not the size of the database volume alone. This distinction makes both cost and recovery planning more accurate.
When restoring, provision a clean VPS, apply operating-system updates, install the container runtime, retrieve the approved configuration, restore the database and volumes, update DNS only after validation, and test the application from an external network. The Docker on a VPS guide and Ubuntu deployment guide provide useful deployment context for this type of runbook.
Restore-test checklist
- Select a recent backup without relying on the newest copy only.
- Restore to isolated staging or a temporary server.
- Verify file counts, database tables, media, users, and recent content.
- Confirm environment variables, scheduled jobs, integrations, email sending, and file permissions.
- Test HTTPS, redirects, login, forms, checkout or other critical workflows.
- Measure the time from restore start to a usable service.
- Record failures, missing credentials, manual commands, and the final result.
When to recalculate
Recalculate the plan when pricing inputs, storage size, traffic, or provider terms change. Review it at least twice a year as an operational habit, and immediately after a migration, major hosting change, new production service, database redesign, or significant increase in uploads. The review should confirm current backup frequency, retention limits, storage and transfer charges, encryption settings, access owners, and whether the provider still includes the data types you depend on.
Run a restore test before a major application upgrade, before moving domains or servers, and after changing backup tooling. A successful scheduled job is not the same as a successful recovery. If the last test exposed missing DNS records or credentials, update the runbook and repeat the test rather than simply marking the issue resolved.
Finish with a one-page recovery record containing service names, backup locations, retention rules, RPO and RTO targets, restoration commands, DNS instructions, escalation contacts, and the date of the last successful test. For DNS-specific recovery details, keep an exported record set and review the Cloudflare DNS setup guide. Before a migration, pair this document with the website migration checklist. The practical goal is not to own the largest backup archive; it is to know what can be restored, how long it takes, and who can do it when production is unavailable.
