Ask ten agencies where their client backups are stored and you'll get a lot of confident answers that dissolve under one follow-up question: could you restore that site if your management tool disappeared tomorrow?
For most cloud management platforms, the honest answer is no. ManageWP keeps backups on its own AWS S3. WPMU DEV stores snapshots against your account with quotas per tier. WP Umbrella holds them in its EU cloud. In every case the archive that stands between your client and catastrophe sits in someone else's bucket, under someone else's account, governed by someone else's retention policy.
The four failure modes of vendor-hosted backups
1. The churn trap
The moment you cancel, your backup history starts evaporating — sometimes immediately, sometimes after a grace period. This is not an accident; backup lock-in is the strongest retention lever a management tool has. You should be staying with a tool because it's good, not because leaving means starting your retention window from zero.
2. The correlated outage
The day you most need a backup is often a bad day for infrastructure generally. If your management vendor has an incident — or just a busy restore queue — your emergency now has a dependency you can't see, staffed by people you can't call.
3. The quota squeeze
Vendor-stored backups cost the vendor real money, which is why they come with storage quotas, retention caps, and per-site pricing (we ran that math in The real cost of per-site pricing). Your backup policy ends up shaped by their COGS, not your clients' risk.
3½. The awkward client question
"Where is our data stored?" is now a standard line in client security questionnaires. "On our management vendor's cloud, we're not sure which region" is a poor answer. "In our own Backblaze account in the EU, encrypted, 90-day retention" wins deals.
You should stay with a tool because it’s good — not because leaving means losing your backup history.
What good looks like: the agency-owned 3-2-1
The classic 3-2-1 rule — three copies, two media, one offsite — maps cleanly onto an agency's client sites:
| Copy | Where | What it's for |
|---|---|---|
| 1. Live site | Client's hosting | The thing itself |
| 2. Local restore points | Protected directory on the same server | Fast rollbacks: bad update, bad edit, bad plugin — restore in minutes without moving gigabytes |
| 3. Offsite archive | Storage the agency owns — S3, B2, Wasabi, Drive, SFTP | Disasters: server dies, host account lost, ransomware |
Notice what's not on that list: your management vendor's cloud. The control plane's job is to orchestrate backups — schedule them, verify them, alert on failures, drive restores — not to warehouse them.
Two honest caveats about local restore points, because this architecture only works if you respect them. First, local-only backups die with the server — they are a rollback mechanism, not disaster recovery, which is why an offsite destination should be treated as mandatory, not optional. Second, restore points consume disk on the client's hosting, so they need a hard retention cap and enough headroom on the account — ask any tool how many runs it keeps and what it does when the disk fills.
The economics are the tell
Here's a useful heuristic when evaluating any tool: find the vendor's biggest marginal cost, and you've found the thing their pricing and product decisions will bend around. For cloud backup vendors that cost is storage and egress. It's why quotas exist, why retention is short, why restores can be throttled, and why prices scale per site.
We designed WPClientHub's backups so that cost doesn't exist: the restore point is built on the client's own server and stays there, and we store metadata only — manifests, checksums, sizes, schedules, success and failure. That's how the line "we can't lose your backups, because we never have them" gets to be literally true, and it's why our tiers don't meter storage.
Now the part an article arguing for offsite copies has to say out loud about its own author. WPClientHub does not replicate your archives offsite yet. Today it fills row 2 of that table — fast local restore points, on the machine you already administer, with the control plane holding nothing — and it does not fill row 3. Replication to your own S3, B2, Wasabi or SFTP destination is the next thing we are building; it is not a checkbox on any of our plans, and you should not buy us today expecting it. Until it lands, whatever offsite copy you have — a host snapshot, a nightly rsync, a manual quarterly pull — is still doing the disaster-recovery job, and you should keep it.
Restores are the actual product
A backup that hasn't been restored is a hypothesis. Whatever storage you choose, insist on three restore paths:
- One-click restore from the dashboard, for the routine bad-update case. (Worth being direct about our own gap here: WPClientHub does not have this yet — today we ship the second and third paths below, and the dashboard restore is being built alongside offsite replication.)
- A standalone restore script — a single file you can upload next to an archive and run when WordPress itself is down. If your tool can't restore a site that can't boot, it doesn't really have restores.
- Raw access — because the archives are in your bucket, you can always download them and rebuild by hand. No support ticket required.
And schedule a quarterly restore drill on a staging box. Twenty minutes, four times a year, buys you the only thing a backup system is for: certainty.
The checklist
- Backups replicate to storage in your name (S3/B2/Wasabi/Drive/SFTP).
- Local restore points exist for fast rollbacks — with retention caps.
- Offsite is treated as mandatory rather than as an upsell — by the tool, or failing that, by you.
- A standalone restore path exists for dead sites.
- Leaving your management tool costs you zero bytes of history.
If your current setup fails more than one of those, it's worth an afternoon to fix — ideally before the day it matters. Start free with three sites and point your backups at your own bucket.