The 3-2-1 Backup Rule, Audited on a Real Site

Quick answer: The 3-2-1 rule — three copies of your data, on two different types of media, with one copy offsite — comes from photographer Peter Krogh, who coined it for archiving irreplaceable image libraries, not websites. Applied to a WordPress site, most setups that claim to follow it actually fail on the third digit, because their "offsite" copy shares a login, a billing account, or a hosting provider with the primary site. If a single compromise or a lapsed card can take down two of your three copies at once, you don't have 3-2-1. You have one copy with two names.

This guide walks the rule digit by digit against a real WordPress stack — database, uploads, theme, wp-config, server config — shows the specific failure most sites hit, and gives you a ten-minute scorecard to check where your own setup actually stands.

Where the 3-2-1 Rule Actually Comes From

According to Peter Krogh, a photographer and author of The DAM Book, he formulated the 3-2-1 rule in the mid-2000s for professional photographers managing archives of raw image files — assets with no source of truth beyond the original capture. Lose the archive, lose the work permanently. Krogh's framing was blunt: if a piece of data exists in only one place, it does not exist. The rule spread from photography into general IT backup practice over the following decade because the underlying logic holds for any dataset you cannot regenerate — and a live WordPress site, with its accumulated posts, orders, customer records and years of SEO equity, qualifies.

The rule is deliberately simple to state and easy to get wrong in practice, which is the whole reason it needs auditing rather than assuming:

• Three copies — the original plus at least two backups. Not "the original and one backup," which is common but is 2-1-0, not 3-2-1.
• Two different media types — not two copies on the same disk array, the same database engine, or the same storage vendor's redundancy. A primary MySQL instance and a nightly snapshot of that same instance's disk are one medium, however many "copies" the snapshot tool reports.
• One copy offsite — physically or logically separated from the location, account, and administrative control of the original. This is the digit almost every WordPress backup setup gets partially right and calls fully solved.

Mapping the Rule Onto What a WordPress Site Actually Is

"Backup your WordPress site" sounds like one object. It's five, and each behaves differently under a host failure or a compromise:

A backup plan that only covers the database — common with lightweight export plugins — leaves four of five components unprotected. A restore after a host-level incident recovers your posts and loses your media, your redirects, and your SSL setup. That's not a 3-2-1 failure yet; it's a scope failure that happens before the rule even applies. Fix scope first, then audit copies.

The Failure-Domain Test: The Question Every "Offsite" Backup Needs to Answer

Here is the test that catches almost every WordPress backup setup that thinks it's covered: would this copy survive the same event that could take out the primary? Walk through three concrete scenarios and ask if your second and third copies are still standing after each:

1. The hosting account is suspended — non-payment, an abuse flag, a provider-side incident. If your "offsite" backup is a snapshot feature the host itself provides, it is suspended along with the account. It shares a failure domain with the primary, full stop, regardless of what marketing material calls it — see what web hosts actually cover for how far that snapshot coverage typically extends before this scenario hits.
2. wp-admin is compromised — a credential-stuffed login or a vulnerable plugin gives an attacker admin access. If your backup plugin's storage destination is authenticated via credentials stored in that same WordPress install (an API key in the plugin's own settings page, readable from wp-admin), the attacker who compromises the site can also delete the backups it made of itself.
3. The card on file lapses — a subscription backup service, a cloud storage tier, or the hosting plan itself. If the same card funds your hosting and your backup storage, one billing failure removes both at once. This is the "same failure domain" trap that "it's in the cloud" language quietly hides. Google Drive, Dropbox, or S3 storage tied to the same account credentials, the same card, or the same admin email as the site you're protecting is not a second failure domain. It's the same one wearing a different login screen.

"It's in the cloud" answers a storage-medium question, not an offsite question. Cloud storage genuinely satisfies the "two different media" digit — object storage is a different medium from a spinning disk under your host's control. It does not automatically satisfy "offsite" in the failure-domain sense, because offsite is about administrative and financial independence, not physical location. A Google Drive folder authenticated with the same Google Workspace login you use to manage the site's DNS is offsite geographically and onsite administratively. If that login is compromised or that Workspace account is suspended, the backup goes down with everything else.

A Worked Example: Two Sites, One Attack, Two Different Outcomes

Two client sites, same agency, same night. A vulnerable contact-form plugin gets exploited on both, and the attacker gets wp-admin access on each. Here's how the 3-2-1 audit plays out differently for each, because the difference isn't the attack — it's the backup architecture behind it.

Site A runs a well-known backup plugin configured to push nightly archives to a Google Drive folder. The Drive connection was set up once, years earlier, using the same Google account the site owner uses for the domain registrar and the hosting panel's SSO login. The attacker, now inside wp-admin, finds the plugin's settings page, sees the connected Drive account, and — because credential reuse across this owner's accounts is common — the same session cookie that gave them wp-admin also had an open browser tab logged into that Google account. They delete the last four weeks of backups before encrypting the uploads directory for a ransom note. Copy count: was 3, now 1. The rule wasn't wrong; the implementation shared a failure domain the owner never audited.

Site B runs the agentless SSH-pull model described below. The attacker gets the same wp-admin access, but there is nothing in the WordPress install that references the backup system at all — no plugin, no settings page, no stored API key, because the backup service authenticates outward-in on its own schedule rather than inward-out from the site. The attacker can deface pages and rewrite content, and does. When the agency restores from the previous night's pull the next morning, the restore is clean, because the compromise never had a path to the copies protecting it. Copy count: still 3. Nothing about Site B's WordPress configuration was more secure than Site A's — the contact-form vulnerability existed on both. The difference was entirely in whether the backup credentials lived somewhere the compromise could reach.

This is the practical shape of the failure-domain test from the previous section: it's not a hypothetical, it's the exact mechanism by which "we had backups" turns into "we had backups that got deleted along with everything else."

Where Should You Actually Store the Offsite Copy?

"Store it in the cloud" is not a location — it's a category with wildly different failure-domain properties depending on which account holds the keys. Four common choices, rated against the failure-domain test above:

Notice the pattern: it's not the storage medium that determines offsite status, it's whether the account, login and billing relationship to that storage is genuinely separate from the site's own administrative surface. A dedicated cloud-storage account with a unique password and no single-sign-on tie to the site scores identically to a purpose-built backup service on this test — the purpose-built service just makes that separation the default instead of a manual setup step someone has to remember and maintain.

A 10-Minute 3-2-1 Scorecard for Your Own Site

Fill this in honestly. Most sites score 2 or 3 out of 6 the first time through, and that's the point of running the check before you need a restore, not after.

A "yes" on every row means you've satisfied 3-2-1 in the sense the rule was written for — not just in the sense that a dashboard shows a green checkmark. Our own step-by-step breakdown of how BackupYourSite runs its backups shows one way to satisfy every row by construction rather than by careful configuration — worth comparing against however your current setup answers row four and five specifically, since those are where most stacks quietly fail.

When 3-2-1-1-0 Is Worth the Extra Steps — and When It's Overkill

3-2-1-1-0 extends the original rule with two additions that became standard advice after ransomware started specifically targeting backup infrastructure, not just primary data:

• The extra "1" — one copy immutable or air-gapped. A backup that cannot be modified or deleted for a set retention window, even by an account with admin credentials. This matters specifically against ransomware that, once it has admin access, goes looking for backup storage to encrypt or delete before encrypting the primary — a well-documented pattern in real ransomware playbooks. If your threat model includes "an attacker with wp-admin access deliberately targets my backups," immutability is the digit that stops them.
• The "0" — zero errors on backup verification. Not "the job reported success" but "the backup was actually opened, restored to a test environment, and confirmed to contain what it should." A backup job can report success while producing a corrupted or incomplete archive — this is the single most common reason backups fail silently for months before anyone notices.

For a small brochure site with no e-commerce and no customer PII, 3-2-1 with a monthly manual restore check is usually proportionate — the operational overhead of true immutability rarely earns its keep at that scale. For a site handling transactions, storing customer data, or representing meaningful revenue if it goes down for a day, the extra "1" and "0" stop being nice-to-haves. The right question isn't "should I do 3-2-1-1-0." It's "what does a successful attack on this specific site cost me, and does that number justify the extra configuration?"

How an Agentless SSH Pull Satisfies the Offsite Digit by Construction

Most WordPress backup plugins push: code running inside the WordPress install initiates the connection outward to cloud storage, using credentials the plugin itself holds. That architecture is exactly what fails the login-independence row on the scorecard above — if wp-admin is compromised, the credentials the plugin uses to push backups are sitting right there in the plugin's own settings table, readable by whatever compromised the site in the first place.

An agentless SSH-pull model inverts that. Nothing runs inside WordPress. A separate system outside the site's infrastructure connects in over SSH on its own schedule, reads the database credentials from wp-config.php at the moment of the run — not stored anywhere plugin-side — archives the files, dumps the database, and streams both back over the same channel to storage the site's own admin panel has no access to and no knowledge of. That's the mechanic behind how BackupYourSite runs its backups: the pulling system's credentials never touch the WordPress install, so a WordPress-level compromise has nothing to reach for on the backup side. The offsite digit stops being a configuration choice you have to remember to get right and becomes a property of the architecture — there's no plugin settings page holding a key an attacker could find, because there's no plugin.

This also sidesteps the billing-independence row without extra effort: because the backup pull requires no code or account credentials on the WordPress side, the service funding it is inherently a separate account from whatever pays the hosting bill, unless you deliberately wire them together. This is the single architectural choice that most reliably turns a "usually offsite" setup into an "always offsite" one — because it removes the human step where someone reuses a login or a card out of convenience.

The Component Most Audits Skip: Server and DNS Configuration

The scorecard above focuses on copies and failure domains, but it assumes the backup actually contains what a restore needs — which loops back to the scope problem from earlier in this guide. If you've never confirmed what your backup covers, start with what actually counts as a WordPress backup before auditing how many copies of it you keep; copy count is irrelevant if all three copies are missing the same thing.

Database and files get most of the attention because they're what backup plugins are built to grab. Server-level configuration — PHP version pins, cron schedule definitions, redirect rules in .htaccess or an Nginx config, SSL certificate setup, DNS records at the registrar — sits outside WordPress entirely and is almost never captured by a WordPress-side backup tool, plugin or otherwise. It only shows up as a gap during a full host migration or a from-scratch restore, which is exactly the scenario the 3-2-1 rule is meant to protect against and exactly the scenario where "I thought I had backups" turns into a multi-day rebuild.

Two ways to close this gap without much overhead. First, keep a short plaintext runbook — PHP version, cron entries, any non-default web-server rules, DNS records with TTLs — in the same offsite location as your other backups. Update it whenever server config changes; it's cheap and gets skipped mainly because no tool prompts for it. Second, if you're already paying for a managed service, confirm explicitly whether "we back up your site" in their materials includes server configuration or stops at files and database. Most marketing copy in this space, ours included, is specific about scope if you read the feature list rather than the headline. It's worth checking rather than assuming either way.

How This Guide Was Built

This scorecard and the failure-domain framing exist because the specific pattern of "offsite" backups sharing a login or a card with the primary hosting account shows up often enough, across otherwise well-configured sites, that it's worth writing down as a standalone check rather than a footnote. The origin material on the rule itself is Peter Krogh's own writing and talks on digital asset management for photographers. The extension to 3-2-1-1-0, according to the CISA StopRansomware guidance, reflects post-2020 direction from backup and security vendors responding to ransomware that specifically targets backup infrastructure; that guidance recommends offline, immutable, and tested backup copies as a core defense. Where this guide differs from most 3-2-1 explainers is scope: rather than restating the rule in the abstract, it maps each digit onto the specific parts of a WordPress install and the specific way each one tends to fail in practice, based on the failure patterns above.

What to Do This Week

Run the scorecard above against your actual setup before assuming the answer. If you score 6 for 6, you're done — keep testing restores on a schedule, since that's the row that decays fastest without anyone noticing. If a row failed, start with login independence and billing independence; those two are what actually determine whether a single compromised account can take out more than one of your three copies at once. Everything else on the checklist is easy to fix with configuration. Those two usually require rethinking which account funds and authenticates the offsite copy — which is the whole reason "it's in the cloud" keeps getting mistaken for "it's offsite" in the first place.

Frequently Asked Questions