Back to tutorials
Tutorial

cPanel Account Restore Tutorial (2026): WHM Restore, DNS Safety Checks, and Fixing Broken Permissions After a Backup

cPanel account restore tutorial for WHM: safe restores, DNS checks, and permission fixes to bring sites back cleanly in 2026.

By Anurag Singh
Updated on Jul 02, 2026
Category: Tutorial
Share article
cPanel Account Restore Tutorial (2026): WHM Restore, DNS Safety Checks, and Fixing Broken Permissions After a Backup

A backup only matters if you can restore it without surprises. This cPanel account restore tutorial shows a practical WHM restore workflow. You’ll pick the right backup file, restore without unintended DNS changes, validate web and mail, and fix common post-restore problems (ownership, PHP handlers, SSL, and mail routing).

The steps below assume you administer a cPanel/WHM server on a VPS or dedicated machine. Predictable restore times require enough CPU and disk I/O to extract archives and rebuild accounts. Start with a properly sized HostMyCode VPS, or go managed if you want to offload patching and backups.

What you need before you restore (and why it matters)

Most restores fail for boring reasons. The usual causes are the wrong archive, low disk space, an overloaded server, or an unplanned DNS change.

Run this quick preflight before you touch WHM.

  • Root WHM access to the destination server (a reseller with restore privileges is uncommon).
  • Backup artifact: usually a cpmove-USERNAME.tar.gz file, or a full account archive created by WHM backups.
  • Free disk space: plan for at least 2–3× the account’s used size for extraction and temporary files.
  • Maintenance window: 5–30 minutes per account is normal, especially with lots of mail.
  • DNS plan: decide whether this server will be authoritative for the domain, or if you’re only restoring content.

Check disk, load, and backup integrity

On the destination server, confirm capacity first. Also confirm you are not already I/O bound.

df -h
free -h
uptime
iostat -xz 1 3

Next, verify the archive isn’t truncated or corrupt:

ls -lh /home/backup/cpmove-USERNAME.tar.gz
gzip -t /home/backup/cpmove-USERNAME.tar.gz && echo OK

If the backup is on another server, copy it over SSH. This is usually faster and less error-prone than FTP:

rsync -avP root@OLD_SERVER:/home/backup/cpmove-USERNAME.tar.gz /home/backup/

If you restore more than once in a blue moon, keep a written runbook. HostMyCode’s checklist in this disaster recovery runbook tutorial is a good starting point.

cPanel account restore tutorial: restore an account in WHM (two reliable methods)

WHM gives you two dependable restore paths. The right choice depends on what you have available.

Use Method A for a single cpmove archive. Use Method B when the server can access WHM’s configured backup destination.

Method A: Restore from a cpmove archive (most common)

  1. Log in to WHM as root.
  2. Go to Home → Backup → Restore a Full Backup/cpmove File.
  3. Set Backup Directory to the folder that contains cpmove-USERNAME.tar.gz (for example, /home/backup).
  4. Select the archive and click Restore.

Watch the restore progress as it runs:

tail -f /usr/local/cpanel/logs/error_log

For account-level detail, review the dedicated restore logs:

ls -lt /var/cpanel/logs | head
# then open the latest restore log with:
less /var/cpanel/logs/restore-*.log

Method B: Restore from WHM’s backup system (if available)

If your destination server can see the configured backup destination (local storage, mounted remote storage, etc.), restore directly from the WHM backup interface:

  1. Home → Backup → Backup Restoration
  2. Select the date and account.
  3. Restore Account (and optionally Mail, depending on what you’re trying to recover).

This path is clean and convenient. It only works if the backup destination is accessible from the server you’re restoring to.

Critical choice: should the restore overwrite DNS zones?

DNS is where a “quick restore” turns into an accidental cutover. If the domain points somewhere else, restoring zones can flip traffic. It can also disrupt mail delivery.

  • Restoring to the active production server: restoring DNS zones is often fine.
  • Restoring to a staging or recovery server: avoid changing live DNS during the restore. Restore content first, then update DNS intentionally.

If a planned DNS switch is part of your recovery, use HostMyCode’s DNS cutover tutorial as a checklist for TTL reduction, record verification, and rollback.

Post-restore verification: web, DNS, SSL, and mail (the 20-minute checklist)

A “restore complete” message only means the archive extracted and the scripts finished. It does not confirm the site and mail are working.

Spend a focused 20 minutes verifying the parts that commonly break.

1) Confirm the account exists and is sane

whmapi1 listaccts search=USERNAME searchtype=user | head
id USERNAME

Check the home directory. Then spot-check web-root permissions:

ls -ld /home/USERNAME
ls -la /home/USERNAME/public_html | head

2) Test the site without touching public DNS (hosts-file approach)

On your workstation, temporarily map the domain to the new server IP. This lets you test privately without changing DNS for everyone else.

macOS/Linux:

sudo sh -c 'echo "NEW_SERVER_IP example.com www.example.com" >> /etc/hosts'

Windows (run Notepad as Administrator): edit:

C:\Windows\System32\drivers\etc\hosts

Load the site and test the admin area as well. For WordPress, check /wp-admin.

If you’re restoring WordPress and plan a structured low-downtime move later, this WordPress migration tutorial lays out a repeatable process.

3) Check DNS zone content (and common restore surprises)

On the server, locate the zone file. Then validate it:

ls -1 /var/named | grep -i example.com
named-checkzone example.com /var/named/example.com.db
  • A/AAAA records: confirm web traffic will land where you expect.
  • MX records: confirm you didn’t redirect mail delivery by accident.
  • SPF/DKIM/DMARC TXT records: check for missing records, duplicates, or old values.

If mail deliverability matters, keep authentication records consistent. HostMyCode’s email authentication tutorial is a solid reference for SPF/DKIM/DMARC and reverse DNS alignment.

4) SSL status: verify AutoSSL and force a recheck when needed

After restores, SSL failures usually come down to one of these issues:

  • DNS still points at the old server, so AutoSSL can’t validate.
  • The domain changed IPs and the certificate install didn’t follow.
  • Redirects send ACME validation to the wrong host.

In WHM, go to Home → SSL/TLS → Manage AutoSSL and run AutoSSL for the account.

If issuance fails, troubleshoot with HostMyCode’s SSL renewal troubleshooting tutorial.

5) Mail sanity checks (don’t ignore the queue)

If the account handles mail, check Exim health and queue size right away:

exim -bpc
exim -bp | head

If you need to dig into queue behavior, follow this cPanel email troubleshooting tutorial instead of making trial-and-error changes.

Fix the most common post-restore failures (with commands)

Most “restored but broken” accounts fail in predictable ways. Work through the fixes below in order.

This sequence resolves the majority of outages.

Issue 1: Wrong ownership or file permissions (403, 500, or WP can’t update)

Common symptoms include 403 Forbidden, failed uploads, plugin/theme install failures, or PHP errors that mention “Permission denied”.

Start by checking current ownership and directory modes:

# Replace USERNAME
stat /home/USERNAME/public_html
ls -ld /home/USERNAME /home/USERNAME/public_html

If ownership is wrong, correct it:

chown -R USERNAME:USERNAME /home/USERNAME/public_html

Then apply sane permissions. Avoid 777:

find /home/USERNAME/public_html -type d -exec chmod 755 {} \;
find /home/USERNAME/public_html -type f -exec chmod 644 {} \;

On suPHP or PHP-FPM setups, permissive permissions can break execution. After fixing ownership and modes, restart services as needed:

/usr/local/cpanel/scripts/restartsrv_httpd
/usr/local/cpanel/scripts/restartsrv_php-fpm

Issue 2: PHP version/handler mismatch after restore

If the destination server uses a different EasyApache 4 profile, a restore can change PHP versions, handlers, or available extensions. This often shows up as blank pages, fatal errors, or missing module messages.

In WHM, verify these areas:

  • Home → Software → MultiPHP Manager (per-domain PHP version)
  • Home → Software → MultiPHP INI Editor (per-domain settings)
  • Home → Software → EasyApache 4 (modules and PHP packages installed)

From the shell, confirm what Apache and PHP are actually running:

/usr/local/apache/bin/httpd -M | head
php -v

If WordPress admin loads but the front-end dies, check the site’s PHP error log. The log location varies by configuration.

Enabling logging briefly in wp-config.php and tailing the log is often the fastest path. Disable it again when you’re done.

Issue 3: Database connection errors after restore (without turning this into a DB article)

You don’t need to tune MySQL to finish a restore. The application does need to authenticate and connect.

  • Confirm the DB user exists in cPanel and is assigned to the DB.
  • Verify credentials in wp-config.php (WordPress) or your application config.

Quick login test as the cPanel user:

u=cpuser
mysql -u"$u" -p -e "SHOW DATABASES;"

If you get “Access denied”, reassign privileges in cPanel or WHM. If you see socket or connection errors, confirm the service is up:

/usr/local/cpanel/scripts/restartsrv_mysql
systemctl status mysql --no-pager

Issue 4: Restored site points to the old server (hardcoded URLs)

If you restored onto a new hostname or IP and the app redirects to the old URL, this is usually application configuration. WordPress commonly stores URLs in the database.

First, confirm DNS (or your hosts override) matches the domain you want to serve. Then retest.

If you must update WordPress URLs, WP-CLI is safer than hand-editing SQL:

cd /home/USERNAME/public_html
wp option get home --allow-root
wp option get siteurl --allow-root
wp search-replace 'https://old.example.com' 'https://example.com' --skip-columns=guid --allow-root

Issue 5: Exim/IMAP works, but mail deliverability collapses after restore

This often happens when the restored server sends from an IP without correct reverse DNS. It can also happen when SPF/DKIM/DMARC no longer matches the new sending path.

  • Check the sending IP and HELO name alignment.
  • Confirm rDNS (PTR) points to a hostname that resolves back to the same IP.

Use these HostMyCode guides to fix the pieces quickly:

Restore safely during an incident: minimize downtime and avoid data split

If you’re restoring because the old server is unstable or compromised, the main risk is “split brain”. Some users hit the old site while others hit the restored copy.

That’s how you lose form submissions, orders, or email.

Practical low-risk sequence

  1. Lower DNS TTL ahead of time if you can (300 seconds is a common target).
  2. Freeze writes on the old server: enable maintenance mode and pause inbound forms where possible.
  3. Take a final backup or last-minute archive.
  4. Restore the account to the new server.
  5. Verify via hosts-file mapping before touching DNS.
  6. Cut DNS and monitor access logs + mail flow.

If you suspect compromise, treat this as incident response, not a normal migration. HostMyCode’s VPS incident response tutorial lays out the right order of operations (containment first, recovery second).

Quick diagnostics: where to look when a restore “succeeds” but the site is down

Bookmark this section. It’s the difference between a fast fix and an hour of guessing.

Web stack checks

curl -I http://127.0.0.1
curl -Ik https://example.com --resolve example.com:443:127.0.0.1

Apache status and config test:

/usr/local/apache/bin/apachectl -t
systemctl status httpd --no-pager

cPanel service health

/usr/local/cpanel/scripts/restartsrv_cpsrvd
/usr/local/cpanel/scripts/restartsrv_tailwatchd
/usr/local/cpanel/scripts/restartsrv_dnsadmin

DNS resolution from the server

dig +short example.com A
dig +short example.com MX
dig +short default._domainkey.example.com TXT

Mail checks

exim -bpc
tail -n 80 /var/log/exim_mainlog

Hardening after a restore (small steps that prevent the next restore)

A restore is a reset point. Use it to fix easy risks: weak access, stale software, and backups that only work on paper.

  • Enable 2FA for WHM and resellers: follow this WHM 2FA setup guide.
  • Restrict WHM/cPanel access to trusted networks where possible. IP allowlisting cuts noise immediately.
  • Patch and reboot planning: put the server on a predictable update cadence.
  • Backup restore tests: schedule them. One successful restore today doesn’t guarantee the next one will work.

Summary: a restore workflow you can repeat

Restoring a cPanel account isn’t “upload archive, click restore, done.” A reliable workflow is more deliberate.

Run preflight checks, restore using the right method, and verify through a hosts-file override before any DNS changes. Then fix permissions, PHP mismatches, SSL, and mail routing.

Write the checklist down and keep the logs. Your next incident will be calmer.

If restores are dragging, hardware is usually the bottleneck. For consistent performance and predictable recovery windows, run WHM on a properly sized HostMyCode VPS or choose managed VPS hosting when you’d rather hand off day-to-day server administration.

If you restore cPanel accounts regularly (or you want a recovery plan that holds up under pressure), run WHM on a stable platform with enough CPU and disk I/O to extract and rebuild accounts quickly. Start with a HostMyCode VPS, or pick managed VPS hosting if you want help with updates, security, and operational hygiene.

FAQ

Should I restore a cPanel account onto a server with a different cPanel version?

Try to keep destination cPanel/WHM at the same major version or newer. Restoring from newer to older is where you’ll hit compatibility issues first.

Can I restore the website but not the email?

Yes. If mail is handled elsewhere (like Microsoft 365 or Google Workspace), restore the account content and databases. Then ensure MX records still point to your mail provider.

Why does AutoSSL fail right after a restore?

Most often, DNS still points to the old server. AutoSSL validation hits the wrong IP, so issuance fails. Verify A/AAAA records and re-run AutoSSL once the domain resolves correctly.

What’s the safest way to test a restored site before DNS cutover?

Use a hosts-file override (or curl --resolve) so only your machine targets the new server. That prevents accidental public cutovers while you validate.

After restore, I’m getting 403/500 errors. What should I check first?

Check ownership and permissions in /home/USERNAME/public_html. Then confirm the domain’s PHP version/handler in MultiPHP Manager. Those two fixes resolve a large share of post-restore outages.