121 lines
6.4 KiB
Plaintext
121 lines
6.4 KiB
Plaintext
---
|
||||
|
|
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 />
|