Backups in a hosting panel are not one universal feature: check whether the installed panel release exposes a backup module, then define independent copies of files, databases, configuration, and secrets and prove them with a restore test.
Do not assume a common backup button
The four panels focus on web engines, mail, DNS, containers, and migration, but they do not establish a shared backup job, retention model, or restore workflow. A panel may offer a backup component, an export view, or no integrated scheduler at all. Names, destinations, and retention semantics depend on the panel, the release, and optional modules. Treat any screenshot or tutorial as a version-specific hint, not as a guarantee.
Define what must be recoverable
Inventory the application files, databases, uploaded media, virtual-host configuration, DNS records, mailboxes, certificates, and key material that would be needed after a failure. A file copy alone may not reproduce a database-backed site. Conversely, a database dump without uploads or configuration can leave an application unusable. Write down ownership, permissions, runtime versions, and secrets handling so a restore has a known target state.
Choose an independent destination
Prefer a destination that is operationally separate from the panel host. Review the tool’s encryption, authentication, integrity checks, and failure reporting. If the panel exports a local archive, decide how it will be copied away from the server and how its keys will be protected. Avoid calling a single local snapshot a complete strategy; a disk failure or a compromised account can affect both the live data and the snapshot.
Make retention an explicit policy
Retention is the rule for which recovery points remain available and when older copies are removed. Base it on the data’s change rate, legal or contractual needs, storage budget, and the longest period in which an unnoticed error could be discovered. State whether the policy keeps daily, weekly, or event-based copies without assuming that a panel’s labels implement those meanings. Review deletion safeguards and verify that a failed job does not silently replace the last good copy.
Test a restore, not just a job
Run a restore into an isolated location and check application behavior, database consistency, file permissions, certificate handling, and mail or DNS dependencies. Record the result and fix gaps before relying on the copy. Repeat the test after changing the panel, backup tool, destination, or application structure. No panel-wide backup schedule or recovery time should be assumed; keep those commitments inside your own documented operations policy.
Ask precise panel questions
When a release-specific option is unclear, use the support ticket route with the panel release, desired scope, destination type, and restore objective. For general sizing, review the available plans without treating a plan name as a backup guarantee.