As a reseller you sit between two backup arrangements, and neither is automatically yours. The host backs up infrastructure on their schedule for their purposes. Your clients assume you are backing up their sites. Unless you set something up, both assumptions are wrong in the direction that matters.
Decide what you are actually offering
This is a business decision before it is a technical one, and it is worth settling explicitly.
Nothing. Clients back up their own sites. Legitimate, and it must be stated plainly in writing, because the default assumption is the opposite, and the conversation you do not want is the one after a client has lost a site they believed you were protecting.
Best effort. You take periodic backups and make no guarantee about retention or restore time.
A defined service. Stated frequency, stated retention, stated restore expectation. This is what most clients think they are getting, so if you are charging for hosting rather than for a commodity, it is usually the right answer.
Whichever you choose, write it in the welcome email. Ambiguity here resolves against you.
What you can take from WHM
A full cPanel backup of an account covers everything: files, databases, email accounts with their messages, forwarders, cron jobs, DNS zone and settings.
That completeness is why it is the right archive to take before anything risky: a migration, a PHP change, a major update, and the right thing to hand a client who is leaving.
It is the wrong tool for routine protection, because it depends on you remembering. A scheme requiring a human to do something monthly lapses within a quarter.
Automate it or it will not happen
If you are offering backups as a service, automate them and push the archives off the server.
A backup stored on the same account protects against a client deleting a file. It protects against nothing else; a compromised account can reach its own archives, and it consumes the disk allocation you are also selling.
Then make failure noisy. A backup job failing silently for six weeks is indistinguishable from having none, and that is the most common way people discover they have none.
Retention, and why three days is not enough
Daily for a week or two, weekly for a couple of months, one monthly kept longer.
Compromises and slow corruption are usually discovered long after they start. A three-day rotation on a site infected two weeks ago contains three infected copies and nothing useful.
Test a restore before a client needs one
Restore one account to a spare account and check it properly: does the site load, is recent content present, does email exist.
You are looking for specific failures that are invisible until tested. An archive missing the mail directory, a database dump truncated by a timeout, a backup of an account that was already broken.
Half an hour now. The alternative is finding out during a client's emergency, with them watching.
Know how long a restore takes
This is the number that turns backups into a service you can describe.
If a client asks how quickly you can restore their site and the honest answer is "I have never tried", you do not have a backup service: you have archives. Time one restore, on a real account, and quote that.
Do not let clients rely on host-level backups
Host backups exist for infrastructure recovery. Their retention is chosen around that purpose, not around a client who deleted a page last Tuesday.
Ask what is actually available if you want to know, and do not build a promise on it. Anything you tell a client about recovery should be something you control.
Before terminating anything
Take a backup and keep it for a few months, even when the client is leaving on bad terms.
The request for a copy arrives more often than you would expect, and with an archive the answer is yes. Termination deletes everything permanently. Terminating client accounts goes into the checklist.
Retention is what decides whether an account you removed can still be recovered months later. How to Suspend, Unsuspend and Terminate Accounts in WHM walks through the sequence that keeps that option open.
Confirm the backups are still happening
Backup arrangements fail silently, and the failure is discovered when one is needed. A weekly glance at two figures prevents that entirely.
ls -lt /home/*/backups/ 2>/dev/null | head
ls -l --time-style=+%F /backup/*/accounts/*.tar.gz 2>/dev/null | awk '{print $6, $5/1048576"MB", $7}' | tail
Two things to read: the date of the newest file, and the size against the previous one. An age older than the schedule means it stopped; a size that has dropped sharply means it is running and capturing less than it did.
The size drop is the one worth reacting to, because the file exists and the schedule looks healthy. It usually means an exclusion was added, a database was skipped after a failed connection, or the run was cut short on disk, and it produces a backup that restores cleanly and is missing things.
Keep a copy the server cannot reach
A backup stored on the machine it protects covers deletion and mistakes. It does not cover the machine, and it does not cover an intruder with access to it.
The arrangement that helps is a copy somewhere the server cannot write to or delete from, which in practice means the remote system pulls the files instead of the server pushing them.
rsync -az --delete -e 'ssh -p 22' user@server:/backup/ /local/store/
Run from the storage side, with a key restricted to reading, that inverts the trust: compromising the server does not give access to the archive. Credentials stored on the server for pushing to remote storage are available to anyone who reaches the server. For the mechanics, see using rsync for transfers and backups.
What the account backup does not contain
A full cPanel backup is comprehensive about the account and silent about everything around it, and the gaps only appear during a rebuild.
DNS held at a registrar or an external provider. The zone in the backup is the server's copy; if the authoritative records live elsewhere, they are not in it.
Mail hosted somewhere else. An account whose MX points at an external provider backs up an empty mail directory.
Anything outside the account. Certificates issued to the hostname, firewall rules, and any customisation made as root.
Write these down per client instead of assuming the archive is the whole picture. The recovery you are promising is only as complete as the least documented of them. Secondary DNS and what happens when DNS fails deals with the first.
Ask three questions before restoring anything
Most damage done during a restore comes from starting it before understanding the request.
When did it last work? That chooses the backup. A client saying "yesterday" frequently means "the last time I looked", which can be a fortnight.
What exactly is wrong? One file, one page, the database, or everything, because the answer decides whether this is a partial restore or a full one, and a full restore for a single-file problem discards every legitimate change since.
Has anything happened since? Orders, form submissions, new posts, uploaded files. Whatever exists after the backup date is what a full restore removes, and the client should agree to that in writing before rather than discover it afterwards. Backing up and restoring in cPanel goes into the restore itself.