//Web Panel

Disaster Recovery Guide: Restore Full cPanel Fleet with JetBackup

Restore an entire cPanel fleet to a new server using JetBackup. Step-by-step guide for AlmaLinux 9 setup, bulk restore, and DNS updates.

5 min read
Disaster Recovery Guide: Restore Full cPanel Fleet with JetBackup

Managing a fleet of cPanel servers involves juggling thousands of sites, databases, and mailboxes. Even with robust monitoring, hardware failures, ransomware, or accidental deletions can still occur. A well‑defined disaster‑recovery (DR) plan lets you restore the entire environment quickly and with minimal data loss. This guide walks you through restoring an entire cPanel fleet onto a brand‑new server using JetBackup, the backup solution that integrates directly with cPanel.

1. Prepare the New Server

The target machine must be ready to host cPanel and the restored accounts before any backup data is pulled.

1.1 Install the Operating System

cPanel’s current official distribution is AlmaLinux 9 (or Rocky Linux 9). The following commands are for a fresh AlmaLinux 9 install. If you use a different OS, adjust accordingly.

# dnf update -y
# dnf install -y wget perl

What it does: Updates all packages to the latest available versions and installs wget (needed to download the installer) and perl, which is required by cPanel.

1.2 Set Hostname and Network

# hostnamectl set-hostname server01.example.com
# nmcli con modify "System eth0" ipv4.addresses "203.0.113.10/24"
# nmcli con modify "System eth0" ipv4.gateway "203.0.113.1"
# nmcli con up "System eth0"

What it does: Assigns a fully qualified domain name (FQDN) and configures the primary network interface with a static IP and gateway.

1.3 Install cPanel & WHM

Download and run the official installer. The process can take 30–60 minutes depending on bandwidth and system performance.

# cd /home
# curl -o latest -L https://securedownloads.cpanel.net/latest
# sh latest

What it does: Retrieves the latest cPanel installer script and executes it, pulling in all required packages, services, and configuration files.

1.4 Verify Licensing

After installation, log into WHM at https://your-ip:2087 with root credentials. Navigate to Server Configuration → Manage License and confirm the license is active. If the license is missing, contact AtoZNode support to assign one to the new IP address.

2. Configure JetBackup on the New Server

JetBackup must be installed and linked to the same backup destination that the source servers use (S3, remote FTP, NAS, etc.).

2.1 Install JetBackup via WHM

  • Log in to WHM.
  • Navigate to cPanel → Manage Plugins → Install Plugins.
  • Search for “JetBackup” and click Install.

2.2 Add the Remote Backup Destination

In WHM, go to JetBackup → Destinations → Add Destination. Select the type that matches your existing backups (e.g., “Amazon S3”, “Remote FTP”, “Local Disk”). Enter the same credentials that were used on the source servers.

After adding the destination, click Test Connection to ensure the new server can read the backup files.

3. Restore the Server Fleet

JetBackup allows both account‑level and full‑server restores. For a complete fleet restore, use the full‑server option.

3.1 Locate the Full Server Backup

In JetBackup, open Backups → Server Backups. Identify the most recent full backup (usually labeled with the server’s hostname and a timestamp). Note the backup ID; you’ll need it for the CLI command.

3.2 Use the CLI for Bulk Restore

While WHM offers a graphical restore, the command‑line method is faster for many accounts.

# /usr/local/jetapps/jetbackup/bin/jetbackup3 restore --type=full \
    --server=server01.example.com --backup-id=2024-09-15_02-00-00 \
    --target=/

What it does: Calls JetBackup’s internal script to restore the entire snapshot identified by --backup-id onto the root filesystem (--target=/). Replace the server name and backup ID with your values.

3.3 Verify Restored Services

  • Apache/Nginx: systemctl status httpd or systemctl status nginx
  • MySQL/MariaDB: systemctl status mariadb
  • DNS: systemctl status named
  • Open a few random cPanel accounts and confirm that files, databases, and email are present.

3.4 Re‑apply Custom Configurations

Some settings live outside JetBackup (e.g., firewall rules, ModSecurity rules, third‑party PHP extensions). Compare the /etc/ directory on the old server (if still available) with the new one and copy any necessary files.

4. Update DNS and Routing

After the restored server is verified, point traffic to it.

4.1 Update Nameserver Records

If the server hosts its own nameservers (e.g., ns1.example.com), log into your domain registrar and change the A records to the new IP address.

4.2 Adjust cPanel’s IP Mapping

# /usr/local/cpanel/scripts/ipchange 203.0.113.10

This command updates cPanel’s internal IP mapping tables, ensuring new accounts receive the correct IP.

4.3 Propagation Checks

Use dig or an online DNS checker to confirm that queries resolve to the new server. For critical sites, consider lowering TTLs a day before the migration so the switch happens faster.

5. Automate Future Restores

Repeatable automation makes disaster recovery faster and less error‑prone.

5.1 Create a Restoration Script

#!/bin/bash
# restore_cpanel_fleet.sh
# AlmaLinux 9 – JetBackup full server restore

SERVER_NAME=$1
BACKUP_ID=$2

if [[ -z "$SERVER_NAME" || -z "$BACKUP_ID" ]]; then
  echo "Usage: $0  "
  exit 1
fi

/usr/local/jetapps/jetbackup/bin/jetbackup3 restore --type=full \
    --server="$SERVER_NAME" --backup-id="$BACKUP_ID" --target=/

# Restart core services
systemctl restart httpd mariadb named

echo "Restore completed for $SERVER_NAME (backup $BACKUP_ID)"

Make the script executable (chmod +x restore_cpanel_fleet.sh) and store it securely. Run it like:

# ./restore_cpanel_fleet.sh server01.example.com 2024-09-15_02-00-00

5.2 Schedule Regular Backup Tests

Set a quarterly reminder to perform a test restore on a staging server. This validates both backup integrity and the restoration workflow.

6. Post‑Recovery Checklist

  • Security: Run /usr/local/cpanel/scripts/check_cpanel_rpms --fix to ensure all cPanel packages are up to date.
  • SSL: Re‑issue Let’s Encrypt or commercial certificates if the IP changed.
  • Monitoring: Verify that AtoZNode’s monitoring agents (e.g., Netdata, Zabbix) report correctly.
  • Backup Configuration: Confirm JetBackup’s schedule points to the same remote destination and that retention policies match the pre‑failure setup.
  • Documentation: Record any deviations from the standard process (e.g., manual configuration tweaks) for future reference.

Conclusion

Restoring an entire cPanel fleet with JetBackup is straightforward when you follow a disciplined, step‑by‑step approach: prepare a clean AlmaLinux 9 host, install cPanel, configure JetBackup, perform a bulk restore, and bring DNS and services back online. By automating the core commands and testing the workflow regularly, you can turn a potentially disruptive outage into a controlled, repeatable event. Keep this guide handy, adapt it to your environment, and you’ll be ready to recover quickly whenever disaster strikes.

cpaneljetbackupdisaster recoveryalmalinuxbackup restorationdns migrationserver automationlinux administration

Try it on your own server

Follow along on a Cloud VPS with full root access, or read the step-by-step knowledge base guides.