Acronis WordPress Backup and Restore in cPanel & WHM: Safe Recovery Checklist

Acronis WordPress recovery checklist for cPanel and WHM showing recovery scope, pre-restore checks, safe restore testing, and verification.

Acronis can give cPanel and WHM users a useful self-service recovery path when the host has enabled the service. The important decision is not simply whether a recovery point exists. It is whether that recovery point contains the right files and the right database for the problem you are solving.

Use this guide before a WordPress change, after a limited breakage, or when you are planning a recovery test. It keeps the first recovery small, makes the restore scope explicit, and avoids rolling older store or booking data over newer activity.

Choose the smallest recovery scope

What changed	Start with	Why
One image, theme file, or plugin file is missing	That file or folder	A small recovery limits the chance of replacing unrelated work.
Posts, settings, login behavior, or site data is wrong	The matching WordPress database, after a test where possible	WordPress content and settings normally live in the database.
The site needs to return to one known point in time	A coordinated files-and-database recovery	Files and database data need to represent the same site state.
An account-wide incident affects sites, mail, or panel data	A host-led account recovery decision	This larger action needs an approved rollback plan and service-owner review.

Acronis describes its cPanel and WHM integration as supporting granular recovery for accounts, files, databases, and mailboxes. The choices actually shown to you depend on the host's policy, retention, storage, and account permissions. Treat the panel as the source of truth for available recovery points.

Confirm the recovery point before you touch production

Identify the affected site by its public URL and hosting account, especially when one account contains several WordPress installs.
Record the recovery-point time and compare it with the last known good change, order, booking, form submission, or content edit.
Decide whether the problem is file-only, database-only, or a matched files-and-database issue.
Confirm there is a safe test destination, staging site, or provider-supported preview for the first restore.
Write down the owner who can approve a broader rollback before you make an account-wide decision.

This checkpoint is particularly important for WooCommerce, membership, booking, and form-heavy sites. A historical database can contain the right site settings while missing newer business records. Stop and ask the site owner how newer orders, bookings, and submissions will be handled before a database or account-wide recovery.

Check Acronis compatibility and limitations

Acronis publishes current cPanel and WHM system requirements and release notes. Ask the hosting provider or server administrator to confirm that the plugin, Acronis service, and protection agent are on a compatible supported path before treating a missing recovery option as a WordPress issue.

Acronis documents supported cPanel and WHM versions, PHP versions, and MySQL or MariaDB requirements for the integration.
Its cPanel and WHM documentation states that remote database servers are not supported for backup and recovery through this integration.
It also states that granular recovery of PostgreSQL databases is not supported through this integration.
The May 2026 1.9.3 HF2 release notes list a coordinated service and protection-agent prerequisite. A provider should handle that platform maintenance, not a customer restoring a WordPress site.

These are boundaries, not reasons to guess. When a site uses a remote database, PostgreSQL, custom storage, or an unfamiliar hosting layout, pause and request the provider's recovery plan.

Run a low-risk recovery test

Open the Acronis service made available in cPanel or WHM and select the correct account and recovery point.
Select the smallest scope that matches the issue. Do not expand the scope just to make the recovery feel more complete.
Use a staging or disposable target for the first test whenever the host supports it.
Confirm the recovery completed, then compare the intended file, page, setting, or data state with the checkpoint you recorded.
Escalate to a coordinated recovery only when the test shows that the smaller scope cannot solve the problem and the rollback owner approves it.

Verify the restored WordPress site

Sign in with an authorized test account and check the home page plus the pages that matter most to visitors.
Open media-heavy content and confirm images, downloads, and page-builder sections load as expected.
Submit a safe test through key contact, quote, or registration forms and verify the destination receives it.
For stores, review the current order and payment timing with the business owner before enabling normal checkout activity.
Check that caching and the public version of the site reflect the verified state rather than an older cached page.

When to stop and involve the host

Pause the recovery when the available point is older than the business can accept, the database is outside the integration's supported scope, the account contains several unrelated sites, or the next step would replace newer customer activity. The host can confirm retention, account ownership, storage location, and the least disruptive supported recovery path.