R1Soft bare-metal restore for cPanel servers

R1Soft's bare-metal restore (BMR) is the reason most hosts pick it over file-level backup tools. When a cPanel node's RAID array fails, the boot disk dies, or a kernel update wrecks the initramfs, BMR lets you reimage the entire server — partitions, LVM, swap, the cPanel install, every customer home directory — onto fresh hardware or a fresh VM in a couple of hours, straight from the Server Backup Manager (SBM).

This guide walks the end-to-end procedure for a single-disk or RAID-backed cPanel node. Plan 2–4 hours wall-clock for a 500 GB recovery point over a 1 Gbit link, mostly waiting for block transfer. The actual hands-on time is under 30 minutes.

When BMR is the right tool

Use BMR when:

• The server won't boot and you can't get to a usable rescue shell
• The boot disk or RAID array has physically failed
• A botched kernel, glibc, or /boot change has bricked the OS
• You're migrating to new hardware and want a bit-for-bit clone — same hostname, same IPs, same disk layout

Don't use BMR when:

• A single customer wants a single file back — use the cPanel self-service restore plugin
• A MySQL database is corrupt — restore from an application-aware backup into the running server
• The server is fine but /var filled up — fix it in place; a full BMR for a free-space issue is overkill

Prerequisites

• A completed recovery point on the SBM for the failed server
• The SBM IP, hostname, and an admin login that can authorise the agent
• A target machine — same or larger disk capacity than the source. Smaller disks fail mid-restore; CPU and RAM don't have to match.
• IPMI, iDRAC, or hypervisor console access on the target — the BMR runs from a Live ISO and you'll need keyboard and screen
• A valid R1Soft license on the SBM that still covers the agent slot you're restoring into

Step 1 — Download the BMR Live CD

The BMR ISO is built per major SBM version. Grab the matching one from the SBM web UI under Recovery → Bare-Metal Restore → Download Live CD, or directly from R1Soft's download server.

# from the SBM box, mirror it for fleet use
wget https://download.r1soft.com/server-backup-manager/bmr/latest/r1soft-bmr.iso
sha256sum r1soft-bmr.iso

Mount it as virtual media in iDRAC / iLO / iKVM, attach it to the VM as a CD-ROM, or write it to a USB stick:

dd if=r1soft-bmr.iso of=/dev/sdX bs=4M status=progress conv=fsync

The ISO is roughly 700 MB and boots a stripped Debian environment with the R1Soft agent preloaded.

Step 2 — Boot the target and configure networking

Boot from the ISO. The BMR launches into a TUI menu within 60 seconds. The first task is networking — without it the agent can't reach the SBM.

From the menu pick Configure Network. Pick the interface (BMR detects most onboard NICs but skips some 10G cards — load the driver from a USB stick if needed), then choose DHCP or static. For a production restore, set the IP statically to the failed server's address. This matters: cPanel keys, named.conf zone IPs, and outbound mail SPF all depend on the original address, and changing them post-restore is more work than booting on the right IP.

Verify connectivity to the SBM:

ping -c 3 sbm.example.com
nc -zv sbm.example.com 1167

TCP/1167 must be open both ways — the BMR agent will receive blocks on that port.

Step 3 — Initialise the target disks

From the BMR menu pick Hardware → Configure Disks. The ISO ships with gdisk, parted, mdadm, and lvm2. If the target hardware needs RAID assembled before restore, build the array first:

# Software RAID 1 across two NVMe drives
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/nvme0n1 /dev/nvme1n1

For hardware RAID, build the logical volume in the controller BIOS before booting the ISO.

You do not need to pre-partition the disks — R1Soft will reapply the source's exact partition table during restore. Just expose the raw block devices.

Step 4 — Register with the SBM and pick the recovery point

Back at the main menu, pick Connect to Server Backup Manager.

1. Enter the SBM hostname or IP
2. Enter your admin username and password
3. The ISO registers itself as a temporary agent

On the SBM side, the BMR agent appears under Agents with a [BMR] tag. Now in the SBM UI go to Recovery Points, find the failed server, click the recovery point you want, and choose Bare Metal Restore. Pick the BMR agent as the destination.

The SBM prompts you to map source disks to target disks:

Source: /dev/sda  (480 GB)  →  Target: /dev/nvme0n1 (960 GB)
Source: /dev/sdb  (480 GB)  →  Target: /dev/nvme1n1 (960 GB)

Confirm the mapping. This step overwrites the target disks completely — there is no undo.

Step 5 — Restore and monitor

Click Restore. The BMR rewrites partition tables, recreates LVM groups and volumes, and streams every block from the disk safe. Progress shows in both the BMR TUI and the SBM Tasks panel.

Typical throughput on a 1 Gbit link is 80–110 MB/s sustained, so a 500 GB recovery point lands in about 90 minutes. NVMe on both sides over 10 Gbit can push 400–600 MB/s and finishes a similar restore in 15–20 minutes.

When the transfer finishes, the BMR ISO prompts to reboot. Pull the ISO from the virtual media menu first, then reboot.

Step 6 — Post-restore fixes for cPanel

The OS will boot. cPanel, named, MySQL, and exim will start. Most servers come up clean — but there are four predictable issues to clear before opening the firewall.

1. Filesystem UUIDs. If you restored across different disk hardware (NVMe → SATA, single disk → RAID), /etc/fstab UUIDs still match the source disk metadata because R1Soft restores the filesystem byte-for-byte. Usually this Just Works. If it doesn't and the system drops to emergency mode, edit /etc/fstab from the BMR rescue shell and replace UUIDs with the new ones from blkid.

2. Network config. Verify nmcli or /etc/sysconfig/network-scripts/ reports the right interface name. RHEL 9 sometimes renames NICs based on PCI slot — if the source was eno1 and the new hardware exposes enp3s0, copy the config and restart NetworkManager.

3. cPanel license check. Run /usr/local/cpanel/cpkeyclt to refresh the license against the cPanel licensing server. If the IP is identical to the source, this is a no-op. If you restored onto a different IP, also confirm the cPanel license covers the new address.

4. MySQL recovery. InnoDB does crash recovery on first start since the source server's mysqld didn't shut down cleanly. Watch /var/lib/mysql/<hostname>.err for InnoDB: ... ready for connections. If it stalls, restore the database tier from an application-aware MySQL backup instead of re-running BMR.

Once those four are clear, run cPanel's own health checks:

/scripts/restartsrv_cpsrvd
/scripts/upcp --force
whmapi1 servicestatus

Anything failing here is usually a service that needs a config tweak after the hardware change, not a backup-integrity issue.

Step 7 — Re-attach the restored server to the SBM

The original agent record on the SBM still points to the old install. Reuse it: SSH into the restored cPanel server and run:

serverbackup-setup --get-key --server-address sbm.example.com

Authorise the key from the SBM UI under Agents → Pending Authentications. The agent picks up the existing disk safe and continues incremental backups against it — no new full required. This is one of R1Soft's quiet wins versus tools that would treat the restored server as net-new.

FAQ

Next steps

• Verify your SBM is sized for restore I/O — BMR throughput is gated by the same random-read performance you size merges around
• Set up Disk Safe Replication so a failed primary SBM doesn't take your BMR capability down with it
• Compare R1Soft and JetBackup on disaster-recovery features if you're still picking a backup product for a new cPanel fleet