Choose recovery before considering removal.

Separate a website restore, panel update rollback and server decommissioning. They affect different data and require different evidence and access.

Read the guide

Preserve a recovery path first.

Keep independent server access, a usable backup and the information needed to identify the installed release and affected service. Preserve the current error and recent change before attempting a correction.

An EzePanel website/database archive is not a complete image of every server setting, mailbox and DNS record. Confirm the coverage you need and keep the recovery copy outside the system you may retire.

A website or account needs recovery.

Use the backup workflow for the selected account and inspect archive state, integrity and coverage. File restoration and database recovery are separate operations.

The customer file-restore action does not import SQL. Test the recovered application and account for writes made after the backup. Do not treat checksum success as an application recovery test.

A panel update failed.

The updater keeps a previous release reference and captures selected configuration/database recovery material. Its error path attempts to restore the affected panel state and reports incomplete recovery when it cannot finish.

This is version- and failure-dependent rollback, not a guarantee to reverse every package or host change. Preserve the update log and recovery material, then use the supported operator process for that release. No generic rollback command is published here.

A service is unhealthy.

Use fresh monitoring and health evidence to identify the service and account scope. Recovery Center exposes supported bounded actions for eligible conditions.

Recovery Center is not an uninstaller or a universal disaster-recovery engine. Shared-service changes can affect several accounts; follow eligibility and verify the actual customer outcome.

The server is being retired.

Inventory websites, databases, email, DNS, certificates, scheduled tasks, credentials and external dependencies. Move or preserve the required service and verify the destination before agreeing to removal.

A general-purpose public EzePanel uninstaller and a guaranteed removed/preserved matrix are not currently published. Removal must be reviewed against the installed release and host configuration; do not assume deleting panel files preserves the hosting service.

Agree the removal scope explicitly.

Before an operator removes anything, document the exact components to remove, the data to retain, the backup location, who can restore it and how recovery will be tested. Keep the old service available for the agreed verification window.

Contact the responsible operator or EzePanel support for release-specific guidance. Confirm the exact removal procedure and preservation plan before any destructive action.

Common questions

Understand the recovery scope.

Is there a public one-command uninstaller?

No general-purpose public uninstall procedure is provided here. Review the installed release and required preservation scope with the responsible operator.

Will uninstalling preserve every website and mailbox?

No such preservation guarantee is established. Agree the exact data and service scope and verify independent backups before removal.

Does update rollback restore the entire server?

No. The updater has bounded recovery material and failure handling. Host packages and other changes may require separate operator recovery.

Can Recovery Center replace a backup?

No. Supported service recovery and backup restoration solve different problems. Maintain usable recovery copies and verify their coverage.

Bring the right context to support.

Share the affected service, release and non-sensitive error details so the responsible team can understand the situation.

Find support