---
title: Backups
description: How WHP's automatic backups work, the default-target requirement, full-server backups vs customer data backups, and managing backup targets.
sidebar:
  order: 6
---

import { Aside } from '@astrojs/starlight/components';
import SuperAdmin from '~/content/partials/super-admin-callout.mdx';
import AdminSignIn from '~/content/partials/admin-signin.mdx';
import Support from '~/content/partials/support-link.mdx';

<SuperAdmin />

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.

## Sign in as super admin

<AdminSignIn />

## 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](/whp/how-to/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:

1. **Name** — descriptive label.
2. **Type** — pick S3 (or whichever storage backend you want).
3. **Endpoint URL** — for non-AWS S3 (Cloudflare R2, MinIO, Wasabi, etc.), point at the provider's endpoint.
4. **Bucket / path**.
5. **Access key / Secret** — the credentials WHP will use.
6. **Retention / Max Backups** — server-wide defaults for any account that uses this target.
7. **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.

<Aside type="tip">
  Keep one global target as the default. Customers who want their own offsite (e.g. their own S3 bucket) can add a per-account, non-global target — visible in the same table for the admin, but only usable by that one customer.
</Aside>

### 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:

1. Pick the customer in the **User** dropdown.
2. Pick a **Backup Type** (Sites / Databases / both).
3. Pick a **Backup Target**.
4. **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.

## Related

- [Backups](/whp/how-to/backups/) — the customer-facing side.
- [Server settings & services](/whp/admin/server-settings/) — including Backup Upload host service.

## Still stuck?

<Support />