R1Soft (now ConnectWise Server Backup Manager) has been the default block-level backup for cPanel hosts for over a decade, but a lot of operators are moving off it — backups that crept from two hours to six, block scans that run past 24 hours, and database restores that fail on modern MariaDB. JetBackup 5 runs as a cPanel plugin, gives customers self-service restores, and pushes incrementals to S3-compatible storage without a separate Java agent and SBM box.
This guide is for hosts running a cPanel fleet on R1Soft who want to cut over to JetBackup cleanly. The hard rule of this migration: backup history does not transfer. You run both systems in parallel until JetBackup has built enough recovery points to satisfy your retention promise, then decommission R1Soft. Plan for weeks, not an afternoon.
What actually transfers (and what doesn't)
R1Soft and JetBackup are architecturally different, so almost nothing copies across. Be honest with yourself about this before you start.
| Item | Transfers? | Notes |
|---|---|---|
| Disk safe history / recovery points | No | R1Soft disk safes are a proprietary block format. You start JetBackup at recovery point zero. |
| Backup schedules | No | Rebuild as JetBackup backup jobs. Different model. |
| Retention policy | No (re-author) | JetBackup uses keep-N-of-each rules; map your old policy by hand. |
| Storage destinations | No (re-add) | Re-add S3/Wasabi/B2/SSH targets in JetBackup. |
| The data being protected | N/A | It's the same live servers — JetBackup just reads them fresh. |
The practical consequence: until JetBackup has run for as many days as your longest retention tier, R1Soft is still your only source of old restore points. Don't pull the agent early.
Step 1: Stand up JetBackup storage first
JetBackup writes incrementals to a destination, so the destination has to exist before any job runs. Don't reuse the R1Soft SBM volume — keep that intact for restores.
Provision fresh storage and add it as a destination in JetBackup. For most hosts an S3-compatible bucket is the cheapest durable option; see the Wasabi destination setup for the exact bucket, key, and endpoint config, or the full destinations guide if you're going local-disk or SSH instead. If your compliance story needs write-once storage, configure immutable backups with object lock now — it's far easier to set on an empty bucket than to retrofit.
Step 2: Install the JetBackup plugin on each server
JetBackup installs per cPanel server, not as a central manager. On each box:
bash <(curl -LSs https://repo.jetbackup.com/install.sh)
This adds the JetBackup repo, installs the plugin, and registers it in WHM under Plugins → JetBackup 5. Apply your license — if you bought a tiered license from us, activation is keyed to the server's primary IP. Confirm the plugin loads in WHM before going further.
Step 3: Build backup jobs and retention
In the JetBackup plugin, create a backup job pointing at your destination. For a cPanel
host the standard shape is an accounts backup job covering all cPanel accounts, plus optional
config/directory jobs for /etc and custom paths R1Soft was catching.
Map your old R1Soft retention to JetBackup's keep-rules. R1Soft thought in "recovery points to keep"; JetBackup thinks in "keep N daily, N weekly, N monthly". A common 30-day policy becomes something like keep 7 daily + 4 weekly + 2 monthly. The retention policies guide walks the exact mapping and the storage-cost math, which changes a lot versus R1Soft's single block store.
Stagger job start times across the fleet so you don't hammer the destination at 02:00 on every server at once.
Step 4: Run both systems in parallel
This is the whole migration. Leave R1Soft running its normal schedule. Let JetBackup build recovery points alongside it. The first JetBackup run is a full backup and reads every account from scratch — on a dense shared server that initial pass can take several days per server before incrementals kick in and runs drop to minutes. Watch the destination fill and confirm jobs complete green for a full week.
During parallel run, your restore source-of-truth is still R1Soft for anything older than your JetBackup start date. Tell your support team explicitly which dates live where.
Step 5: Validate restores before you trust it
A backup you haven't restored is a hypothesis. Before declaring JetBackup primary, prove all three restore paths:
- Single file — restore one file into an account and diff it. See restore a single file.
- Single database — restore a MySQL/MariaDB database and confirm it imports clean. This is the exact thing R1Soft was failing at, so test it deliberately.
- Full account — restore an entire cPanel account to a scratch server.
Also confirm the customer-facing restore: the JetBackup section should appear in each user's cPanel, letting them self-serve file and database restores. That self-service path is the biggest day-to-day win over R1Soft and the thing that cuts your restore tickets.
Step 6: Cut over and decommission R1Soft
Once every server has run JetBackup green for at least one full retention cycle and you've validated restores:
- Make JetBackup the documented primary in your runbooks and support macros.
- Stop the R1Soft backup schedule (but keep the SBM server online, read-only).
- After one more full retention cycle with no R1Soft restores needed, archive or destroy the disk safes and reclaim the SBM server.
Only now do you stop paying for R1Soft. If you want the side-by-side feature breakdown to justify the switch internally, the R1Soft vs JetBackup comparison covers it, and the JetBackup license tiers explain how per-server pricing nets out against R1Soft's per-server agent fees. Volume migrations across a fleet — talk to us about staged licensing so you're not double-paying during the parallel-run window.