Skip to content

Backups

BHPanel has two kinds of backup, and they never overlap:

Server backups A customer's own backups
Made by the administrator's jobs, or Back up now the customer (or its reseller), when the plan allows it
Kept /var/backups/bhpanel, and/or remote destinations in the account, ~/.bhpanel-backups
Counted in the customer's disk no yes
Plan switch (Accounts › Packages) Server backups, on Customers' own backups, on

Server backups leave a customer's own backups out, so nothing is stored twice.

Server backups

Everything is on Files › Backups, in two tabs: Archives and Jobs & destinations.

Switch them on

The Server backups card has one switch. Off means no job runs and Back up now is refused; your destinations, jobs and archives are all kept. It can only be switched on once there is at least one destination.

When nothing has been set up, a built-in Nightly job runs every night at 02:30, to the server's own disk, keeping 7. It is an ordinary job you can edit.

Jobs

New job asks for:

  • How often: every day (on the weekdays you tick), every week (one day) or every month (dates 1–28, so it runs in every month), at a time of your choice. Times are the server's own time zone, shown on the page.
  • What to back up: files, MariaDB, PostgreSQL and MongoDB databases, mail, site settings, DNS zones, SSL certificates, cron jobs, FTP users, account settings and container apps. All are ticked to start with.
  • Destinations: the server's disk and any remote destination, each with its own number of copies and days to keep.
  • Keep the newest (default 7) and delete older than (days, default off). 0 turns either off, and at least one copy is always kept.
  • Only these accounts (empty is every account), and Paused.

Jobs run at the lowest CPU and disk priority, so websites are not slowed by them. Run now starts a job straight away.

Format: gzip (works everywhere), zstd (faster and smaller), none (for sites that are mostly photos and video), or incremental for remote destinations: one encrypted repository per account, which stores only what changed. Its key is shown once, when you save: keep it somewhere safe.

What is never in an archive: DNSSEC keys, the keys of bought certificates and FTP passwords stay on the server; Let's Encrypt certificates are issued again rather than restored; account settings never include the account's password or contact email.

Destinations

Jobs & destinations › Destinations adds Local, SFTP, FTP, S3 or Google Drive. Test and save writes a small file there and removes it again; the destination is only saved if that works. A destination that later fails its test is kept, marked not working, and used again once a test passes. Each server gets its own folder there, and each account its own folder under that.

Destination What it needs
SFTP (recommended) host, port, user, and a password or a private key. The server's host key is recorded the first time and checked every time after.
FTP over TLS host, port, user, password. The server's certificate must name the host you enter — a real or a self-signed certificate both work.
S3 bucket, access key and secret key (and an endpoint for anything other than Amazon: Wasabi, Backblaze B2, Cloudflare R2, MinIO). The key needs list, read, write and delete on the bucket.
Google Drive a token from rclone authorize "drive" run on your own computer, with your own OAuth client ID and secret (strongly advised, to avoid Google's shared quota).

After a rebuild of the other server: tick Trust its new host key (SFTP) or The server's certificate changed (FTP) and save again. The guide at the bottom of the page walks through each type, including FileZilla Server.

Back up one account now

Archives › Back up now: pick the account and how many to keep. The archive is read back before it is kept.

Restoring

Every archive has two buttons.

Restore puts back the parts you tick — website files, databases, mailboxes, DNS records, certificates, cron jobs, site settings, account settings, FTP users. Nothing is ticked to start with: choose only what you need, so recovering one database does not also replace a website that is working. Type the account's name to confirm.

Restore a part brings back one thing:

  • Files — all of them or one folder, in place (files of the same name are replaced, files added since are left alone) or into a new folder (~/restored-<date>, nothing replaced). It runs inside the account's own limits. Logs are not restored.
  • One database — its contents are replaced. It must exist; create it again first if it was deleted.
  • Email — a whole domain or one mailbox. Messages come back; passwords and filters are left as they are.
  • DNS records, certificates, cron jobs, FTP users, site settings, account settings, and a container app's data.

From a remote destination: Show its backups reads the destination itself, so it works on a newly built server too. Bring back copies an archive here; it is then restored like any other.

An account that no longer exists: create it again (or import it), then restore. An archive of an earlier account with the same name asks you to confirm that this is what you mean.

A customer's own backups

On the customer's Files › Backups: Make a backup now, a schedule (only when asked, every day or every week), how many to keep (default 3), and Download, Restore and Copy to remote. These backups live in the account and count in its disk; one always leaves 5% of the disk limit free. Customers can copy every backup to their own SFTP, FTP, S3 or Google Drive too.

The same page lets a customer download and restore from the server's backups, when the plan includes them.

Resellers: their customers to their own storage

A reseller plan can tick Reseller backs up customers to its own remote (off on every plan). The reseller then sets a schedule on its own Files › Backups, ticks the accounts to include, and every backup goes to its own remote, one folder per account. Nothing is kept on the server. Times inside the server's own backup window are refused, so they never compete for the disk. Bring back copies an archive into that customer's backups to restore it.

Good practice

  • Keep at least one remote destination. A backup on the same disk does not survive the disk.
  • Test a restore now and then — Restore a part › Files › Into a new folder is safe to try on a live account.
  • With incremental backups, store the key away from the server.