WHM Backup Restore Drill on AlmaLinux for Safer Migrations

Why you should test a WHM backup restore drill before migration day

A WHM backup restore drill is the quickest way to catch migration problems before they turn into customer downtime. On a fresh AlmaLinux server, you can verify cPanel account backups, confirm ownership and permissions, test database restores, and make sure the destination is ready for cutover.

This tutorial uses AlmaLinux and WHM because that setup is a common fit for production cPanel moves on Hostperl VPS and dedicated servers. If you are planning a real migration, pair this with a properly sized Hostperl VPS or dedicated server so the destination has enough CPU, memory, and disk I/O for the restore window.

The goal is not just to restore a file. You will create a non-root admin, lock down SSH, confirm the server OS, prepare the backup import path, run a controlled restore of one cPanel account, validate services, and keep a rollback path open if anything looks wrong.

What this WHM backup restore drill covers

• AlmaLinux 8/9 server setup with a non-root sudo user
• SSH hardening and firewall rules before service exposure
• WHM backup import location and restore preparation
• Account restore verification, including website, mail, and database checks
• Rollback steps if the restore reveals corruption or missing assets

Prerequisites and safe sequencing

Use a clean AlmaLinux 9 VPS or dedicated server with WHM already licensed and installed. For production migrations, keep the source server online until the restore checks pass and DNS is ready. Do not disable root login until your new admin account works in a second terminal.

For naming, this tutorial uses server.example.com as the hostname, example.com as the domain being restored, and deploy as the non-root admin user. Replace those examples with your own values. The IP example 203.0.113.10 is reserved for documentation only.

Connect to the server and confirm the operating system

On your local computer

ssh root@203.0.113.10

203.0.113.10 is a documentation example. Replace it with the public IP assigned to your server. If your provider gives you a default non-root account, connect with that account instead and then use sudo -i where required.

On the VPS as root

cat /etc/os-release

This confirms you are on AlmaLinux and shows the release version. You should see AlmaLinux in the output before you continue.

Create a non-root admin and keep the root session open

On the VPS as root

useradd -m -G wheel deploy
passwd deploy

This creates the deploy account, adds it to the wheel group, and sets a password for the first login. Keep the current root session open. If you prefer key-only access, you can lock the password later after SSH keys work.

mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

These commands copy the existing root key into the new account for a quick verification path. In a real migration, you may instead append a specific public key from your workstation. The permissions matter: SSH rejects loose ownership and mode settings.

Confirm sudo access before moving on:

su - deploy
sudo -l

You should see that deploy can run admin commands with sudo. Open a second terminal from your local computer and log in as deploy before making any root-login changes.

On your local computer

ssh deploy@203.0.113.10

After login, test sudo:

sudo whoami

The expected output is root. If that fails, stop here and fix account access before continuing.

Patch the system and prepare firewall rules

On the VPS as the non-root sudo user

sudo dnf update -y
sudo dnf install -y firewalld policycoreutils-python-utils rsync tar lsof

This updates the server and installs the tools used during the restore drill. policycoreutils-python-utils gives you SELinux management commands, which matter on AlmaLinux.

sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

Open SSH, HTTP, and HTTPS before you touch any SSH restrictions. If WHM is exposed on a custom port in your environment, add that port first and test it from a second terminal before removing any old access path.

Check SELinux state before restoring accounts

On the VPS as the non-root sudo user

getenforce

On AlmaLinux, SELinux often runs in Enforcing mode. That is normal. If you restore a cPanel account into a non-standard path, SELinux denials can block Apache, PHP-FPM, or mail processes later.

Install the restore tools used by WHM and watch logs if something is denied:

sudo ausearch -m avc -ts recent | tail -n 20

If you see denials tied to the restore path, fix the context instead of disabling SELinux. For most standard cPanel restores, WHM handles contexts correctly when the server is healthy.

Stage the backup and restore one cPanel account

The best drill uses one real cPanel backup file, not a theory. Copy the account archive to the destination server first. A typical WHM backup lives under /backup, but many teams move it into /home or a temporary restore directory during transport.

On the VPS as the non-root sudo user

sudo mkdir -p /restore-drill
sudo chown deploy:deploy /restore-drill

Place the backup file in /restore-drill. Then confirm it is intact:

cd /restore-drill
ls -lh
sha256sum *

You should see the archive and a checksum that matches the source copy. If the checksum differs, do not restore it.

Start the restore from WHM or from the command line if your team prefers terminal-driven maintenance. For a WHM-assisted drill, import the package through the account restore interface and restore only one account first. That keeps the blast radius small.

If you use the command line on AlmaLinux for validation around the restore, the archive often expands under a temporary tree. Confirm that the expected files exist after the restore completes:

sudo find /home/examplecom -maxdepth 2 -type f | head -n 20

Replace /home/examplecom with the actual restored account home directory. You should see website files, mail data, and application assets if the backup is complete.

Verify ownership, permissions, and services in the WHM backup restore drill

A restore only matters if the account can actually serve traffic. Check the restored ownership first, because bad permissions are a common post-migration failure.

On the VPS as the non-root sudo user

sudo ls -ld /home/examplecom /home/examplecom/public_html
sudo find /home/examplecom -maxdepth 1 -type d -printf '%M %u:%g %p\n'

Ownership should normally point to the restored cPanel account user, not root. If you see root-owned files, fix them before testing the site.

sudo systemctl status httpd --no-pager
sudo systemctl status mariadb --no-pager
sudo systemctl status dovecot --no-pager
sudo systemctl status exim --no-pager

These are the services that usually determine whether a restored account works for web, database, and email delivery. If one is inactive, check the logs immediately instead of guessing.

sudo journalctl -u httpd -n 50 --no-pager
sudo journalctl -u mariadb -n 50 --no-pager
sudo journalctl -u exim -n 50 --no-pager

Look for syntax errors, missing sockets, SELinux denials, or port conflicts.

Run client-side smoke tests

On your local computer

curl -I http://203.0.113.10

This confirms the web server answers on the public IP. Replace 203.0.113.10 with your server IP. You should get an HTTP status line, usually 200, 301, or 302, depending on the site configuration.

curl -s http://203.0.113.10 | head

If the restored account hosts a known landing page, confirm that the HTML you expect is present. For HTTPS-enabled sites, test the certificate as well:

curl -I https://203.0.113.10

A certificate warning may appear if you have not updated DNS yet. That is acceptable during the drill, but the certificate must be valid before the real cutover.

If you are also refreshing site structure or answer-first content during the move, pair this drill with Hostperl guidance on technical SEO for hosting sites that answer fast in 2026 and answer-first SEO on Hostperl VPS. That helps you avoid restoring a site that is technically live but poorly prepared for search discovery.

Handle the most likely restore problems

If the restore fails, diagnose the problem before changing anything else. These are the issues support teams see most often during migration windows.

Problem: the archive does not import

sudo ls -lh /restore-drill
sudo sha256sum /restore-drill/*

If the file size is zero or the checksum does not match, re-copy the archive from the source server. Do not retry a broken archive.

Problem: the site loads a blank page or 500 error

sudo tail -n 50 /usr/local/apache/logs/error_log
sudo tail -n 50 /var/log/php-fpm/error.log

Missing PHP extensions, wrong document root, or bad ownership usually show up here. Correct the package or path, then reload the service that changed.

Problem: mail does not send after restore

sudo exim -bpr | head
sudo tail -n 50 /var/log/exim_mainlog

Queue buildup or relay restrictions point to delivery configuration rather than the backup itself. Fix the hostname, SPF, DKIM, or relay policy before the cutover. For mail-specific DNS work, Hostperl has a related guide on DNSSEC and email authentication.

Rollback and recovery if the drill exposes a bad restore

Keep the original server untouched until the new one passes these checks: SSH access, HTTP response, database access, mail queue health, and at least one real browser visit from your workstation. If the restore is clearly wrong, revert by removing the imported account on the destination and re-running the import from a clean backup.

On the VPS as the non-root sudo user

sudo /scripts/removeacct examplecom

Use this only if you are sure the destination account is the failed test restore and not a live production account. After removal, re-import the backup, check ownership again, and repeat the smoke tests.

If you need a stable fallback during a larger move, keep the source site serving while you repair the destination. That is the safest path for customer-facing sites with live orders or ticket traffic.

Lock down SSH after the new account is proven

Only after the new admin login works should you remove root password login or tighten SSH further. First, make sure your current root session is still open and that the deploy account works from a second terminal.

On the VPS as root

sed -i 's/^#\?PermitRootLogin .*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config
sed -i 's/^#\?PasswordAuthentication .*/PasswordAuthentication no/' /etc/ssh/sshd_config
sshd -t
systemctl reload sshd

sshd -t checks the syntax before reload. If the test passes, the reload keeps existing sessions alive while applying the safer SSH policy. Do not close your root shell until you confirm a fresh login works with keys.

On your local computer

ssh deploy@203.0.113.10

Then confirm sudo still works:

sudo whoami

If that succeeds, the server is in a safer state than when you started.

Final checks before a live migration

Before you point DNS at the new server, run one last checklist from the server and from your workstation. You want clean services, open ports, and a known-good backup copy.

On the VPS as the non-root sudo user

sudo ss -tulpn
sudo systemctl is-enabled httpd mariadb dovecot exim firewalld
sudo journalctl -p err -n 50 --no-pager

On your local computer

curl -I http://203.0.113.10
curl -I https://203.0.113.10

If both sides look clean, you have a restore you can trust, not just a backup you hope will work.

FAQ

Should I restore the full cPanel backup first?

Not always. Start with one representative account. If that restore works, the rest of the migration is far less risky.

Can I do this drill on a live production server?

Yes, but only if you restore into a separate account path or a separate destination server. Do not overwrite a live account during testing.

What if WHM says the backup is valid but the site is broken?

Check ownership, Apache error logs, PHP-FPM logs, and database service status. A valid archive can still produce a broken site if permissions or services are wrong.

When should I remove root SSH access?

After the new sudo user works from a second terminal and you have confirmed key-based login. Keep a root session open until then.

Does SELinux need to be disabled on AlmaLinux?

No. Leave SELinux enforcing unless you have a specific, documented reason to change it. Most restore issues are better fixed by correcting file contexts or paths.

Conclusion

A WHM backup restore drill gives you evidence before cutover. On AlmaLinux, that means testing the account import, watching service health, checking SELinux and firewalld, and proving that a client can reach the restored site from the outside. If you are planning a migration on Hostperl infrastructure, this is the kind of test that turns a risky move into a controlled one.

For the next step, keep your backup schedule current and pair this drill with a production-ready migration checklist so the real cutover follows the same verified sequence.