DirectAdmin Region Failover for Agencies on RHEL 9

Why region failover matters for agency hosting

If you run client sites from a regional DirectAdmin server, a solid failover plan matters more than raw hardware. A lost mailbox, stale DNS record, or rushed cutover can turn a routine move into a morning of support tickets.

This tutorial shows how to prepare DirectAdmin region failover on RHEL 9 with a primary-and-standby approach agencies can actually use. You'll build a safe cutover path, keep the old server intact until the new one passes checks, and verify that accounts, DNS, and HTTPS still work after the move. If you're sizing the next server as part of the migration, Hostperl's dedicated server hosting is a better fit than squeezing a busy agency stack onto an undersized VPS.

For teams that already work inside DirectAdmin, this pairs well with account transfer workflows like WHM account transfer on AlmaLinux with zero downtime, but the goal here is different. You're planning for region-level continuity, not just copying a single account.

What you will build

You will prepare a standby RHEL 9 server, install DirectAdmin prerequisites, move a small agency account set, update DNS with a low TTL, test mail and web traffic, then switch traffic only after validation. The rollback plan stays simple: keep the source server live until the standby proves itself.

• OS: RHEL 9
• Panel: DirectAdmin
• Goal: region-aware failover for agency hosting accounts
• Cutover method: staged DNS switchover with verification before old server retirement

Before you start

You need root access to both servers, a working DirectAdmin license on the destination, and enough disk space for website files, databases, and mail if you host mail locally. This guide assumes the source server already serves live accounts.

Use the reserved documentation IP in the examples below. Replace 203.0.113.10 with your own server's public IP before running any command.

1) Connect to the source server and confirm the OS

On your local computer, open your first SSH session to the existing server.

ssh root@203.0.113.10

That IP is only a documentation example. Replace it with the real public IP assigned by your provider.

On the VPS as root, confirm the operating system and basic identity before you change anything.

cat /etc/os-release

You should see RHEL 9 details. If you're on Oracle Linux or Fedora Server instead, the package names are similar, but lifecycle and repository steps differ enough that you should adapt them first.

hostnamectl

This confirms the host name and kernel. If the server name is unclear, set one now so logs and panel alerts are easier to read.

2) Prepare a non-root admin for the destination server

You should not do the entire cutover as root. Create a sudo user first, keep the original root session open, and test the new login in a second terminal.

On the VPS as root, create the admin user and add it to the wheel group.

useradd -m -G wheel deploy
passwd deploy

Set a strong password when prompted. If your support process uses SSH keys only, you can lock the password later after key login is verified.

On the VPS as root, create the SSH directory and copy your public key.

mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
cat > /home/deploy/.ssh/authorized_keys <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyForDocumentationOnly deploy@laptop
EOF
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

Replace the example key with your real public key. The permissions matter; if they are too open, SSH will ignore the file.

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

ssh deploy@203.0.113.10

Then test sudo.

sudo -v

If sudo works, keep the original root session open for now. Do not disable root SSH until the destination server is fully ready.

3) Update packages and basic system settings on RHEL 9

On the VPS as the non-root sudo user, move into a sudo shell and update the destination system.

sudo -iu root
dnf update -y

RHEL 9 uses dnf. If the update pulls in a new kernel, plan for a reboot before the final cutover.

timedatectl set-timezone UTC
timedatectl status

Use UTC for predictable logs across regions. Agencies with support staff in New Zealand or APAC often find that UTC avoids confusion during overnight maintenance.

4) Install the DirectAdmin prerequisites

This step assumes the destination server will host the panel, web stack, and DNS or mail services required for the migrated accounts. DirectAdmin installs are license- and version-specific, so follow your license portal instructions for the panel itself. The system prerequisites below are the part you can safely prepare now.

On the VPS as root, install basic tooling, firewall services, and SELinux utilities.

dnf install -y curl wget tar rsync unzip firewalld policycoreutils-python-utils bind-utils lsof

Enable the firewall now, before you open panel ports.

systemctl enable --now firewalld

On RHEL 9, SELinux should stay enforcing unless DirectAdmin's documented setup explicitly requires a temporary change. Check the status before you proceed.

getenforce

Expected output: Enforcing. If you get Disabled, fix that before you put the new server into production.

For a broader RHEL-compatible hardening workflow, Hostperl also maintains a guide on crawlability checks for SEO on AlmaLinux 9 VPS; the OS family is similar, but this tutorial stays focused on failover operations.

5) Open only the ports you need

Open SSH first, then the panel and service ports after you confirm the destination is ready. Add rules before you tighten access anywhere else.

On the VPS as root, allow SSH, HTTPS, HTTP, and the common DirectAdmin port set used by your licensing and mail stack.

firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --permanent --add-port=2222/tcp
firewall-cmd --permanent --add-port=25/tcp
firewall-cmd --permanent --add-port=587/tcp
firewall-cmd --permanent --add-port=993/tcp
firewall-cmd --reload
firewall-cmd --list-all

Adjust the DirectAdmin port if your license or install script uses a different value. The list output should show the new rules active.

6) Synchronize the source account data

Now copy the live content from the source server to the standby server. For a real agency move, do this in stages: websites first, then databases, then mail if you host mail locally. Keep the source server online while you test.

On the destination server as root, create a staging directory.

mkdir -p /srv/failover-sync

On the destination server as root, pull the source account files with rsync.

rsync -aHAX --numeric-ids --delete root@203.0.113.10:/home/ /srv/failover-sync/home/

Replace the documentation IP with the source server's real IP. If SSH key trust is not set up between the servers yet, use a temporary jump host or run the transfer from the source side instead.

On the destination server as root, copy databases from the source after you place the panel into maintenance mode or pause writes on active sites.

mysqldump --all-databases --single-transaction --routines --triggers | gzip > /srv/failover-sync/all-databases.sql.gz

For PostgreSQL-heavy agencies, use a database-specific dump method instead. This tutorial keeps the example generic because DirectAdmin environments often mix database engines by client needs.

7) Point the destination server at the imported content

Move the copied files into place only after the transfer finishes cleanly. If your DirectAdmin layout differs, adapt the paths to match your panel templates and user homes.

On the destination server as root, inspect what arrived.

du -sh /srv/failover-sync/home/* | head

If the sizes look plausible, continue.

rsync -aHAX --numeric-ids /srv/failover-sync/home/ /home/

Then validate ownership and permissions.

find /home -maxdepth 2 -type d -name public_html -o -name domains | head

Do not rush this part. A wrong owner can break PHP, mail, or backup jobs later.

8) Install and verify the panel services

DirectAdmin itself is installed by its official installer and license process. After installation, verify the core services instead of assuming the panel is healthy.

On the VPS as root, check the expected services.

systemctl status httpd mariadb named exim dovecot directadmin --no-pager

If a service is missing, that tells you which stack pieces were not installed or started by the installer.

Check the listening ports too.

ss -tulpn | egrep ':(22|80|443|2222|25|587|993)\b'

You should see processes bound to the ports you opened. If a port is absent, the service may not be running or SELinux may be blocking it.

9) Validate DNS, web, and mail before switching traffic

Before you change live DNS, test the destination by hostname and direct IP. This avoids the classic mistake where a panel looks ready, but the public edge is still serving the old server.

On the destination server as root, run local DNS and HTTP checks.

dig +short example.com @127.0.0.1
curl -I http://127.0.0.1
curl -Ik https://127.0.0.1

You should get an answer for the domain and a valid HTTP response. If HTTPS is not ready yet, do not switch traffic. Fix the certificate or vhost first.

If you need a certificate repair reference later, Hostperl's technical SEO logs fix crawlability on Debian 12 VPS shows how logs reveal host and certificate problems, even though the OS differs.

10) Lower DNS TTL and switch records

Keep the TTL low before the move so caches expire quickly. This is the step that makes region failover practical.

On the DNS provider or authoritative server, reduce A, AAAA, MX, and any service subdomain TTLs to 300 seconds. Then wait at least one old TTL period before cutover.

On the destination server as root, confirm the records resolve to the new IP once you update them.

dig +short example.com
host example.com

If you manage nameservers locally, remember that the serial number in the zone file must move forward after any edit.

11) Test from a client before decommissioning the old server

On your local computer, run browser and command-line checks against the live hostname after DNS propagates.

curl -I https://example.com
curl -fsS https://example.com | head

Then test a real login or order flow if the hosted site is commercial. For agency work, that usually means logging into WordPress admin, submitting a contact form, and checking receipt mail.

For customer-facing CMS migrations, Hostperl's WordPress migration checklist for safer store cutovers is a useful companion when one of your accounts is WooCommerce-heavy.

12) Keep rollback simple

The safest rollback is to leave the source server unchanged until the new region proves stable. If something goes wrong after DNS changes, point the record back to the source IP and let the low TTL do the work.

On the DNS provider, revert the A and AAAA records to the old server if you see broken logins, missing files, or mail delivery failures. Do not destroy the old environment during the first verification window.

On the source server, keep an eye on the access logs and mail queue while the new server absorbs traffic.

tail -f /var/log/httpd/access_log /var/log/maillog

Those logs show whether customers are still hitting the old region or whether the new server is taking all traffic cleanly.

Common failures and how to diagnose them

1. SSH works, but the panel port times out. Check firewall and listening ports.

ss -tulpn | grep 2222
firewall-cmd --list-ports

If the port is missing, open it and reload firewalld. If it is listening but unreachable, check cloud security groups or upstream filtering.

2. HTTPS loads a certificate error after cutover. Inspect the active certificate and renewal logs.

openssl s_client -connect example.com:443 -servername example.com < /dev/null
journalctl -u certbot --no-pager -n 50

Renew or reissue the certificate, then test again before you tell clients the migration is done.

3. One account loses file ownership during sync. Compare owners on source and destination.

stat -c '%U:%G %n' /home/*/domains/*/public_html | head

Fix ownership with chown -R on the affected account only. Avoid broad recursive changes across all users unless you have confirmed the scope.

4. Mail queues build up on the new server. Check whether DNS MX records and SPF still match the new region.

mailq
postqueue -p
postconf -n | egrep 'myhostname|relayhost|inet_interfaces'

Then update SPF, DKIM, and any host-based filters. Mail is often the last part to settle after a regional move.

13) Reboot test and persistence check

Finish with one reboot on the destination server while the old server is still available. If the server does not come back cleanly, you can still revert DNS.

On the destination server as root, enable the key services at boot and reboot.

systemctl enable directadmin httpd mariadb named exim dovecot firewalld
reboot

After reconnecting, confirm the services and open ports again.

systemctl status directadmin httpd mariadb named exim dovecot firewalld --no-pager
ss -tulpn | egrep ':(22|80|443|2222|25|587|993)\b'

If the services survive reboot, the failover is durable enough for real customer traffic.

FAQ

Should I disable the old server immediately after cutover?

No. Keep it online until DNS has propagated, mail queues are clear, and you have completed at least one reboot test on the new region.

Can I use this procedure for Oracle Linux or Fedora Server?

Yes, in principle. The service names and SELinux tools are similar, but repository and lifecycle handling differ. Check package availability before you copy the exact RHEL 9 commands.

What is the safest rollback if clients report broken logins?

Point DNS back to the source server, verify the old site responds, and investigate file ownership, PHP sessions, or database synchronization before trying the cutover again.

Do I need to move mail during region failover?

Only if the server hosts client mail locally. If mail lives elsewhere, keep the scope on web, databases, and DNS to reduce risk.

Done correctly, DirectAdmin region failover gives you a practical way to move agency clients between regions without a hard outage. The key is to validate the new server before any DNS switch, keep rollback simple, and avoid retiring the old environment until the new one survives real traffic.