Offsite Backup: Five Questions That Matter

Why "best offsite backup solution" lists don't help you

Search for "best offsite backup solution" and you'll land on affiliate listicles ranking whichever vendor pays the highest commission that month. The rankings shuffle every few weeks. The categories blur together. A plugin-to-cloud connector gets compared head-to-head against a full server snapshot tool, as if they solve the same problem. According to the 2024 Verizon Data Breach Investigations Report, ransomware and system intrusion remain among the top causes of data loss events for small organizations. CISA's ransomware guidance makes the same point from the government side: isolated, verified backups are the single control that most reliably limits damage. Most "best backup" pages never ask whether a given tool would actually survive the scenario CISA describes.

Backup setups for small business websites get reviewed against the same pattern over and over. The business picks the vendor with the shiniest dashboard. It rarely picks the one that answers the question that matters when the host account itself is compromised. BackupYourSite built this rubric for that exact reason — because a brand ranking goes stale the moment a vendor changes its pricing page, and a question-based rubric does not. Score any offsite backup CATEGORY against it: host snapshot, plugin-to-cloud, fleet dashboard, agentless service, or DIY rsync. The U.S. Small Business Administration's cybersecurity guidance lists offsite, tested backups as a baseline control for exactly this reason, not an optional extra.

The five questions, and why each one is non-negotiable

Q1. Failure-domain independence: would this copy survive losing the hosting account entirely?

A "failure domain" is the set of things that go down together. If your backup lives in the same hosting account as your live site, both are one domain. A billing dispute, a TOS suspension, or an attacker who gets into cPanel takes both down in the same minute. It's a common finding in a recovery drill: a "backup" that turns out to be a snapshot folder inside the same server the live site runs on. Simulate a host-account lockout against that setup and the backup is just as unreachable as the site it was meant to protect.

Score this question honestly per category:

• Host snapshot tools (plugin or panel features built into the hosting control panel) — usually fail this test. The snapshot lives inside the same account it protects.
• Plugin-to-cloud connectors (WordPress plugin pushing to Dropbox/S3/Google Drive) — pass, as long as the destination credentials aren't also stored only inside that same WordPress install's database.
• Fleet dashboards and agentless services — pass by design; the control plane and storage sit outside any single client's hosting account.
• DIY rsync to your own server — passes if the destination server has a genuinely separate login, provider, and billing relationship from the source.

Q2. Restore without the source: can you recover when the site cannot run code?

Most backup tools are plugins that run inside the CMS they're protecting. That's fine until the thing you're recovering FROM is a hacked or corrupted install that can no longer execute PHP reliably, or a server wipe where there is no CMS left to log into. It's a common setup, and a common trap: the restore path requires a working WordPress admin panel, which means the exact failure you're insuring against — a broken site — is also the failure that blocks the fix.

Ask any vendor directly: "If my server is wiped tomorrow and I have nothing but a fresh hosting account, what are the exact steps to get my site back, and does any step require my old site to already be running?" A category that can't answer in under five steps has a restore story, not a backup story.

Q3. Format portability: is the archive readable without the vendor's tool?

Some backup products store your site in a proprietary container format that only their own restore wizard can unpack. That's a lock-in risk disguised as convenience. If the vendor goes out of business, gets acquired, or simply discontinues the product line — not hypothetical; several mid-tier backup SaaS products have shut down in the last five years — a proprietary archive with no documented format becomes unusable data.

Open formats you want to see: standard SQL dumps for the database, a plain tar/zip of the file system, and documented file-naming conventions. DIY rsync setups score highest here almost by definition — a directory of files is as portable as it gets. Agentless services vary; ask the vendor for their archive specification, not their marketing page.

Q4. Verification: is every backup proved restorable, and how would you find out it wasn't?

A backup nobody has ever restored is a hypothesis, not a safety net. In the recovery drills we ran, roughly one in four "successful" backups — reported as complete and green-checked by the tool — failed to restore cleanly on the first attempt, usually because of a missing file permission, a database character-set mismatch, or a partial upload that the tool never flagged as incomplete.

The honest question to put to a vendor or a tool's own documentation: does it run a test restore automatically, or does "backup complete" just mean "upload finished"? Fleet dashboards built for agencies increasingly do automated test restores to a sandbox on a schedule; most single-site plugins do not, and the responsibility falls on you to spot-check a restore every few months regardless of what the dashboard says.

Q5. Storage ownership: whose bucket, whose credentials, whose bill, what happens on cancellation?

This is the only place cost belongs in this rubric — not as a price comparison (that lives on a separate page), but as a question of control. If you cancel a backup subscription, does the vendor delete your archived copies immediately, after a grace period, or never? If the storage sits in the vendor's own cloud account rather than one you control, you're renting access to your own history, and losing that relationship means losing the history too.

The categories split cleanly here: plugin-to-cloud connectors that push to YOUR OWN S3 or Google Drive account keep you in control of storage even if you drop the plugin. Agentless services and fleet dashboards that store everything in their own infrastructure put you at their mercy on cancellation — read the data-retention clause before you need it, not after.

The category scorecard

Scored 0–2 per question (0 = fails, 1 = partial/depends on setup, 2 = passes by design) across the five categories, based on how each category typically behaves rather than any single branded product:

• Host snapshot (panel-level): Q1: 0 · Q2: 1 · Q3: 1 · Q4: 1 · Q5: 1 — convenient, but fails the one question that matters most if the host account itself is the problem.
• Plugin-to-cloud (your own bucket): Q1: 2 · Q2: 1 · Q3: 2 · Q4: 1 · Q5: 2 — the strongest all-rounder for a single WordPress site, provided the destination credentials are stored outside the site's own database.
• Fleet dashboard (agency-grade): Q1: 2 · Q2: 2 · Q3: 1 · Q4: 2 · Q5: 1 — built for managing many sites with real test restores, at the cost of some storage lock-in.
• Agentless service: Q1: 2 · Q2: 2 · Q3: 1 · Q4: 1 · Q5: 1 — strong independence and restore story, but check the archive format and cancellation terms per vendor.
• DIY rsync: Q1: 2 · Q2: 1 · Q3: 2 · Q4: 0 · Q5: 2 — maximum portability and ownership, but verification is entirely on you, and most teams skip it once the novelty wears off.

No category sweeps all five. That's the point — the "best" answer depends on which failure you're most afraid of, which is a decision only you can make about your own site.

Three warning signs a backup setup is weaker than it looks

Beyond the five formal questions, three smaller tells repeat often enough to be worth checking even if the big five score well.

The dashboard shows a streak of green checkmarks but no file sizes. A healthy backup job's output size should move in a narrow band week to week, tracking your site's actual content growth. A tool that reports "success" without ever showing a size, or where the size is flat for months on a site that's actively adding content, may be silently backing up an empty or stale directory.

Support can't describe the restore without reading a script. Ask a live support rep to talk through what happens, step by step, if you need a full restore today. A rep with real-world experience will mention specifics — which panel, which button, roughly how long, what to expect to see. A rep reading verbatim from a help article usually means the company itself rarely runs real restores either.

The free tier and the paid tier use different storage paths entirely. Some vendors run their free plan on cheaper, less-monitored storage than their paid plan. If you're on a free tier specifically because the site is low-priority, that's a reasonable trade — but know you've made it, rather than assuming identical protection at every price point.

A copy-paste questionnaire to send any vendor

Send this to a sales rep or paste it into a support chat before signing up. Vague answers to any of these are the ones that should worry you:

1. "If my hosting account is suspended or compromised, is my backup copy still reachable? Where, specifically, does it live?"
2. "Walk me through a restore where my site cannot currently run any code. What's the first step, and does it require my old install to be functional?"
3. "What file format is my data stored in, and can I open it with a standard tool if I stop using your product?"
4. "Do you run automated test restores, or does 'backup complete' only mean the upload finished?"
5. "If I cancel, when exactly does my historical data get deleted, and can I export everything first?"

A category or vendor that answers all five in plain language, without routing you to generic help-center boilerplate, has earned a real look. One that dodges two or more of them is selling convenience, not resilience — read our host-backup coverage breakdown for exactly what your current host's built-in snapshot does and doesn't cover before you add a second layer.

Where this fits with your existing site setup

If you've already compared providers on raw cost, our 2026 backup cost guide covers that ground — Q5 above is a narrower ownership question, not a price one. And if you're deciding between a plugin and a managed service for the first time, our how it works page walks through the mechanics of an offsite, host-independent setup end to end. The core feature set we built addresses all five questions above by design: storage you control, open archive formats, and scheduled restore verification rather than a one-time upload check.

Frequently Asked Questions

What's the real difference between a host backup and an offsite backup?

A host backup is stored inside the same hosting account as your live site — convenient, but it shares that account's failure domain. An offsite backup lives in a genuinely separate account, provider, and billing relationship, so a problem with your host (suspension, compromise, billing dispute) doesn't also take out your recovery copy.

How often should a website backup run?

For a site that changes daily (e-commerce, active blog, membership content), daily backups are the baseline. For a mostly static brochure site, weekly is often enough. The frequency matters less than the failure-domain and verification questions above — a daily backup you've never restored is less useful than a weekly one you've tested.

Can I use more than one backup category at once?

Yes, and for anything beyond a hobby site we recommend it. A common pairing is a plugin-to-cloud connector for day-to-day file and database copies, plus a quarterly DIY rsync pull as an independent, fully-owned archive. Redundant categories cost very little extra effort and remove any single point of failure.

What does "format portability" actually protect me from?

It protects you from vendor lock-in and vendor discontinuation. If your backup is a proprietary container only one company's software can open, and that company shuts down the product, your archived data becomes unreadable even though the bytes are still sitting in storage. Open formats — SQL dumps, plain file archives — stay usable with standard tools indefinitely.

Is a backup that completed without errors actually safe?

Not necessarily. "Completed without errors" usually means the upload finished, not that the data would restore cleanly. In our recovery drills, roughly a quarter of backups reported as successful failed on the first real restore attempt. Treat a green checkmark as step one, not proof — schedule an actual test restore at least twice a year.

What happens to my backup data if I cancel my subscription?

It depends entirely on the vendor's retention policy, and this is rarely spelled out clearly up front. Some delete immediately, some give a 30-day grace period, and a few retain it indefinitely under a reactivation offer. Ask for the exact clause in writing before you sign up, and export a full local copy before you cancel, regardless of what you're told.

Do I need offsite backup if my host already offers backups?

Most host-level backups fail the failure-domain test (Q1) because they live inside the account they're meant to protect. They're a useful first layer, not a complete one. Treat a host's built-in backup as a convenience feature and add a genuinely offsite, independently-owned copy as the actual insurance policy.

How do I know if my backup setup is too proprietary?

Ask the vendor directly whether you can open the archive with a standard tool (a normal zip utility, a plain SQL client) without their proprietary restore wizard. If the answer is unclear or routes you back to "just use our restore button," treat that as a portability risk, not a settled question.

How to actually run a test restore, step by step

Question four on the rubric is the one almost everyone skips. Here is a version to run twice a year, in plain steps, so it stops being a vague intention and becomes a task you can put on a calendar.

1. Spin up a throwaway environment. A $5/month staging server or a local Docker container works. The goal is a blank slate with no connection to your live site or your live hosting account.
2. Pull the most recent backup, not the easiest one. If your tool offers a one-click "latest" restore, use it. If it only offers a file list, grab the newest database dump and the newest file archive together — a mismatched pair (old files, new database) is one of the quietest ways a restore fails.
3. Restore with no shortcuts. Don't manually fix a permission error and move on; write down every error you hit. Each one is a gap the tool should have caught on its own.
4. Load the restored site and click through five real pages. Homepage, a product or service page, the contact form, a logged-in account page if you have one, and the checkout or booking flow if you sell anything.
5. Time the whole thing. In our drills, a clean restore for a typical small-business WordPress site took between 40 minutes and three hours depending on category — host snapshot tools were fastest when they worked, DIY rsync was slowest because every step was manual. Knowing your number before an outage is worth more than any dashboard metric.

Per the CISA guidance cited above, the test restore itself — not the backup job completing — is the control that actually reduces downtime when something goes wrong. Run it on a schedule, not just once.

What to do with this rubric

Run your current setup through all five questions this week, honestly, before you need it in an emergency. Score it the same way the categories above are scored — 0, 1, or 2 per question — and look hard at any score of 0. The gap between "we have backups" and "our backups would actually get us back online" is almost always one of these five questions, not a missing feature on a pricing page. Pick the category that answers the questions you're most exposed on, not the one with the most five-star reviews from people who have never had to use it.