Article Reseller Hosting

How to handle backups for client sites

Decide, and state plainly, exactly whose responsibility backups are, then test that a restore actually works before a client needs one.

iFastHosting Support Team Updated 26 August 2026 8 min read Intermediate

Backups are the part of a hosting relationship almost nobody thinks about until they need one, and by then it is entirely too late to discover the assumption you and your client were operating on were different. Deciding who is responsible for what, before that moment arrives, is one of the more consequential things a reseller can get right early.

Work out what your plan actually provides first

Before you can tell a client anything about backups, know what your own reseller plan actually includes at the platform level — what is backed up, how often, and how it can be restored. Check this at /reseller-hosting or confirm directly with our support team rather than assuming; platform-level backups vary between plans and are not a substitute for a considered backup policy of your own.

Decide, deliberately, who is responsible

There are broadly three positions a reseller can take, and the wrong one is not having decided at all:

Backups are entirely the client's responsibility. Fine as a policy, but only if the client genuinely understands and has the means to act on it — most non-technical clients do not, which makes this position a liability if it is not communicated with real clarity.
You provide backups as part of the plan. A stronger offering, and one worth pricing accordingly — see how to price hosting plans — but only credible if you have actually tested that a restore works, not just that a backup file exists somewhere.
Backups are a paid add-on. A reasonable middle ground, provided the client understands clearly what they get without it — specifically, that recovery from data loss without a backup is not something you can promise.

Whichever position you take, the failure mode is the same: a client who assumes backups are happening when they are not. Prevent that by stating your actual position plainly, not by choosing carefully worded language that avoids committing to anything.

Put this in your terms, in plain language

Backup responsibility is one of the most common sources of a genuinely damaging dispute in hosting, precisely because it usually only becomes visible after something has already been lost. What your hosting terms need to cover covers writing this clause properly — it deserves more care than a single vague sentence.

A backup nobody has restored is a theory, not a backup

The 3-2-1 backup rule — three copies, on two different kinds of storage, one of them off-site — is a solid general standard to measure any backup arrangement against, your own or a client's. But the single most overlooked step, at any scale, is testing the restore itself. A backup file existing is not the same guarantee as knowing it can actually be turned back into a working site, and the first time to discover a gap in that process should never be during an actual emergency.

Think about retention, not just whether a backup exists

A backup taken yesterday does not help a client who only notices a problem with their content three weeks after it happened. Decide, and state clearly, how far back your backups actually go — a week, a month, longer — because retention is exactly the kind of detail a client assumes generously in their own favour unless you tell them otherwise. If a client needs longer retention than your standard policy provides, that is a reasonable thing to offer as a paid option, provided you are actually able to deliver it.

Communicate the policy at the point of sale, not after a loss

Whatever your backup position is, state it clearly in your plan descriptions and again in your onboarding communication with a new client — not buried exclusively in a terms of service document a client is unlikely to read closely. A client who signed up believing backups were included, when they were in fact an unpurchased add-on, is a conversation you want to have long before anything has actually gone wrong, not during the recovery attempt itself.

Offer a real backup service if you can support it properly

If you decide to offer backups as part of your plans or as an add-on, how to back up your website and how to restore a website backup cover the mechanics you will need to be comfortable with yourself before offering it to clients. Do not offer a backup service you have not personally tested restoring from — a client relying on it deserves that it has actually been proven to work, not just configured to run.

Set a recurring reminder to test a restore

Pick a schedule — quarterly is reasonable for most small hosting businesses — and actually restore a real backup to a test location to confirm it works end to end. This is one of the few genuinely preventative habits in running a hosting business, and it is the one most likely to be skipped simply because nothing has gone wrong yet.

Backups are one of the few areas in hosting where the cost of getting it wrong is not proportional to how often it happens — a single lost site with no working backup can undo the trust built by every other part of the service you provide well. Decide the policy, communicate it clearly, and prove to yourself it actually works before a client is depending on it.