Backups and migration

#Backup types

Backups live under Server Admin → Backups, which has these tabs: Snapshots, Repositories, Schedule & retention (these three are Pro), Full backups, Full backup settings and Transfers & import.

#Full account backups

A full backup is a .tar.gz archive containing the account's panel records (domains, databases and their users, email, cron, DNS), MySQL dumps, PostgreSQL databases and the home directory. The backups/, tmp/ and .trash/ folders in the home directory are left out. There are three kinds: Full backup, Files only and Databases only.

#User panel

Account owners create, download, delete and restore their own backups from User panel → Files → Backups. Backups they take are stored in their home directory under ~/backups. When restoring, files and databases can be selected separately. A bipanel backup (.tar.gz) uploaded from another server can also be picked from the home directory and restored. Only one backup job runs per account at a time.

#Scheduled server backups

Scheduled backups are turned on in the Full backup settings tab. Defaults:

On a native install, server backups are written to /var/lib/bipanel/backups/<account>/; in a Docker or Railway container they go to /data/backups/ on the persistent volume. When an account is terminated its server backups are kept, so the account can be rebuilt from the Full backups list with "Recreate account". The user's own backups go away together with the home directory.

The same operations are available from the command line:

$ bipanel backup list
$ bipanel backup create --all --kind databases
$ bipanel backup restore 42 --mode recreate --package Basic

#Incremental backups (Pro)

In the Pro edition the backup engine is restic: data is deduplicated and encrypted, and each run only sends what has changed. On a native install, add the "restic (incremental backups)" component from Server Admin → Components. It is not installed by default; the official release is verified against its SHA-256 checksum, and rclone is installed alongside it. The Docker image ships with restic and rclone; in a container, backups are written under /data/backups/ on the persistent volume (see Docker and Railway).

#Repositories and the server key

In the Repositories tab you open a restic repository on a backup destination. Every repository this server creates is protected by a random server key, stored encrypted in the panel. If the server is lost completely, the repositories can only be opened with that key. It can be exported only once, after re-authentication, and the panel never shows it again, so keep it somewhere safe. A repository from another server can be adopted with its address and that server's key, which lets you rebuild accounts on a new server from the old server's backups. Integrity checks, prune and unlock are available for maintenance.

#Schedule and retention

You can also set exclude patterns (*.log, node_modules, public_html/cache), a maximum file size, a bandwidth limit, extra copy repositories, and pre/post hooks that only the server administrator can enter. Settings can be overridden per account, and a retention rule can be previewed before it is applied.

#Restoring

The Snapshots tab lets you browse restore points. You can restore a file or folder to its original place or to another folder in the home directory, a single MySQL or PostgreSQL database, a single mailbox or the whole account, and you can recreate a terminated account. Files are written as the account user.

If the administrator allows it, account owners see and restore their own points under User panel → Backups → Incremental backups. This can be switched off per account with the "Restore from incremental backups" package feature. Users only reach their own snapshots, and only in repositories the administrator has made visible.

If the license expires, scheduled incremental backups, browsing and restores keep working; creating new repositories and policies requires a valid Pro license.

#Backup destinations

Destinations defined under Server Admin → Backups → Backup Destinations are used both for copying full backups and for restic repositories. Remote destinations run through rclone.

Connection tests, quotas and bandwidth limits are set per destination. With "copy new backups" on, successful backups taken after the option was enabled are copied every 5 minutes; a failed copy is retried up to 3 times, 30 minutes apart. When the number of copies kept per folder (default 7) is exceeded, only files the panel put there are deleted. Any backup on a destination can be downloaded back to the server.

Setting up remote destinations other than the server disk requires the "Remote backups" feature in your license; the Community edition does not include it (see Pricing). In the Pro edition, account owners can add their own remote destinations under User panel → Files → Backup Destinations; the administrator can turn this off per package or entirely.

On Docker and Railway, backups under /data sit on the same volume as the panel. Use at least one remote destination to protect against losing the volume.

#Moving accounts

#From another bipanel server

On the source server, create a transfer token under Server Admin → Accounts → Transfer Source (both editions). The token only opens the transfer endpoints and grants no panel session. You can add an IP/CIDR restriction and an expiry date; prepared archives are deleted after 24 hours. On the destination server, open Accounts → Transfer Tool (Pro), choose "bipanel server" and enter the address and token. Accounts keep their passwords.

#From another control panel

The Transfer Tool connects over SSH to servers running supported other control panels. No connection is made until you confirm the host key fingerprint, and passwords or private keys never appear on the command line. On a native install the required tools come with the "Transfer tools" component.

Each account goes through packaging on the source, download (resumable and SHA-256 verified), import and verification. A session processes 1 to 4 accounts in parallel. If an account with the same name already exists here, enable overwrite or map it to another name. With overwrite, a safety backup of the existing account is taken first and restored if the import fails. Post-migration checks compare the site as well as database, mailbox and domain counts, without changing the account. The DNS helper lowers TTLs before the move, then points A records that still target the old IP at this server.

#Importing from an archive

If the source server cannot be reached, upload an archive instead:

• Backups → Transfers & import tab: bipanel backups and full account archives from supported other panels (.tar.gz; the format is detected from the file name). The home directory, MySQL databases (with their passwords) and addon, sub and parked domains are imported. Copy large archives over SFTP to /var/lib/bipanel/backups/_uploads (/data/backups/_uploads in a container).
• Accounts → Import from Another Panel: XML-dump subscription backups and single-piece or split user backups. A dry-run report comes first, and a failed import is rolled back. The Community edition imports one account from one archive; Pro adds multi-account and bulk imports.

In the Community edition, imported accounts count towards the 3 hosting account limit. To move an account to another disk on the same server, see Disk manager. For moving accounts between cluster members, see Cluster and cloud.