WordPress Rollback on AlmaLinux and Rocky Linux VPS

When a WordPress update breaks checkout

WordPress rollback is the safest way to recover a live site after a bad plugin update, theme change, or failed core upgrade. This guide shows you how to restore WordPress files and the database on an AlmaLinux or Rocky Linux VPS, then confirm that the site, checkout, and login still work. If you run customer stores on a managed or self-managed server, this is the recovery process you want ready before launch. For teams planning larger moves, Hostperl VPS hosting gives you the control to keep backups, test restores, and roll back fast when a release goes wrong.

This guide uses AlmaLinux and Rocky Linux because they match the RHEL-compatible tooling many Hostperl customers already run in production. You will start from a fresh SSH session, create a non-root admin, stop the affected service safely, restore WordPress files and MariaDB data, and verify the result with real checks. If you need a rehearsal before a live cutover, pair this workflow with WordPress migration rehearsal for safer 2026 cutovers and WordPress recovery plan for updates, migrations, and rollbacks.

What you need before you start

• An AlmaLinux 9 or Rocky Linux 9 VPS.
• Root SSH access to the server.
• A recent WordPress backup with both files and a MariaDB dump.
• Your site path, which this tutorial assumes is /var/www/example.com.
• Your database name, database user, and backup filenames.

This procedure assumes you already have a working WordPress site and a backup from before the failure. If your site is down because of a plugin crash, do not keep refreshing the browser. Capture what failed first, then restore a known-good copy.

Connect and confirm the operating system

On your local computer, open an SSH session to the VPS.

ssh root@203.0.113.10

203.0.113.10 is a reserved documentation address. Replace it with the public IP assigned to your server. If your provider gives you a default non-root account, use that account name with the same IP.

On the VPS as root, confirm the operating system before you touch packages or services.

cat /etc/os-release

You should see AlmaLinux or Rocky Linux release details. The rest of this tutorial uses dnf, firewalld, and SELinux-aware commands.

Create a non-root sudo user and keep root open

Do not close your root session yet. Open a second terminal later and test the new account before you disable anything.

On the VPS as root, create the administrator account, set a password, and add it to the wheel group.

useradd -m -s /bin/bash deploy
passwd deploy
usermod -aG wheel deploy

This creates the deploy account, prompts for a password, and grants sudo rights through wheel. If you use SSH keys only, you can lock the password later.

On the VPS as root, create the SSH directory and set restrictive permissions.

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

If you do not keep your root key in /root/.ssh/authorized_keys, paste the correct public key into /home/deploy/.ssh/authorized_keys instead. The goal is straightforward: the new account must log in before you change any root login settings.

On your local computer, open a second terminal and test the new session.

ssh deploy@203.0.113.10

After you log in, confirm sudo works.

sudo -v
sudo whoami

You should see root as the second command output. Keep the original root shell open until this step succeeds.

Install the restore tools and check the current state

On the VPS as the non-root sudo user, update packages and install the tools you need for a clean rollback.

sudo dnf -y update
sudo dnf -y install mariadb-server rsync tar gzip policycoreutils-python-utils firewalld

This tutorial uses MariaDB because many WordPress VPS deployments on AlmaLinux and Rocky Linux use it by default. If your site uses MySQL instead, the file and database steps are similar.

On the VPS as the non-root sudo user, check the current WordPress files and services before restoring.

pwd
sudo systemctl status mariadb --no-pager
sudo systemctl status firewalld --no-pager
sudo ls -lah /var/www/example.com

Replace /var/www/example.com with your real document root. You want a quick baseline so you can compare after the restore.

Back up the broken state before you overwrite anything

A rollback should not destroy the evidence. Save the current files and database first, even if the site is already failing.

On the VPS as the non-root sudo user, make a safety copy of the live directory and the database.

sudo mkdir -p /root/wp-rollback-safety
sudo rsync -aHAX /var/www/example.com/ /root/wp-rollback-safety/files/
sudo mariadb-dump --single-transaction --quick --routines --triggers exampledb | sudo gzip > /root/wp-rollback-safety/current-db.sql.gz

Replace exampledb with your live database name. If the current state helps with debugging, you now have a copy before the rollback.

Restore WordPress files from the last known good backup

File restores usually mean replacing plugin, theme, or core files while keeping uploads where appropriate. If the problem came from a bad plugin update, you can often restore only wp-content/plugins and wp-content/themes. For a broader failure, restore the full site tree.

On the VPS as the non-root sudo user, stop the web server briefly so files do not change during the copy.

sudo systemctl stop nginx

If your site uses Apache instead, stop httpd instead of nginx. The service name must match your stack.

On the VPS as the non-root sudo user, restore the files from your backup archive or snapshot.

sudo rsync -aHAX --delete /backups/example.com/files/ /var/www/example.com/

Replace /backups/example.com/files/ with the path to your known-good backup. The --delete flag makes the restored tree match the backup exactly, so use it only when you are sure the backup is correct.

On the VPS as the non-root sudo user, fix ownership and SELinux labels before starting services again.

sudo chown -R nginx:nginx /var/www/example.com
sudo restorecon -Rv /var/www/example.com

If your web server runs as apache instead of nginx, change the ownership accordingly. The restorecon step matters on AlmaLinux and Rocky Linux because SELinux can block the site even when file permissions look correct.

Restore the MariaDB database cleanly

Database rollback is usually what fixes broken checkout pages, corrupted settings, and plugin data drift. If your store changed orders after the bad update, be careful: restoring an older database can overwrite recent transactions. In that case, restore to staging first and compare.

On the VPS as the non-root sudo user, confirm the database service is running before you import.

sudo systemctl start mariadb
sudo systemctl enable mariadb
sudo systemctl status mariadb --no-pager

On the VPS as the non-root sudo user, restore the dump to the live database.

gunzip -c /backups/example.com/exampledb.sql.gz | sudo mariadb exampledb

Replace the backup path and database name with your own values. If your backup includes a database drop-and-create section, review it first. For most WordPress restores, importing into the existing database is enough.

On the VPS as the non-root sudo user, check that WordPress tables are present.

sudo mariadb -e "USE exampledb; SHOW TABLES;"

You should see tables such as wp_options, wp_posts, and wp_users. If the list is empty, the import did not complete.

Bring the site back up and test configuration

On the VPS as the non-root sudo user, test the Nginx configuration before you reload it.

sudo nginx -t

Look for syntax is ok and test is successful. If you use Apache, run sudo apachectl configtest instead.

On the VPS as the non-root sudo user, start and enable the web server.

sudo systemctl start nginx
sudo systemctl enable nginx
sudo systemctl restart php-fpm

Adjust the PHP-FPM service name to match the installed version, such as php-fpm or php82-php-fpm. WordPress needs PHP and the web server to come back together.

On the VPS as the non-root sudo user, check the service state and listening ports.

sudo systemctl status nginx --no-pager
sudo systemctl status php-fpm --no-pager
sudo ss -tulpn | grep -E ':80|:443'

HTTP and HTTPS should listen on the expected ports. If they do not, stop here and fix the web server before testing the browser.

Open the firewall without creating a lockout

Only touch firewall rules after the service is healthy. That way you do not expose a broken stack.

On the VPS as the non-root sudo user, open the web ports with firewalld and reload the rules.

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

You should see http and https in the active services list. If SSH is not already allowed, add it before you close any current session.

Verify the WordPress rollback from server and client

On the VPS as the non-root sudo user, check the recent error logs.

sudo tail -n 50 /var/log/nginx/error.log
sudo journalctl -u php-fpm -n 50 --no-pager

Any missing file, PHP fatal error, or permission problem usually shows up here first. Fix the error before you call the rollback complete.

On your local computer, test the site with HTTP requests.

curl -I http://203.0.113.10
curl -I https://example.com

Replace the IP and domain with your own values. A successful response should return 200 or a clean redirect to the canonical host name.

On your local computer, open the storefront and check the exact customer path that failed.

curl -s https://example.com/checkout | head

For WooCommerce, confirm the cart and checkout pages load without database errors. If the site has a maintenance page cached at the CDN edge, purge that cache before you judge the result.

Common failure points and fast fixes

Permission denied after file restore. Check ownership and SELinux labels.

sudo ls -ld /var/www/example.com /var/www/example.com/wp-content
sudo restorecon -Rv /var/www/example.com

If the web server user cannot read the files, correct ownership with chown and test again.

Database import hangs or fails. Inspect the MariaDB service and the dump file.

sudo systemctl status mariadb --no-pager
sudo gzip -t /backups/example.com/exampledb.sql.gz

If the dump is corrupt, restore from the previous backup set. If the database service stopped, check journalctl -u mariadb for the exact error.

Site loads but checkout still fails. That often means a plugin or object cache mismatch remains.

sudo ls -lah /var/www/example.com/wp-content/object-cache.php
sudo rm -f /var/www/example.com/wp-content/object-cache.php

Remove only the cache drop-in if your stack uses one and the backup did not include it. Then reload PHP-FPM and retest checkout.

Rollback and recovery plan after the restore

Once the site is stable, keep the restore path for the next incident. Save the working backup location, note the plugin or update that caused the break, and schedule a restore drill. If you host multiple client sites, Hostperl WHM backup restore drill on AlmaLinux pairs well with this WordPress workflow, especially for agencies that need repeatable recovery steps.

If you want a VPS that can handle maintenance windows, restore testing, and customer launches without surprises, Hostperl VPS hosting gives you the isolation and control to run real rollback drills. For WordPress-specific deployments, Hostperl shared hosting is a good fit for smaller sites that do not need full server access.

FAQ

Should I restore files first or the database first?

Restore the database first if the failure is data-related, such as broken checkout logic or corrupted settings. Restore files first if the issue came from a bad plugin or theme file. In practice, many production rollbacks need both.

Can I roll back only one plugin?

Yes. If the plugin folder is isolated, restore only wp-content/plugins/plugin-name from the last known good backup. Then test the site and checkout flow before you touch anything else.

Why does the site still fail after a restore?

Most often the problem is file ownership, SELinux labels, PHP cache, or an incomplete database import. Check the Nginx error log, PHP-FPM logs, and MariaDB status in that order.

How do I avoid losing recent orders?

Pause the store, export recent orders separately if needed, or restore to staging first and compare the database timestamps. For active stores, a rollback should be planned around the business window, not just the server window.