shadowdao
119d376029
Build and deploy / deploy (push) Successful in 24s
Verified every page against the live admin panel on whp01 (read-only). Five existing articles rewritten; one new article added; customer-facing backups article updated to match server reality. Article changes - overview: super admin = the root user only (no UI to add another); WHMCS portal route doesn't apply for admin; accurate sidebar map of every admin-only section; customer backups don't cover server config (multiple locations, not just /etc — full-server backup is the right safety net). - server-settings: walked all six tabs (System / Services / Mail / DNS / Network & SSL / Security); clarified that host Apache + PHP-FPM serve the WHP control panel, not customer sites; that MySQL runs as a container so host MySQL config is client-facing; that custom container needs are met by publishing a custom Docker image (linked to repo.anhonesthost.net/cloud-hosting-platform/ for examples). - coraza-waf: real Firing rules / CRS catalog / Activity tabs; global WAF mode pill (off/detect/enforce); per-rule + per-host overrides; Ask AI link; security.db source-of-truth + SIGHUP reload note. - site-monitoring: split into the three actual admin pages — AI Monitor dashboard, Issues, Ignore Rules — with stat tiles + health-check timeline + ignore-rule AND-semantics. - user-management: account types corrected to full / domain_dns / mail_dns (verified in web-files/pages/user-management.php:26); system users are protected against deletion (verified is_protected_user in web-files/libs/usermgmt.php:697); delegated users are admin-editable (not read-only); suspension page is served by haproxy's 503 errorfile (verified in haproxy-manager-base/haproxy_tarpit_config.txt:31) so troubleshooting points at haproxy reload / container logs. - new admin/backups: customer-data backups vs full-server backups; auto-backups only run with a default target; how to add global vs per-customer targets; how to fire on-demand backups for any user; troubleshooting around missing targets / failed test / disk pressure. - how-to/backups (customer): aside about default-target requirement; new section explaining what full-server backups cover vs customer backups (managed plans + VDS covered by AnHonestHost; elsewhere is the server operator's responsibility). New components / tooling - admin-signin partial: 'sign in directly at :8443 as root'. - Head.astro override + medium-zoom: click-to-zoom lightbox on every article image; auto-reattaches after Starlight client navigation. - capture-admin.ts: read-only Playwright capture for admin docs with multi-pass redaction (server hostnames, mail server, customer domains, customer usernames in table cells, IPs except RFC1918 and public resolvers, password/key/token/secret/api input values, plus LiteLLM URLs, model names, JWT/sk-prefix API keys, root → admin).
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 />
|