Placeholders are 1440x900 'Screenshot pending' PNGs that will be overwritten by real captures via 'npm run screenshots' once a demo user is provisioned.
91 lines
3.2 KiB
Plaintext
91 lines
3.2 KiB
Plaintext
---
|
|
title: Backups
|
|
description: Confirm WHP is backing up your site, restore individual files, and download archives.
|
|
sidebar:
|
|
order: 4
|
|
---
|
|
|
|
import { Steps, Aside } from '@astrojs/starlight/components';
|
|
import SignIn from '~/content/partials/signing-in.mdx';
|
|
import Support from '~/content/partials/support-link.mdx';
|
|
|
|
WHP runs **automatic daily backups** of your site files and databases. You don't have to set anything up for this to happen — but it's worth knowing how to confirm a backup ran, restore something, and download an archive when you need to.
|
|
|
|
## What's backed up by default
|
|
|
|
- **Site files** — everything under each domain folder.
|
|
- **Databases** — all MySQL databases attached to your account.
|
|
- **Email** — mailboxes and their contents (depending on your plan).
|
|
|
|
Retention is shown on your plan page. The default tier keeps **7 daily backups**.
|
|
|
|
## Sign in to WHP
|
|
|
|
<SignIn />
|
|
|
|
## Configure your backup schedule
|
|
|
|
<Steps>
|
|
|
|
1. From the sidebar, open **Backups → Settings**.
|
|

|
|
|
|
2. Confirm the **schedule** (default: daily, overnight). Adjust if your plan permits.
|
|
|
|
3. (Optional) Enable **off-server backups** to a separate storage location — recommended for anything you can't afford to lose.
|
|
|
|
</Steps>
|
|
|
|
## Verify a backup actually ran
|
|
|
|
<Steps>
|
|
|
|
1. Open **Backups → History**.
|
|

|
|
|
|
2. Confirm the most recent entry is from **within the last 24 hours** and shows **Success**.
|
|
|
|
3. Click the entry to see what was included — files, databases, email — and the total size.
|
|
|
|
</Steps>
|
|
|
|
<Aside type="tip">
|
|
Add a calendar reminder to check this monthly. Backups that fail silently are the worst kind.
|
|
</Aside>
|
|
|
|
## Test a restore (recommended quarterly)
|
|
|
|
The best time to discover your backup isn't working is *not* when you actually need it. Test surgically:
|
|
|
|
1. In **History**, click a recent backup → **Restore preview**.
|
|
2. Pick a single file — your site's `index.php`, for example — and restore just that one file.
|
|
3. Confirm it appears correctly. If yes, the restore pipeline works.
|
|
|
|
Don't do a full restore unless you genuinely need to — it rewrites your live site.
|
|
|
|
## Download a backup
|
|
|
|
To grab a copy off-server:
|
|
|
|
1. From **History**, click a backup → **Download**.
|
|
2. WHP packages it as `.tar.gz` and offers a one-time download link that's valid for 24 hours.
|
|
|
|
## Troubleshooting
|
|
|
|
**Backup failed.** Click the failed row to see the error. Common causes:
|
|
|
|
- Disk full or close to it — check **Overview → Resource usage** and consider a [resource upgrade](/whp/add-ons/resource-upgrades/).
|
|
- A very large mailbox slowed the run — consider the [archival email add-on](/whp/add-ons/archival-email/) to relieve mailbox pressure.
|
|
- Transient lock or maintenance window — let it retry overnight before opening a ticket.
|
|
|
|
**Restore "succeeded" but my file isn't there.** Check the **path** shown on the backup's detail page — your restore landed where the backup says it would, which may not match your current site layout if you've moved files around.
|
|
|
|
## Related
|
|
|
|
- [Archival email add-on](/whp/add-ons/archival-email/)
|
|
- [Resource upgrades](/whp/add-ons/resource-upgrades/)
|
|
|
|
## Still stuck?
|
|
|
|
<Support />
|