Backups

Requires WHP super admin access. These features are unlocked for customers with a WHP super admin role on the server — for example, anyone running a Virtual Dedicated Server. Customers without super admin won’t see these pages.

WHP backs up customer data (sites and databases) when an admin has configured a default backup target. WHP does not back up the full server — that’s a separate concern.

Two different things called “backup”

It’s worth being precise:

Customer data backups — what WHP does. Site files (per user, per domain) and databases. Configured per server via backup targets. These start automatically once a default target exists.
Full server backups — backing up the host OS, /etc, container images, the WHP install itself, etc. WHP does not do this.

Full server backups

Where WHP runs	Who owns full-server backups
Our Virtual Dedicated Server (VDS) plans	Included. AnHonestHost snapshots the VDS at the platform level.
Anywhere else	The server operator. WHP doesn’t ship a full-server backup mechanism — you’ll need to set up something at the OS / hypervisor level.

If you’re running WHP on your own infrastructure, plan accordingly. WHP’s configuration isn’t all in /etc — there are config and state files in the WHP install directory, in Docker volumes for the platform containers (HAProxy, MySQL, Postgres, Valkey, the WAF), and in service-specific paths elsewhere on the host. The safest approach is a full-server backup (image snapshot or filesystem-level backup) rather than trying to enumerate paths.

Super admin access is granted to the root user only. Sign in directly at https://<your-server-hostname>:8443 with the root credentials.

The WHMCS client portal route doesn’t apply for super admin — it signs you in as the linked customer, not as root.

How customer auto-backups start

Customer auto-backups don’t run until at least one default backup target exists. A fresh WHP install has no targets and no schedule — every user’s backup status is “no targets available” until an admin sets one up.

Once a default target is configured, the platform begins automatic daily backups for every customer with sites or databases. Customers see their own backup history under the Backups page in their account.

The Backup Management page

Sidebar → Backups. The admin view of this page mirrors the customer view, with extra controls:

Stat tiles — Total Backups, Total Size, Sites, Databases. Server-wide totals across every account.
Create New Backup — fires an on-demand backup. Admin form adds a User dropdown so you can backup any customer’s account, not just your own.
Backup Targets — the table of destinations available on the server. The Global column distinguishes shared targets from per-account targets.

Backup targets

Each target row has:

Name — your label for the destination.
Type — S3 (and other supported types) — built-in support for S3-compatible storage (AWS S3, Cloudflare R2, MinIO, etc.).
Connection — the endpoint URL and bucket / path.
Retention — how long backups are kept (default 5 days).
Max Backups — cap on the number of snapshots retained (default 10).
Global — Yes if every account can use this target, No if it’s bound to a single account.
Actions — Test (verify credentials and write a probe object), Edit, Delete.

Adding a global backup target

Click + Add Backup Target and fill in:

Name — descriptive label.
Type — pick S3 (or whichever storage backend you want).
Endpoint URL — for non-AWS S3 (Cloudflare R2, MinIO, Wasabi, etc.), point at the provider’s endpoint.
Bucket / path.
Access key / Secret — the credentials WHP will use.
Retention / Max Backups — server-wide defaults for any account that uses this target.
Global — leave on so every account can use it as their default destination.

Click Test before saving to confirm WHP can reach the bucket. A good target round-trips a probe object in under a second.

Per-customer (non-global) targets

Customers can add their own backup targets from the customer-side Backups page. Those show up here with Global: No plus a note linking them to the owning account. Admins can edit or delete those on the customer’s behalf when they need help.

Triggering an on-demand backup for a user

In the Create New Backup form:

Pick the customer in the User dropdown.
Pick a Backup Type (Sites / Databases / both).
Pick a Backup Target.
Start Backup. Progress is visible in the run history below.

This is the right path when a customer asks for a fresh backup right before a risky migration.

Verifying customer backups are succeeding

The Total Backups and Total Size tiles climb over time on a healthy server. If they sit flat:

Confirm at least one target exists with Global: Yes.
Open the run history (lower on the page) and look for failed entries — the error message usually points at credentials or quota.

Troubleshooting

No backups are running for any customer. Confirm at least one Global: Yes target exists and that its Test button returns success. Without a global default, the scheduler doesn’t fire.

One target is failing. Click Test on the target row. The most common causes are rotated credentials, an incorrect endpoint URL (R2 / MinIO often need an explicit endpoint different from AWS’s default), or the bucket lifecycle policy deleting backups before the retention window.

Customer says their backup is too old. Check Max Backups on the target — if it’s lower than their backup cadence × retention window, older backups get pruned.

Backup ran but tar step failed mid-stream. Disk pressure on the host is a common cause. Check Disk Usage (admin sidebar) and consider raising the target’s retention so fewer backups stack up on the host before upload.

Backups — the customer-facing side.
Server settings & services — including Backup Upload host service.

Still stuck?

Still stuck? Open a support ticket and our team will help.