A backup is only a stored possibility. Disaster recovery is the proven ability to restore a usable service within a business deadline. This guide helps site owners turn automated backup claims into a recovery system with clear targets, independent copies, validation, and rehearsed responsibilities.
Image disclosure: The images are AI-generated editorial illustrations, not photographs of a provider, test lab, or ChoiceRidge recovery exercise.
Short answer
Define the maximum data loss and downtime the business can tolerate, back up every required component, keep an independent copy outside the production account, protect it with encryption and restricted access, and run scheduled restore drills. Monitor backup completion, but treat a successful restore and functional check as the real proof.
Start with RPO and RTO
Two targets turn vague reassurance into an engineering requirement:
- Recovery point objective (RPO): how much recent data the business can lose. A four-hour RPO means a recovery may legitimately omit up to four hours of changes.
- Recovery time objective (RTO): how long the service may remain unavailable after an incident.
Choose them per workload. A publishing site may accept a daily database copy; a store processing orders cannot. Faster targets cost more because they require more frequent capture, automation, capacity, and staff availability.
| Workload | What changes | Questions that set the target |
|---|---|---|
| Brochure site | Pages, theme, configuration | Can yesterday's edits be recreated? |
| Publication | Posts, media, comments | How many hours of submissions are tolerable? |
| Membership | Profiles, access, messages | What records have contractual value? |
| Ecommerce | Orders, stock, customer data | Can any confirmed transaction be lost? |
Back up the whole recoverable service
For WordPress, files and database are both required. Files include plugins, themes, uploads, configuration, and custom code; the database holds content, users, settings, and transactional records. Also preserve DNS exports, CDN and firewall rules, certificates or certificate-issuance instructions, cron schedules, environment variables, mail configuration, deployment code, license records, and an inventory of external services.
The WordPress documentation explicitly treats database and file backups as separate needs. A database-only copy cannot restore uploaded media or custom code. A files-only copy cannot reconstruct current posts, orders, or configuration held in tables.
Use independent and immutable copies
The familiar “3-2-1” pattern—three copies, two storage types, one off-site—is a useful starting point, but independence matters more than counting. A backup stored inside the same hosting account may disappear with account deletion, compromise, billing failure, or provider outage.
A stronger design keeps:
- the live service;
- automated versioned backups in a separate security boundary;
- an additional protected copy that normal production credentials cannot overwrite.
Use encryption in transit and at rest, multifactor authentication, least-privilege access, retention locks or immutability where appropriate, and alerts for policy changes. Record who can recover encryption keys if the primary administrator is unavailable.
Retention is a business decision
Daily copies retained for seven days cannot solve a compromise discovered after a month. Keep several time horizons—recent frequent versions for operational mistakes, weekly or monthly points for slow corruption, and any archive required for business or legal reasons. Do not retain sensitive customer data indefinitely without a legitimate purpose.
Watch backup size and duration over time. A job that “succeeds” unusually quickly may have omitted a directory or table. Monitor failed jobs, missed schedules, unexpected shrinkage, quota exhaustion, and the age of the newest usable restore point.
A restore drill that produces evidence
Restore into an isolated environment, never over production as a first test. Use documented credentials and simulate the loss of the primary host. Measure from incident declaration until the site is functionally usable.
The drill should verify more than a home page:
- database integrity and recent content or transactions;
- media, downloads, permissions, and redirects;
- login, password reset, forms, search, and scheduled work;
- checkout or payment sandbox, webhooks, stock, and email;
- TLS, DNS, cache behavior, robots directives, and analytics;
- malware scanning and credential rotation if compromise is the scenario.
Record the achieved RPO and RTO, missing dependencies, manual steps, and decisions that delayed recovery. Convert every finding into an owner and due date. Repeat after major architecture changes and on a regular schedule appropriate to risk.
Disaster-recovery runbook
A concise runbook should be usable during stress:
- Declare the incident and assign incident lead, technical lead, and communicator.
- Contain the cause before restoring, especially after compromise.
- Select a restore point based on evidence, not convenience.
- Preserve logs and a copy of the failed environment when investigation matters.
- Restore infrastructure, files, database, configuration, DNS, and integrations.
- Validate critical user journeys and data consistency.
- Communicate status and limitations accurately.
- Reopen service gradually, monitor, then complete a post-incident review.
Buying questions for a hosting backup feature
Ask where copies are stored, whether they survive account cancellation or region failure, how frequently the database and files are captured, whether restores are self-service, what retention is included, whether backups are encrypted and versioned, and how restoration behaves for large sites. Request documentation; do not infer disaster recovery from a single “daily backups” line.
Provider-managed backups can reduce work, but they do not transfer responsibility for defining recoverability. This is why the ChoiceRidge small-business hosting guide treats backup quality as one part of a wider decision. Provider-specific details belong in the individual reviews collected in the Infrastructure & Hosting hub.
Method and limitations
This guide synthesizes official WordPress backup guidance with reliability principles. It is not a compliance standard. Regulated data, payment systems, healthcare information, and complex distributed applications require specialist legal, security, and continuity review.