Why an Off-Host Copy Is the Only Backup That Survives

At 09:12 on a Tuesday the site answered with a holding page. A card had expired, the host had suspended the account, and the suspension covered everything inside it: the database, the files, the mailbox, and the backup directory a plugin had been filling since 2024. The owner had three years of nightly archives. Every one of them sat behind the login that had just stopped working.

That is the failure an off-host copy exists for, and it is more common than a failed disk. Accounts get suspended over a declined card, a phishing report, a resource overage or a terms complaint. When it happens the host does not negotiate at nine in the morning; it locks the door and works through the support queue in order. A copy inside the locked door is not a backup. It is another file in the evidence locker.

The useful definition is narrow. A backup is a copy of the site and its database, taken at the same moment, stored where the failure that takes the site cannot reach it. Off-host means a different provider, a different account and a different credential. Everything else is a snapshot, which is a fine thing to have after a bad update and useless after a lost account.

Disclosure: some links on this page are affiliate links, and WPSifero may earn a commission if you buy through them. The price is the same either way, and the argument below does not depend on which product you pick: the test is where the copy lives, not whose logo is on the dashboard.

A copy inherits every failure of its location

Backup advice usually starts with frequency. Frequency is the easy part. The question that decides whether a restore is possible is the failure domain: the set of events that take out the site and the copy in one move. A copy is only as good as the failures it is outside of.

The pattern in that table is the whole idea. Each step removes one class of failure, and only the last row removes the class that people actually hit. A host snapshot is genuinely useful, and it is sold as a backup, but it lives in the same commercial relationship as the site. When the relationship ends badly, both sides of it stop.

There is a second inheritance that gets less attention. A backup process running on the site uses the site's credentials, its PHP process and its filesystem permissions. If an attacker gets code execution, they get the backup credential too. That is why the copy needs a credential that can write and cannot delete, and why the destination needs versioning that the writer cannot turn off.

The suspension is the failure nobody budgets for

Disk failure is rare on modern infrastructure and usually handled by the provider. Account failure is common, and it is handled by nobody. The sequence is familiar: a card expires, dunning emails land in an inbox nobody reads, the grace period passes, and the account is suspended. The site is not deleted, which makes it worse, because the owner can see the holding page and cannot reach the data behind it.

Two habits remove most of the risk. The first is billing that does not depend on one card: a second payment method on file, a calendar reminder a week before expiry, and an account contact that is not the same mailbox hosted on the account. The second is an access path to the copy that does not run through the site. If the only way to reach the backup is a plugin screen inside WordPress, then the backup is down whenever the site is down.

Keep the destination's login separate from everything else. A dedicated email address, a password manager entry, and hardware two-factor authentication on the storage account. The storage account is now part of the recovery plan, so it deserves the same treatment as the domain registrar. Losing it is a second outage on top of the first.

Object storage is the cheapest place to put the copy

Object storage is the default answer because it is priced for exactly this: a large, cold, durable bucket that nobody reads until something breaks. The three providers that come up most often are S3, Backblaze B2 and Cloudflare R2. All three support versioning, lifecycle rules and server-side encryption. The differences that matter for a WordPress backup are egress pricing and how the tool you already use talks to them.

The setup is less work than it sounds. Create the bucket in a second account, with a second payment method. Turn on versioning. Turn on default encryption. Create a key that can write and list but not delete. Then point the backup job at it. A database export and an archive of the files are the whole payload:

wp db export - | gzip > /tmp/site-db.sql.gz
tar -czf /tmp/site-files.tar.gz -C /var/www/site wp-content wp-config.php .htaccess
aws s3 cp /tmp/site-db.sql.gz s3://site-backups/db/2026-10-20.sql.gz
aws s3 cp /tmp/site-files.tar.gz s3://site-backups/files/2026-10-20.tar.gz

Two details are worth getting right on the first attempt. Exclude the cache directory and any local backup directory from the file archive, or every run will copy the previous run. And keep the database dump and the file archive under the same timestamp, because a restore needs the pair. A bucket full of files from Monday and databases from Sunday is a puzzle, not a backup.

Versioning is the part that pays for itself during an incident. A compromised site that keeps writing to the same object path will overwrite good copies with infected ones. Versioning keeps the earlier object, and object lock goes further by making a version immutable for a fixed period. Both are configuration, not code, which is the right place for a control that has to work when the site is compromised.

A copy nobody checks is a rumour

The most expensive failure in this area is quiet: the job runs, reports success, and writes nothing useful. A plugin's green tick is the plugin grading its own homework. It knows the job did not throw an exception. It does not know that the archive is 12 KB because the database connection failed, or that the destination rejected the upload with a quota error the plugin logged as a warning.

Put the check outside the site. A small scheduled function anywhere else can list the bucket and assert three things: an object exists for today, its size is within the expected range, and the last modified time is recent. If any of those is false, send a message to a channel somebody reads. That single check catches more real failures than any dashboard, because it does not share a process with the thing it is checking.

Then check the contents, not only the object. Once a month, download the newest archive, list the tar, and open the dump enough to see the table list. Once a quarter, restore it somewhere and log in. The drill is the subject of its own article, and the point here is simpler: an archive that has never been opened is a hypothesis.

What this costs, and when it is overkill

The do-it-yourself version costs a bucket, a key and an hour of setup. For a small site, a weekly database dump and a weekly file archive are enough, with the host's daily snapshot covering the fast rollback. That combination costs close to nothing and survives the failures that matter. The free tooling is genuinely sufficient: WP-CLI for the export, tar for the files, and the provider's own CLI or rclone for the transfer.

Paid services remove the maintenance. Jetpack's backup service keeps copies on Automattic's infrastructure, off the site's disk and outside the hosting account, with a restore that runs from a control panel rather than from WordPress. That is the property this article is about. It is a paid addition, so compare the current price against a bucket and the hour a quarter you would spend on it.

Hosts such as SiteGround include daily snapshots and a restore flow in the panel. Useful, and not off-host in the sense used here, because the snapshot lives in the same account as the site. Buy the host for the hosting. Add the independent copy separately, even if the host's snapshot is the one you reach for first.

The overkill case is real. A five-page brochure site whose content changes twice a year, on a host that keeps off-provider snapshots and answers support within an hour, does not need a second storage account and a monthly drill. Two exports a year, downloaded to a laptop and to a second cloud drive, cover it. The calculation changes the moment the site takes money, holds customer data or is the only copy of years of writing. At that point the bucket and the drill are cheaper than the alternative, which is explaining to a client why the backups were in the suspended account.

Set it up this afternoon

1. Create a storage account with a second payment method and hardware two-factor authentication.
2. Create a bucket with versioning and default encryption, in a region you can name.
3. Issue a key that can write and list, not delete. Store it outside the site's document root.
4. Schedule the database export and the file archive from cron or from the host, not from wp-cron.
5. Add the external check: today's object exists, its size is plausible, its timestamp is recent.
6. Put the restore steps in a file that is not inside WordPress, with the bucket name and the credentials path.
7. Book the quarterly restore drill in the calendar before the first backup runs.

The decision rule is one sentence. If the host disappeared this afternoon, the site can be rebuilt from a copy held by a company that has never heard of the host, using credentials that do not live on the site. If that sentence is true, the rest is tuning. If it is not, the backup count on the dashboard is measuring the wrong thing.