Last year, a client called me in a panic at 11 PM. Their hosting provider had experienced catastrophic hardware failure, and the backup system—which they'd been meaning to upgrade for six months—had failed alongside the primary storage. Four years of content, customer data, and custom development work: gone. They weren't alone. The same hardware failure affected dozens of customers on that server cluster.
That call cost them thousands in emergency recovery services, and we only recovered about 60% of their data. The 40% that was lost included two years of customer transaction records that were legally required to be retained. Don't let this be you.
The 3-2-1 Backup Strategy
The industry-standard backup strategy is called 3-2-1: three copies of your data, on two different types of storage media, with one copy stored offsite. This isn't arbitrary—it's a framework that addresses the most common failure scenarios.
Your primary website is copy one. Your first backup (on the same server, but separate disk) is copy two. Your offsite backup (cloud storage, a different data center, or even an external drive at your office) is copy three. If the server's disk fails, you have copy two. If the entire server room burns down, you have copy three.
What Exactly Needs to Be Backed Up
Most people think "files," but a complete website backup includes several distinct components:
Database. For WordPress, WooCommerce, or any database-driven application, your database contains users, posts, comments, orders—essentially all your dynamic content. Database backups should be taken more frequently than file backups since content changes more often.
Files. Everything in your public_html or www directory. Uploaded images, theme files, plugin code, custom scripts. For most sites, these change less frequently than the database, but they still need regular backup.
Configuration files. Your .htaccess, wp-config.php, nginx.conf, or similar configuration files contain settings that took time to get right. These rarely change, but losing them means rebuilding your configuration from scratch.
Email. If email is hosted on your web server (rather than a dedicated email provider like Google Workspace or Microsoft 365), it needs to be included in backups. Many hosts separate email storage from web hosting storage—make sure you know where your email actually lives.
Backup Frequency: Finding the Right Schedule
Backup frequency depends on how much data you can afford to lose. If you publish four blog posts per day, daily backups mean losing up to 24 hours of content. Hourly backups reduce that to one hour. The question is: what's the cost of that potential loss versus the cost of more frequent backups?
For most sites, daily database backups and weekly full backups hit a good balance. For e-commerce or sites with user-generated content, I recommend at least hourly database backups and daily full backups. The storage cost difference is minimal compared to the potential data loss.
Testing Your Backups
Here's the step most people skip: testing your backups. I've seen it too many times—someone has backups running for years, then they need to restore, and the backup file is corrupted. Or the backup process runs but produces an empty archive because a file was locked. Or the backup was working fine until a software update changed the database schema and now the backup script errors out silently.
At minimum, do quarterly restore tests. Pick a random date from two weeks ago, attempt a restore to a staging environment, and verify you can actually access your content. Document the steps so if you ever need to restore under pressure, you have a checklist rather than improvising.
Hosting-Provided Backups: What to Know
Most hosts offer some form of backup system. These are better than nothing, but don't rely on them as your only backup. Hosting backups are typically: limited in retention (often just 7-14 days), not guaranteed (hosts can suspend or delete backups at any time), and focused on server-level recovery (restoring your entire server, not individual sites).
Read your host's backup SLA carefully. "We perform daily backups" might mean they create backups, not that they guarantee they're restorable. "Backups are kept for 30 days" might mean on tape in a warehouse somewhere, not available for quick restoration. When your site goes down at 2 AM on a Friday, "we can restore from backup" isn't comforting if the backup process takes three days to complete.
Offsite and Cloud Backup Solutions
For critical sites, I use a combination approach: the host's native backups for convenience, plus a third-party cloud backup service for redundancy. Services like CodeGuard (for WordPress), ManageWP Backup, or duplicator-based WordPress backups to S3 or Backblaze B2 give you independent, tested backups that survive host-level failures.
The cost is minimal—cloud backup services typically run $5-20/month for small sites. Compare that to a single data loss incident. For business sites, the ROI calculation is obvious.
Disaster Recovery Planning
Backups are only half of the equation. You need a disaster recovery plan: the documented steps for restoring service when something goes wrong. This should include who to call (host support, your developer, your backup service), what systems need to be restored in what order, and what communication needs to go out to users while you're resolving the issue.
For client sites, I document the recovery plan and store it outside the hosting environment—typically in their project management system or a shared document folder. When disaster strikes at midnight, you don't want to be searching your email for the host's support number.