Core Panel Backup and Recovery Guide
Choose the recovery scope you need and prove that its backup can be restored. A completed upload alone does not establish recoverability.
Website and database recovery
Use website backup and database workflows for individual workloads. Include persistent application files, user uploads, database state, and required configuration. For Python, Laravel, and Node.js applications, record runtime dependencies, workers, and scheduled commands as part of the recovery plan.
Mail recovery
Encrypted mail archives cover supported mail storage and configuration. Keep the mail-backup encryption key in independent recovery escrow; the archive cannot be decrypted without it. Mail-only backups remain separate from panel-wide disaster recovery.
Restoring mail can replace current mail configuration and mailbox files. Rehearse in isolation and plan how messages received since the recovery point will be reconciled.
Panel-wide recovery
System Settings → Panel recovery configures encrypted backups to an independent S3-compatible destination. The documented bundle includes panel state, protected configuration, certificates, website files, mail storage, DNS state, and integrity metadata.
Keep PANEL_RECOVERY_KEY separately from the backup objects and database catalog. Restrict access to both the destination and the key. Review backup intervals, retention, and permissions for your intended recovery objectives.
Clean restore drills and acceptance
A newly created bundle starts unvalidated. A clean restore drill must download it, verify integrity, decrypt into an empty workspace, reject unsafe archive paths, and complete the documented isolated restore validation.
Check the newest bundle and its own successful drill result. Record recovery time and data age, then test application behavior in isolation. A passing recovery check does not satisfy the other production-readiness controls.