The Reseller's Backup Strategy: Be Ready Before a Client Deletes Everything

Every hosting reseller eventually gets the panicked message: a client accidentally deleted their own WordPress site, a plugin update corrupted the database, or a "cleanup" gone wrong wiped out months of content. Whether this becomes a five-minute restore or a genuine crisis depends entirely on backup strategy decisions made well before the incident, not scrambled together after.

The Baseline: Automated Daily Backups, Off the Same Server

WHM's built-in backup system can be configured for automated daily full-account backups covering files, databases, and email — but storing these backups only on the same physical server as the live accounts defeats much of their purpose: a server-level failure (hardware fault, ransomware, a catastrophic misconfiguration) takes down the live sites and their backups simultaneously. Backups should be pushed offsite — to a separate storage location, cloud storage (S3-compatible services), or a dedicated backup server entirely separate from the hosting infrastructure.

Retention: More Than One Recovery Point

A single daily backup, overwritten every night, means a problem that isn't noticed for two days (a slow database corruption, a hack that goes unnoticed initially) has already destroyed the only clean backup by the time it's discovered. A staggered retention policy — daily backups kept for a week, weekly backups kept for a month, monthly backups kept for 6-12 months — provides multiple recovery points, so a problem discovered days or weeks later still has a clean restore point available.

Per-Client Backup Visibility and Self-Service Restore

Giving clients (at least on higher-tier plans) visibility into their own backup history and a self-service restore option through cPanel's backup interface reduces both the panic and the reseller's own support burden — a client who can restore their own accidentally-deleted page from yesterday's backup without waiting for a ticket response resolves the crisis in minutes instead of hours.

Testing Restoration, Not Just Taking Backups

A backup that has never actually been tested for successful restoration is an assumption, not a guarantee — corrupted backup files, incomplete database dumps, or a misconfigured backup destination can silently fail for weeks before anyone notices, typically at the worst possible moment (during an actual emergency restore attempt). Periodically testing an actual restore, ideally to a staging or test environment, confirms the backup system is genuinely working rather than just appearing to run successfully in logs.

A Practical Reseller Backup Checklist

1. Confirm automated daily backups are configured and pushed to storage physically separate from the live server.
2. Implement a staggered retention policy (daily/weekly/monthly), not just a single overwritten daily backup.
3. Enable client-facing self-service restore where the platform supports it, to reduce both client panic and reseller support load.
4. Periodically test an actual full restoration, not just confirm backup jobs complete without error in the logs.
5. Document the specific restore process so any team member (not just whoever originally configured it) can execute it under time pressure.

Documenting the Recovery Process, Not Just the Backup System

A backup system that only one team member fully understands how to restore from is itself a risk — if that person is unavailable during an actual emergency, a technically sound backup system becomes practically useless under time pressure. Writing a short, specific restoration runbook (exact steps, exact WHM menu paths, who to contact if something doesn't work as documented) that any competent team member could follow is a low-effort safeguard against the very situation the backup strategy exists to protect against in the first place.