Website Backup and Disaster Recovery: A Complete Planning Guide
A 2025 survey by Acronis found that 76% of organizations experienced data loss in the previous year, yet only 41% backed up their data daily. For websites specifically, the numbers are worse. A Plesk survey of hosting customers revealed that 30% of site owners had never tested restoring from a backup — they assumed it worked because it ran on schedule.
When the moment came to actually restore, one in five discovered their backups were incomplete, corrupted, or missing entirely. Data loss isn't a hypothetical. It happens through hacking, accidental deletions, failed plugin updates, database corruption, and hardware failures.
What separates a 10-minute recovery from a permanent shutdown is whether you have a tested backup and a documented recovery plan. This guide covers both.
The 3-2-1 Backup Rule
The 3-2-1 rule is the baseline for any backup strategy. It's simple: keep three copies of your data, on two different types of storage media, with one copy stored off-site.
For a website, that translates to:
| Copy | Location | Purpose |
|---|---|---|
| Copy 1 | Live site on your hosting server | The production version |
| Copy 2 | Automated daily backup on separate infrastructure at your host | Protects against hacks and accidental deletion |
| Copy 3 | Off-site backup in a different geographic location | Survives data center catastrophes |
Copy 1 can be destroyed by a hack or accidental deletion. Copy 2 protects against that, but if the data center has a catastrophic failure, both copies are gone. Copy 3 survives because it's physically elsewhere.
Most hosting providers handle copies 1 and 2. DuelHost, for example, runs daily automated backups covering files, databases, and email on separate infrastructure. Copy 3 is your responsibility — download a backup to your local machine or sync to cloud storage monthly at minimum.
Types of Backups: Full, Incremental, and Differential
The three main backup types trade off between storage space, speed, and restoration simplicity.
| Backup Type | What It Captures | Storage Required | Restore Speed | Best For |
|---|---|---|---|---|
| Full | Everything, every time | Highest (100% of site size per backup) | Fastest — single file to restore | Weekly or monthly snapshots |
| Incremental | Only changes since the last backup (any type) | Lowest (typically 1-5% of site size) | Slowest — must chain all increments in order | Daily backups between full snapshots |
| Differential | All changes since the last full backup | Medium (grows larger each day) | Medium — needs last full + latest differential | Compromise between full and incremental |
A typical strategy combines these: one full backup per week with daily incremental backups. This keeps storage costs low while allowing restoration to any day within the retention window.
The trade-off with incremental backups is chain dependency — if any link is corrupted, everything after it is unrecoverable. Differential backups avoid that risk since they always reference the last full backup.
What to Back Up
A complete backup covers four categories. Missing any one means an incomplete recovery.
| Category | What's Included | Why It Matters |
|---|---|---|
| Files | CMS core, themes, plugins, uploads (images, PDFs, videos), .htaccess, wp-config.php | The wp-content/uploads/ directory alone can be several GB |
| Database | Posts, pages, products, user accounts, comments, plugin settings | A website without its database is a hollow shell |
| Mailbox data from hosting-based email accounts | Many providers exclude email from backups by default — verify explicitly | |
| DNS configuration | A, CNAME, MX, TXT, SPF, DKIM records | DNS records live at your registrar, not your hosting server — export and store separately |
DuelHost includes email in daily automated backups, but many providers don't. Always verify the scope of what your backup covers.
Automated vs. Manual Backups
Automated backups run on a schedule without intervention. Manual backups require someone to click a button. The correct answer isn't one or the other — it's both.
Why You Need Both
Automated daily backups are the safety net, but automated systems can fail silently. A full disk, a permission error, a changed database password — and nobody notices until they need a restore.
Manual backups serve two purposes: creating a known-good snapshot before risky operations (plugin updates, theme changes, PHP upgrades), and verifying that the automated system actually works.
Recommended Backup Frequency
| Content Change Rate | Backup Frequency | Retention Period |
|---|---|---|
| E-commerce (daily transactions) | Every 6-12 hours | 30 days minimum |
| Blog or news site (daily posts) | Daily | 14-30 days |
| Business website (weekly updates) | Daily | 14 days |
| Portfolio or brochure site (monthly) | Weekly + before changes | 30 days |
| Staging or development site | Before and after deployments | 7 days |
The retention period matters as much as the frequency. Some malware sits dormant for weeks before activating. If your oldest backup is only 7 days old and the infection happened 10 days ago, every backup you have is compromised.
Common Data Loss Scenarios
Understanding how data loss happens helps prioritize protections.
Hacking and Malware
Sucuri's 2025 Website Threat Report found that 4.1% of all websites scanned had at least one active infection. Recovery requires restoring from a pre-infection backup and closing the vulnerability that allowed entry.
Human Error
Accidentally deleting a database table, overwriting production with a staging copy, or running an incorrect SQL query. The Uptime Institute's 2025 Data Center Resiliency Survey attributed 40% of significant outages to human error.
Failed Updates
A WordPress update that conflicts with another plugin can white-screen a site. If the update also runs a database migration that breaks mid-way, deactivating the plugin won't fix the inconsistent schema.
Hardware Failure
NVMe SSDs fail less often than spinning disks, but they still fail. Backblaze's 2025 drive stats showed enterprise SSDs with annualized failure rates between 0.5% and 1.5%. On a server with hundreds of drives, failures happen regularly.
Hosting Provider Issues
Data center outages, provider bankruptcy, or account suspension. If your only copies exist on one provider's infrastructure, a single billing dispute locks you out of everything.
| Scenario | Frequency | Recovery Difficulty |
|---|---|---|
| Hacking/malware | 4.1% of sites annually | Moderate (restore + patch) |
| Human error | 40% of significant outages | Easy (if backup exists) |
| Failed plugin/theme update | Common (monthly risk) | Easy (restore or rollback) |
| Hardware failure | 0.5-1.5% annually per drive | Low (provider handles it) |
| Provider issues | Rare but catastrophic | High (without off-site backup) |
WordPress-Specific Backup Considerations
WordPress adds complexity because data lives in two places: the filesystem and the database. Backing up one without the other produces a broken site.
Key Challenges
The wp-content/uploads/ directory contains every image and file uploaded through the media library. On a long-running site, it can exceed 10 GB. Incremental backups are almost mandatory here — re-uploading 10 GB daily wastes storage and bandwidth.
WordPress also stores serialized data in the database. If you restore a database to a different domain, serialized data breaks unless you use a tool that handles serialization correctly — WP-CLI's search-replace command or the Search Replace DB tool from Interconnect/IT.
Multisite installations multiply the complexity. Each sub-site has its own database tables, and some plugins store data in tables that don't follow WordPress naming conventions. A backup tool that works on single-site WordPress may miss tables on Multisite.
Disaster Recovery Planning: RTO and RPO
Backups without a recovery plan are like a fire extinguisher locked in a safe. Two metrics define any disaster recovery plan:
| Metric | Definition | Example |
|---|---|---|
| Recovery Point Objective (RPO) | Maximum acceptable age of restored data | RPO of 24 hours = accept losing up to one day of changes |
| Recovery Time Objective (RTO) | Maximum acceptable time from disaster to operational | RTO of 4 hours = site must be back within 4 hours |
Your RPO determines backup frequency. Your RTO determines restoration speed. Together, they shape the disaster recovery budget.
According to ITIC's 2025 Hourly Cost of Downtime Survey, 91% of mid-size and large enterprises reported that a single hour of server downtime costs more than $300,000. For small businesses, Gartner research estimates the average cost at $137-$427 per minute.
For most small to mid-size websites, an RPO of 24 hours and an RTO of 2-4 hours is realistic with daily automated backups and a documented recovery procedure.
Testing Backup Restoration
Veeam's 2025 Data Protection Trends Report found that 58% of backup restorations fail to meet recovery objectives because the backup was never tested before it was needed.
Testing isn't optional. A backup that's never been restored is a backup that might not work.
The Test Process
- Restore to a staging environment (a subdomain or separate hosting account)
- Verify the site loads
- Check that database content is current
- Confirm forms submit correctly
- Validate that media files display
Document how long it took — that's your actual RTO, not the theoretical one.
DuelHost's DirectAdmin control panel allows one-click restoration from any daily backup, making testing straightforward. Restore to a subdomain, verify, then delete the test instance. The process takes 15-30 minutes for a typical WordPress site. Schedule quarterly at minimum.
Off-Site Backup Strategies
Relying solely on your hosting provider's backups violates the "1" in the 3-2-1 rule. Three strategies work well together:
| Strategy | How It Works | Cost | Effort |
|---|---|---|---|
| Cloud storage sync | UpdraftPlus or DirectAdmin pushes archives to S3, Backblaze B2, or Google Cloud | ~$0.50/mo for 10 GB on B2 | Automated |
| Secondary hosting account | Budget account at a different provider for storing archives | EUR 3-5/mo | Semi-automated |
| Local downloads | Full backup to local machine or NAS monthly | Free | Manual (set calendar reminders) |
Combine automated cloud sync (daily) with periodic local downloads (monthly). Automate what you can, set calendar reminders for what you can't.
Frequently Asked Questions
Does my hosting provider's daily backup cover everything?
It depends on the provider. Some daily backups include only files, not databases. Others exclude email. Check your host's documentation or ask support. Providers like DuelHost include files, databases, and email in daily automated backups — but always verify the scope rather than assuming.
How long should I retain backups?
At least 14 days for active websites, 30 days for e-commerce or sites handling customer data. The retention window needs to exceed the time it typically takes to detect a problem. Malware that sits dormant for two weeks won't be caught by a 7-day retention window — every available backup will already contain the infection.
Can I rely on WordPress backup plugins instead of host-level backups?
WordPress plugins like UpdraftPlus and BlogVault work well for WordPress-specific data, but they can't back up email accounts, DNS configurations, server-level cron jobs, or non-WordPress files and databases on the same hosting account. Use them as an additional backup layer (copy 3 in the 3-2-1 rule), not as a replacement for host-level backups.
What's the fastest way to restore a hacked WordPress site?
Identify the infection date using security scan logs or file modification timestamps. Restore from the most recent clean backup before that date. After restoration, update all plugins, themes, and WordPress core, then change every password (admin, database, FTP, hosting panel). With a working backup, this takes 30-90 minutes. Without one, manual cleanup runs 8-20 hours with no guarantee all malware is removed.
How do I know if my backups are actually working?
Test a restoration. Schedule a quarterly restore to a staging environment. Check that the site loads, content is current, media files display, and forms work. If you've never tested a restore, do it this week — discovering a failure during a test is inconvenient, discovering it during an actual disaster is catastrophic.
Your Next Step
Log into your hosting control panel and check three things: when the last backup ran, what it included (files, database, email), and whether you can restore from it without contacting support. If any of those answers are unclear, download a full manual backup today and store it on cloud storage or your local machine. Then set a calendar reminder to test a full restoration next quarter. Twenty minutes of preparation now prevents the kind of data loss that closes businesses permanently.