# WordPress Backup Strategy That Survives Bad Days · WPCloudLab > A WordPress backup strategy that survives bad days: the 3-2-1 rule, what to back up, sane retention, offsite storage — and why untested backups fail. Canonical: https://wpcloudlab.com/guides/wordpress-backup-strategy [Home](/)/[Guides](/guides)/Backup strategy guide · backup strategy · principles first # A backup strategy that survives bad days. A missed update shows a banner. Downtime pages you. A broken backup looks exactly like a working one — until the day you need it, which is the one day you can’t fix it. Five principles and one non-negotiable drill, tool-agnostic and honest about where backups quietly rot. 001 / the guideprinciples, then proof Backups are the only maintenance task whose failure you discover, by definition, too late. Everything else fails forward — a bad update breaks the site today, downtime alerts today. A backup fails in the past: quietly, months ago, and you find out at the exact moment it was supposed to save you. That asymmetry is why backup strategy isn’t a plugin choice. It’s a handful of principles that decide whether your worst day is a bad hour or a lost business. principle one ## 3-2-1, translated to WordPress. The old sysadmin rule still carries the weight: three copies, two kinds of storage, one offsite. For a WordPress site, concretely: - 01 Three copies. The live site, a primary backup, and a second backup somewhere else. Two is the minimum that survives one failure; three survives the failure you discover late. - 02 Two kinds of storage. Not two folders on the same disk. Host storage plus object storage (S3, R2, B2), or host plus a machine you control. Different failure modes are the entire point. - 03 One offsite. At least one copy must live outside your hosting company entirely — different provider, different account, different credentials. Hosting accounts get suspended, compromised and billing-expired; your backup must not share their fate. principle two ## Back up the files and the database. A WordPress site is two things. The files: theme, plugins, uploads, custom code. The database: every post, page, order, user and setting. Backing up only one produces a half-backup that restores to a broken site — and file-only backups are the classic mistake, where the uploads folder survives but five years of content doesn’t. The database is also where naive backups corrupt. WordPress stores serialized PHP arrays whose byte-lengths must match exactly — a careless export or charset mismatch breaks them silently. Plugins keep binary data in BLOB columns that text-mode exports mangle. Emoji and legacy latin-1 content cross character sets badly. A dump can finish without a single error and still contain wrong bytes; you find out at restore time. Or after. principle three ## Retention: two days is a trap. “Daily backups” with two days of retention sounds fine until you consider how problems are actually found. Malware is routinely discovered weeks after infection. A corrupted table can hide behind a cache for a month. If your retention is shorter than your detection time, every backup you hold is a faithful copy of the problem. Thirty days is the sane default: long enough that “we found it late” still has a clean restore point behind it, short enough to store cheaply. If storage is tight, keep a weekly copy for longer rather than shrinking the window. principle four ## Offsite and encrypted, or it doesn’t count. A backup on the same server dies with the server — same disk failure, same ransomware, same account suspension. Many backup plugins default to writing into wp-content, which means the most common backup configuration in the wild protects against almost nothing that matters. Ship copies off the box, to storage your host can’t touch. And encrypt them. A backup is your entire site in one convenient file — every user record, every order, every password hash. Sitting unencrypted in a misconfigured bucket, it isn’t a safety net; it’s a breach with a timestamp. the non-negotiable ## A backup is a hypothesis. A restore is proof. Everything above — 3-2-1, retention, offsite — is arranging hypotheses neatly. None of it tells you whether the file actually turns back into a working website. The only thing that does is restoring it. The drill, quarterly at minimum and monthly if the site earns money: - 01 Spin up an isolated environment — a local install or a scratch subdomain from your host. Never drill on production. - 02 Restore the most recent backup end to end, files and database, using your tool's actual restore path — the same one you would use at 2am. - 03 Click through like a customer: log in, open the key pages, run a search, submit a form, and on a store, open a recent order. - 04 Compare against the live site. Recent content present? Media loading? Special characters and emoji intact? Note how long the drill took — that is your real recovery time, measured while calm. Double it for panic. If any step fails, your backup strategy was a story you were telling yourself — and better to learn that during a drill than during an outage. Put it on your [monthly maintenance checklist](/guides/wordpress-maintenance-checklist) next to the tasks that merely feel productive. from our own audit ## Six ways backups rot silently. We ran a full data-fidelity audit of our own backup and restore pipeline and found six distinct bugs — every one producing backups that looked valid and restored wrong. We fixed them and turned each into a permanent automated check; the full write-up is on the [data safety page](/security). The list is worth knowing whatever tool you use: - 01 Percent-signs and URLs corrupted by WordPress's own escaping layer - 02 Binary and BLOB data mangled in JSON transport - 03 Latin-1 characters lost on legacy sites - 04 SQL comments inside real content stripped on restore - 05 Real customer tables mistaken for cache tables — and skipped - 06 Zero-byte files silently dropped from file backups Every one of these survives “backup completed successfully.” Only byte-level verification and real restore drills catch them — which is the uncomfortable takeaway of this entire guide. how we run it ## The same principles, automated. For completeness, our production setup: daily encrypted backups (Standard plans and up) shipped offsite to a private Cloudflare R2 bucket, 30-day retention with one-click restore from any day. Every backup is verified byte-for-byte at capture — truncated or empty dumps are rejected loudly, never uploaded and forgotten. Weekly restore drills into an isolated scratch database with a corruption scan do the proving on our schedule, not during your outage. And [every update](/features/safe-updates) runs against a fresh restore point. Details on the [backups page](/features/backups). 002 / questionshypothesis vs proof ## Strategy questions, answered. How often should I back up my WordPress site? Daily at minimum, plus a fresh restore point before every update. If the site takes orders or bookings, more frequent database backups are worth it — losing 23 hours of orders hurts. But frequency matters less than people think: a tested weekly backup beats an untested daily one every time. Are backup plugins good enough? They can be, if you fix the defaults: send copies offsite instead of leaving them in wp-content, turn on encryption, keep at least 30 days, and restore-test quarterly. The plugin is rarely the weak point — the unexamined configuration and the never-attempted restore are. Where should I store WordPress backups? Off your hosting infrastructure, under separate credentials. Object storage like Amazon S3, Cloudflare R2 or Backblaze B2 is ideal: cheap, durable, and unaffected by anything that happens to your server. A copy on the server itself is fine for quick rollbacks, but in a real disaster it counts as zero copies. How do I know my backups actually restore? You don't — until you restore one into an isolated environment and click through the result. That is the only proof there is. If you would rather have it proven continuously, that is the core of our service: byte-for-byte verification at capture plus weekly restore drills into an isolated database, all logged in your dashboard. free audit · we check your current backups ## Make the bad day boring. Send us your URL and we’ll tell you what your current backup setup would really recover — retention, offsite, restore path — even if the answer is “you’re fine.” [Get a free audit](/contact)[see plans & pricing →](/pricing) --- Get started: https://wpcloudlab.com/signup · Talk to an engineer: https://wpcloudlab.com/contact · Full agent index: https://wpcloudlab.com/llms.txt