Almost every WordPress site has "backups enabled" in some form. Far fewer have a backup strategy that will actually save them on the day it matters. The difference is a handful of specific, unglamorous details.
Back up files and database together, and know both are needed
A WordPress site is two things that must stay in sync: the file system (wp-content — themes, plugins, uploaded media) and the database (posts, settings, users, orders). A files-only backup misses all your content; a database-only backup misses your uploaded media and any custom code. Confirm your backup solution genuinely captures both, and check whether it snapshots them together in a consistent state — a backup that grabs the database at a slightly different moment than the files can produce subtle inconsistencies (e.g., referencing media that isn't in that file backup).
Store backups off the same server
This is the single most common backup failure mode: backups stored on the same server as the live site. If the server fails, gets compromised, or the hosting account is suspended, the "backup" is gone along with everything else. Backups need to live somewhere physically and logically separate — a different storage provider or region, not just a different folder on the same disk.
Automate the schedule, and match it to how often content actually changes
Manual backups get forgotten. Automate on a schedule that matches your content velocity: daily for an actively updated site or store, less frequent for a rarely changed brochure site — but even a low-traffic site should have some automated cadence, since "I'll remember to back up before I make changes" reliably fails eventually.
For WooCommerce or membership sites, consider that database-only incremental backups between full backups can capture order data more frequently than a full daily snapshot, so a hardware failure mid-day doesn't lose a day's worth of orders.
Test restores — this is the step almost everyone skips
A backup you've never restored from is a hypothesis, not a safety net. Corrupted archives, incomplete database dumps, and permission issues on restore are common and invisible until the moment you actually need the backup. Periodically restore a backup to a staging environment and verify the site actually comes up correctly — this is the only way to know your backup strategy works, as opposed to just running.
Keep enough history to restore from before a problem started
A compromise, a bad plugin update, or a slow-developing data corruption issue isn't always noticed the day it happens. If your retention window is only 24–48 hours, by the time you notice the problem, the only available backups may already contain it. Keep enough history (commonly 7–30 days, sometimes longer for critical sites) to have a genuinely clean restore point available.
Backups are also a security control, not just a disaster-recovery one
A clean, verified backup taken before a suspected compromise is what makes "restore and rebuild" a viable incident response instead of "manually hunt for every backdoor file across the codebase." This is worth remembering when deciding retention length — you want backup history that predates when an intrusion likely started, not just recent snapshots that may already be infected.
What a solid setup actually looks like
- Automated, scheduled backups of files and database together, at a frequency matching your content velocity
- Stored on separate infrastructure from the live site (a different provider/region)
- Retained for a meaningful window (7–30+ days depending on risk tolerance)
- Restored and verified periodically, not just trusted to exist
- Documented — someone other than you should be able to find and execute the restore process if you're unavailable when it's needed
The takeaway
"Backups are on" is not the same as "backups will save us." The strategy that actually works is automated, off-server, retained long enough to predate a slow-developing problem, and — critically — tested by an actual restore, not just assumed to be working.
