Who Is Responsible for Client Website Backups?

Ask three people who is backing up a client’s WordPress site and you can get three confident answers. The client says the agency handles it. The agency’s developer says the host takes backups. The host’s terms say backups are provided on a best-effort basis and the customer is responsible for keeping their own copies. Everyone is partly right, and on the day the site needs restoring, nobody is actually accountable.

This gap is rarely about technology. Backup plugins and host snapshots are easy to set up. The problem is that responsibility was assumed rather than agreed. This post walks through who could own client backups, what each arrangement means in practice, and how to put the answer in writing so it holds up when something goes wrong.

Why backup ownership gets blurry in agency work

On a site the owner runs alone, the answer is obvious: they are responsible, whether they realise it or not. Agency work adds layers. The site may have been built by you, hosted on an account the client pays for, maintained by a contractor, and edited weekly by the client’s marketing person. Each of those parties can delete, break or corrupt something. Each assumes someone else is keeping the safety net.

Common points where the assumption breaks:

• After launch. The build contract ends, nobody signs a maintenance agreement, and the backup plugin installed during development quietly stops because its storage filled up or its license lapsed.
• When the host changes. The client moves to a cheaper plan or a new provider, and the host-level backups you were counting on no longer exist.
• When people change. The developer who set up off-site storage leaves, and the cloud account it uploads to was in their personal name.
• When the client “takes over”. The client asks for admin access, deactivates plugins they do not recognise, and the backup tool is one of them.

The parties who could be responsible

There are usually four candidates. Being clear about what each can realistically do is the first step to choosing.

The host

Many hosts keep server backups or snapshots. They are useful, but read the terms. Retention may be short, restores may be charged or limited, and the copies usually live on the host’s own infrastructure. If the account is suspended, closed for non-payment, or compromised, those backups may go with it. Host backups are a layer, not a plan.

The client

Some clients are perfectly capable of keeping their own backups, especially larger ones with an IT person. Most small clients are not, and will not check that backups are running. If the client owns backups, they need to know that is what they agreed to.

The agency

If you sell maintenance, backups are usually part of it, and clients assume so even when the plan is vague. Owning them means owning the schedule, the storage, the monitoring and the restore.

An outside partner

If you outsource maintenance, the partner may run the backups day to day. That does not move the client’s expectation away from you. Your client agreement is with your agency, so the partner’s duties need to sit in your agreement with the partner, and they need to match what you promised the client.

Responsibility is several jobs, not one

“Who does backups?” is too broad a question. Break it into the actual tasks, and you will often find different answers for different parts. A simple matrix makes the conversation concrete:

Fill this in for each client, or for each plan you sell. The “who owns it” column is the bit that tends to be blank.

Storage: where the copies live, and whose name is on the account

A backup stored only on the same server as the site will not help if that server or account is the thing that failed. Keep at least one copy elsewhere. The 3-2-1 approach to website backups is a sensible frame: several copies, more than one kind of storage, one copy off-site.

For agencies there is an extra question: whose account holds the off-site copies? Three common setups:

• Agency-owned storage. Easy to manage across many clients, but you must hand copies over if the client leaves, and you are holding client data, which brings its own duties.
• Client-owned storage, agency-managed. The client creates a cloud storage account and gives you access. Cleaner on exit; slightly more setup.
• Personal accounts. A developer’s own cloud drive. Avoid this. It disappears when the person does.

Whichever you choose, record it per site. Who controls hosting itself is a related decision with the same trade-offs, covered in our piece on agency-managed versus client-owned hosting.

A backup nobody has restored is a hope

The most common backup failure is not a missing backup. It is a backup that exists but cannot be restored: an incomplete archive, a database export that times out halfway, a file that only one tool can read. If you take on responsibility, you take on testing.

Practical testing does not need to be elaborate:

1. Pick a client site on a regular rotation.
2. Restore its latest backup to a staging location or a local environment.
3. Check that pages load, images appear, a logged-in admin works, and, on a store, recent orders are present.
4. Write down the date, what you restored and how long it took.

That last note is worth having for a reason beyond paperwork: when a client asks how long a restore would take, you can answer from experience instead of guessing. If a test restore fails, treat it as an incident: find out why before the day you need that copy for real.

Agreeing it in writing

The point of all this is a short, clear statement the client has seen and accepted. It does not need legal flourish. It needs to say who does what, and what is excluded. This is general information rather than legal advice; if your agreements are reviewed by a lawyer, show them this section too.

Questions the written terms should answer

• Which sites, and which parts of each site (files, database, email if hosted alongside), are backed up?
• How often, and how long are copies kept? State your actual schedule rather than a promise you cannot track.
• Where are copies stored, and who controls that storage?
• Who restores, and is a restore included or charged separately?
• What is not covered: for example, email accounts, third-party services, or sites the client edits at the code level.
• What happens to backups if the agreement ends?
• What the client must not do: delete the backup plugin, change hosting without telling you, or remove your access.

Sample wording you can adapt

As part of this plan, we take automatic backups of your website files and database on the schedule listed in your plan summary, and store copies outside your hosting account. We check that backups complete and test restoring them periodically. If your site needs to be restored, we will do this as part of the plan, unless the restore is caused by changes made outside our work, in which case we will quote the time first. Your web host’s own backups are separate from ours and are not controlled by us. If you move hosting or remove our access, please tell us first, because backups may stop. If this plan ends, we will provide the most recent backup on request.

Adjust the details to your real setup. If you outsource maintenance, copy the same structure into your agreement with the partner so their obligations cover yours. A broader view of what an agreement like this should include is in our article on the clauses a maintenance agreement needs.

Clients without a maintenance plan

The awkward case is the client who launched, declined ongoing work, and still assumes you are looking after the site. Do not leave this to chance. When the project closes, send a short handover note that says plainly:

Your site is now live and in your hands. We are no longer taking backups or applying updates. Your host may keep its own backups; please check their terms. If you would like us to keep looking after backups and updates, we can set that up at any time.

It feels blunt. It is also the message that prevents a painful call months later, and it often opens the door to the maintenance conversation you wanted to have anyway.

When a partner runs the backups

If an outside team handles maintenance for you, ask them to show, not just say, how backups work on your client sites:

• Which tool, which schedule, which storage location, and in whose account?
• How do they find out when a backup fails, and how do they tell you?
• Do they take a separate backup immediately before updates or development work?
• Have they restored one of your sites as a test, and can they show you the note?
• If you end the arrangement, how do you get the backups and the storage access back?

Answers to those questions belong in your file for each client. For the wider picture of handing maintenance and development to another team, see our guide to WordPress outsourcing for agencies.

Short checklist

• Every client site has a named owner for each backup task.
• At least one copy of each site lives outside its hosting account.
• Storage accounts are in an agency or client name, never a personal one.
• Failed backups produce an alert someone reads.
• Restores are tested on a rotation and logged.
• The client has seen, in writing, what is and is not covered.
• Clients without a plan have been told, in writing, that backups are theirs.

If you want backups, restore testing and the rest of routine upkeep handled quietly under your agency’s name, our white-label maintenance work for agency client sites is built around exactly this kind of written division of duties.

Next in this series: How to Tell a Client Their Website Is Down