A backup that lives on the same server as the site is a convenience, not a backup. When the host account is suspended, the server is compromised or someone deletes the wrong directory, the copy goes with it. The fix is a second copy in storage that you own, and the three common choices are Amazon S3 (or anything S3-compatible), Backblaze B2 and Google Drive. They are not interchangeable.
Why "storage you own" matters
Two questions decide whether an offsite copy is worth having. Who holds the credentials, and what happens to the copies if you stop paying a vendor?
If your backup tool stores the copies in its own bucket, you are renting a promise. If the copies sit in a bucket in your account, you can read them with any S3 client, keep them when you change tools, and prove to a client exactly where their data is. We covered the ownership argument in more detail in where should WordPress backups live. This post is the practical follow-up: which storage, and how to set it up without creating a new problem.
S3 and S3-compatible storage
Amazon S3 defined the API that most of the rest of the industry copies. Backblaze B2, Cloudflare R2, Wasabi, DigitalOcean Spaces and MinIO all speak an S3-compatible dialect, so a tool that supports "S3-compatible" storage with a custom endpoint works with all of them.
What you get on S3 proper: fine-grained IAM permissions, lifecycle rules to move old backups to cheaper tiers or expire them, versioning, and object lock for backups that cannot be deleted or overwritten for a set period. That last one is the strongest protection against ransomware or a compromised credential, and it is worth the setup time.
What you pay for: storage per GB-month, plus requests, plus egress when you download. Egress is the line item that surprises people, because you only pay it on the day you restore.
Backblaze B2
B2 is usually the value pick for backup archives. It offers an S3-compatible API, straightforward per-GB pricing and no need to learn IAM. For an agency it is often the simplest place to start.
The trade-offs are practical. Fewer regions than the big clouds, a smaller ecosystem of surrounding tooling, and fewer lifecycle features than S3. For a backup archive none of those usually matter. Check the current pricing page before you commit, since egress terms are the part that changes.
A useful habit with any provider: create one bucket per client or per site group, not one giant shared bucket. It makes retention, cost attribution and offboarding a client much cleaner. When a client leaves, you export their bucket, hand it over and delete it.
Google Drive
Drive is the option agencies choose because they already pay for Google Workspace and the storage is sitting there. It works, with caveats worth knowing before you build a process on it.
- It is designed for people, not for machines writing thousands of objects. API rate limits are tighter than object storage, and a site with many small files can make uploads slow.
- Permissions are folder sharing, not scoped credentials. The token that lets a tool write backups can often see more than you meant it to.
- Backups live inside an account tied to a person. If that person leaves and the account is deleted, so is the archive. Use a shared drive or a dedicated service account, never a personal login.
- Storage limits are per account or per plan, so a runaway retention setting fills the drive that also holds your invoices.
Drive is fine for a small portfolio, a second copy, or a client who insists on having the backups in their own Google account. For anything you would call the primary offsite copy across dozens of sites, object storage is easier to reason about.
Setting it up so it does not bite you
Whichever you pick, the same handful of rules apply.
- Create a credential that can write to the backup location and nothing else. On S3 and B2 that means an application key scoped to one bucket, not your root account keys.
- Prefer write and read without delete where the provider allows it, and use object lock or versioning to protect against overwrite.
- Turn on server-side encryption, and decide who holds the keys. For client data, also encrypt at rest on your side if the tool supports it.
- Set retention deliberately. Keep dailies for two weeks, weeklies for two months, monthlies for a year, or whatever you can justify to the client, and write it down in the care plan.
- Test a restore from the offsite copy, not from the local one. Otherwise you have only tested the copy that dies with the server.
What it costs, roughly
Do the arithmetic before you promise a price. Take an illustrative rate of $0.005 per GB-month; this is an assumption for the sum, not a quote from any provider. Fifty sites at 5 GB each is 250 GB. With four weekly full copies and a month of deduplicated increments, suppose you hold around 1 TB. At the assumed rate that is 1,000 GB times $0.005, or $5 a month for the whole portfolio, about ten cents a site.
Change the rate to whatever your provider actually charges and the shape of the answer holds: storage is a rounding error next to your time. Egress and request fees are the numbers to read carefully, along with any minimum storage duration or minimum object size. If you bill clients for backups, this is cost you can absorb; it should not be the reason you skip the second copy.
Where this leaves you
Pick object storage for the primary offsite copy, use B2 or another S3-compatible service if you want the low-effort route, and keep Drive for the cases where a client wants the files in their own account. Scope the credentials tightly, protect against deletion, and test a restore from the offsite copy on a schedule. WPClientHub stores backups on the client's server and can copy them to your own S3-compatible storage (Backblaze B2 works through its S3 API), so the archive belongs to you and not to us. Google Drive and Dropbox are not supported destinations yet. WPClientHub is free for 3 sites if you want to try this on a real client site: connect your own storage.