Ask ten agency owners how many backups they keep per client site and you get ten numbers, and most of them were set by whatever the backup plugin defaulted to. Retention is not a storage question. It is a question about how long a problem can sit on a site before anyone notices it, and the honest answer for most care plans is "longer than seven days".

Retention is a detection problem wearing a storage costume

The job of a restore point is to be older than the problem. A broken plugin update gets noticed the same afternoon, so a daily backup from yesterday is enough. A compromised admin account, a spam-injection in the database, a payment gateway silently switched to test mode, a form that stopped sending because an SMTP plugin lost its key: these get noticed when a client calls, and clients call late. Two weeks is normal. A month is not unusual on a brochure site nobody logs into.

If your retention is seven days and the client calls on day sixteen, every restore point you own already contains the problem. You are no longer restoring; you are doing forensic cleanup by hand, at your hourly cost, on a plan that was priced for routine care. That is the scenario retention exists to prevent, and seven daily copies does not prevent it.

So the question to answer before you pick a number is: for this site, how long could something be wrong before someone tells me? Then keep restore points that reach past that.

The three windows a care plan actually needs

A workable default for a care-plan site is three overlapping windows, each answering a different kind of "when did this break?":

  • Daily for 30 days. Covers everything you or the client would notice within a month: bad updates, content mistakes, a deleted page, a broken theme change. Thirty daily points means you can also narrow down the exact day something changed, which is half of diagnosing it.
  • Weekly for 12 weeks. Covers the slow problems: injected spam links, a redirect added to .htaccess, an admin user nobody created. A quarter of weekly points lets you walk back week by week until you find the last clean copy.
  • Monthly for 12 months. Rarely restored from, often asked about. "What did the site look like before the redesign?", a contract dispute about when a page changed, a client who left in March and comes back in September wanting the old site. Twelve monthly points also covers you for the one-a-year audit question of where a client's data has been.

That is 30 + 12 + 12 = 54 restore points per site, with the oldest a year old. It sounds like a lot until you cost it, which is the next section.

For WooCommerce, membership and booking sites the daily window is not enough on its own, because a restore from last night throws away today's orders. Those sites need either more frequent database snapshots (hourly during trading hours is common) or, more practically, a restore procedure that puts back files and database separately so you can roll back a broken plugin without rolling back the orders table. Decide which before the site is on the plan, not during the incident.

What 54 restore points cost across 60 sites

Here is the arithmetic, with the assumptions stated so you can swap in your own numbers.

Assume a typical brochure site is 400 MB of files plus database, and changes by about 5 MB a day once the first full copy exists. With incremental backups (only changed files are copied after the first full one; how incremental backups work covers what can go wrong there), one site's year of retention is roughly:

  • First full copy: 400 MB
  • 30 daily increments at 5 MB: 150 MB
  • 12 weekly and 12 monthly points, which mostly share blocks with the dailies and add maybe another 200 MB of unique data in a bad case

Call it 750 MB per site, generously. Sixty sites at 750 MB is 45 GB, or 0.045 TB. Backblaze B2 lists storage from $6.95 per TB per month (pricing page, checked October 2026, backblaze.com/cloud-storage/pricing); 0.045 TB × $6.95 is about $0.31 a month. Wasabi lists $7.99 per TB per month with no egress fees (pricing page, checked October 2026, wasabi.com/pricing); 0.045 TB × $7.99 is about $0.36 a month. Most providers bill a minimum, so in practice you pay a few dollars, but the point stands.

Even if your sites are bigger and incrementals are worse than assumed, multiply by ten: $3 to $4 a month for a year of retention on sixty client sites. Across sixty care plans, that is less than one cent per site per month. Nobody has ever lost a client over retention storage cost. Agencies lose clients over the day-sixteen phone call.

Where the money actually goes is restore testing, which is labour. A restore you have never run is a hope. Pick two sites a month, restore the oldest monthly point to a throwaway location, confirm it loads and that the admin login works, write down how long it took. Twenty minutes a month buys you the right to say "yes, we can get that back" without checking first.

Where retention lives matters as much as how long

A year of restore points on the same server as the site protects you from a bad update and from nothing else. A host outage, a billing lapse, a hacked hosting account or a client who cancels the hosting in a huff takes the site and its backups together. The retention plan above assumes at least the weekly and monthly points live somewhere you control: an S3-compatible bucket in the agency's own account, not the host's "backups" tab and not the vendor's cloud. Where should your WordPress backups actually live? goes through the options; the short version is that a bucket you pay for directly is the only copy that survives every way a hosting relationship can end.

A small but real detail: when you put long retention in your own bucket, set a lifecycle rule on the bucket itself so the monthly points expire at 13 months. Retention that only exists as a setting in a plugin is one plugin deactivation away from becoming "keep forever", and a year later you are paying for and legally responsible for data you promised to delete.

Write the number into the plan

Retention is also a contract term, whether or not you have written it down. If the care-plan page says "daily backups" and nothing else, the client assumes you can restore any day they name. Put the actual windows in the plan description: "daily restore points for 30 days, weekly for 3 months, monthly for 12 months, stored in storage we control, restore tested quarterly". That sentence costs nothing, takes a support argument off the table, and is a better sales line than "daily backups" because it sounds like someone thought about it.

Then price the exceptions. Hourly database snapshots for a shop, retention beyond a year for a regulated client, or a same-day restore guarantee all cost real attention and belong in a higher tier, not as a favour on the cheapest one.

In WPClientHub, backups are incremental and go to the client's server plus the agency's own S3-compatible bucket (B2, R2, Wasabi and the like), with a restore point taken before every update; it is free for 3 sites, paid plans from $19/month.

Where this leaves you

Set retention by how late your clients tend to call, not by what the plugin defaulted to. Thirty daily, twelve weekly and twelve monthly restore points in a bucket you own costs cents per site and covers nearly every "it has been broken for a while" call you will get. Write the windows into the plan, test a restore every month, and put the lifecycle rule on the bucket. If you want to see what that looks like across a portfolio, start with your 3 worst sites for free.