Account Backups

A CorePanel backup captures a whole account: its home directory, its databases, its domains and subdomains, its FTP accounts and its mailboxes, plus the account’s own identity and limits. The result is a single .tar archive that can rebuild the account from scratch.

It is, deliberately, the inverse of the cPanel importer: the same idea of a self-describing archive, in the other direction.

What is inside an archive

Resource	Captured
Home directory	Every file the account owns, with ownership and permissions
MySQL	Each database, dumped, plus its users and their grants
Domains	Primary, aliases and addon domains, with their serving modes and settings
Subdomains	With their document roots
Mailboxes	Accounts and their mail
FTP accounts
The account itself	uid/gid, home path, PHP version, package reference and every limit

A manifest.json at the root of the archive indexes all of it, so an archive can be inspected — and a restore planned — without unpacking it first.

Taking a backup

Backups → Create backup, pick the account, and the job starts in the background. The job list shows progress and, when it finishes, a per-resource report of what was captured and what was not.

From the CLI:

corepanel account backup <username>

Archives are written to /var/lib/corepanel/backups on the server.

The job is asynchronous

Starting a backup returns immediately with a job you can poll. A large account takes a while — the home directory tarball and the database dumps are the slow parts — and the job survives you closing the panel.

Scheduled backups

The Schedules tab defines recurring backups.

Field	Notes
Name	How the schedule appears in the list
Scope	A single account, or all accounts on the server
Frequency	daily (02:00), weekly (Sundays 02:00), monthly (1st, 02:00), or a custom five-field cron expression
Retention — keep	Maximum number of archives to keep. 0 = no limit
Retention — days	Delete archives older than N days. 0 = no limit
Enabled	A disabled schedule stays defined but does not fire

A server-wide schedule runs a bounded number of accounts at a time rather than starting one job per account at once — a full backup is a heavy mysqldump plus a large tarball, and firing hundreds in parallel would take the server down.

Run now executes a schedule immediately, which is the right way to verify one before trusting it.

Restoring

Restore takes an archive and rebuilds the account: system user (with its original uid/gid and home path), files, databases and users, domains, subdomains, mailboxes and FTP accounts.

Two options shape the run:

Option	Effect
Dry run	Reports everything the restore would do, and every conflict it would hit, without writing anything
On conflict	abort (default) stops at the first collision; skip restores everything that does not collide and reports the rest

Always dry-run a restore onto a server that already hosts things. A domain name is unique across the whole server, so an existing domain is the most common collision.

Passwords after a restore

The account’s password — for the panel and for FTP — is preserved when the archive carries a recoverable hash, so the customer’s credentials keep working. When it does not, the account is restored with a random password and the report says a reset is required.

MySQL users are recreated with their original credentials where the hash can be recovered. A user whose password cannot be recovered is skipped and reported rather than recreated with a random password — recreating it would silently break the application that connects with it.

Partial restores

A failure in one resource does not abort the whole run: it downgrades the job to partial and is recorded in the report. You get an account that mostly came back plus an explicit list of what did not, instead of an all-or-nothing failure.

Restoring a deleted account

Backup archives are not deleted when an account is deleted. That is the point of a backup: it must outlive what it describes. Restoring a deleted account is the ordinary restore flow, with no collisions to worry about.

Moving an account to another server

Copy the archive to the target server and restore it there. The account’s uid/gid, home path and limits come from the archive, and its hosting package is re-mapped by name if the ID differs on the target.

Plan DNS separately: the restore rebuilds the zones on the new server, but the domain keeps resolving to the old one until the delegation or the records change.

Where archives live

Backups are written to local storage on the server itself, unencrypted. Two consequences worth planning around:

• Copy them off the server. A backup on the same disk as the account does not survive the failure it is there to protect against. rsync or rclone from a cron job is the usual answer.
• Treat the backup directory as sensitive. An archive contains the account’s files, its databases and its mail.

Backups vs restore points

	Account backup	WordPress restore point
Scope	The whole account	One WordPress instance
Contents	Files, databases, domains, mail, FTP	That instance’s document root and database
History	Governed by retention	Three per instance
Survives account deletion	Yes	No
Purpose	Disaster recovery, migration	An undo button for an update

Use restore points around risky updates. Use backups for everything else.