R1Soft Server Backup Manager sizing: storage, RAM, and disk I/O

R1Soft's official requirements page lists a minimum spec — 4 GB RAM, two cores, "sufficient disk" — that works for a lab and breaks the first time you point thirty agents at it. The Server Backup Manager (SBM) is a Tomcat application that does block-level deduplication, hourly merges, and policy scheduling on top of a Derby database. Each of those three workloads has its own bottleneck, and you have to size for all of them.

This guide gives you concrete numbers for storage, RAM, and disk I/O on a production hosting SBM, and ends with a worked example for a typical shared-hosting fleet running on a valid R1Soft license.

Storage — three layers, not one

Total disk on the SBM is the sum of three independent costs, not just "1 TB protected = 1 TB on the SBM".

Layer 1: deduplicated full. Block-level dedupe inside a disk safe typically reaches 1.0–1.2x of the source after the first full and a few merges, assuming standard cPanel content (mail, MySQL, PHP apps). Compress with zstd inside the disk safe (the default since SBM 6.16) and you can land at 0.85–1.0x for text-heavy workloads.

Layer 2: recovery point retention. Every recovery point is a sparse delta. For shared hosting with hourly schedules and 30-day retention, plan on 0.4–0.6x of the source as the retention overhead. Email-heavy workloads land higher; static-content servers lower.

Layer 3: merge headroom. R1Soft merges old recovery points into the base nightly. The merge process needs free space equal to the largest disk safe being merged — not the whole pool, but enough that running at 95% full will deadlock the policy with an out-of-space error.

Add them up: plan for 2.0–2.5x the source protected size. A fleet with 5 TB of source data needs 10–12 TB of usable SBM storage, not 5 TB.

RAM and Tomcat heap

R1Soft's installer sets the Tomcat heap to 1 GB. That is the right number for fewer than ten agents and wrong for everything else.

Rule of thumb for production:

• Heap: 1 GB per 10 agents, rounded up. 30 agents → 4 GB. 100 agents → 12 GB.
• System RAM: heap × 2.5. The OS page cache for the Derby database, kernel buffers, and reserved space for merge processes all live outside the JVM.

Set the heap in /usr/sbin/r1soft/conf/wrapper.conf:

wrapper.java.initmemory=4096
wrapper.java.maxmemory=4096
systemctl restart cdp-server

Set min and max to the same value. A growing JVM heap on a server doing constant disk I/O thrashes the page cache. Reserve the memory up front.

Disk I/O is the real bottleneck

Storage capacity is easy; sustained random IOPS during merge is what kills under-spec'd SBMs. R1Soft's merge is a block-level operation that walks every changed extent across every retained recovery point. On a 10 TB disk safe pool it can run for hours and saturates random write IOPS the entire time.

Concrete guidance:

• NVMe SSD pool: ideal. Even a single enterprise NVMe handles a fleet of 50+ agents without merge spilling into business hours.
• SATA SSD in RAID 10: acceptable up to ~30 agents. Avoid RAID 5/6 — write amplification on small random writes during merge is brutal.
• Spinning disk in RAID 10: workable only for cold archive tiers or fewer than ten agents. Plan on overnight merge windows and don't mix with the active recovery point store.
• Filesystem: XFS on a dedicated LVM volume. ext4 works but XFS handles the large sparse files in /var/lib/r1soft-data better at scale.

Mount the data volume noatime:

mount -o remount,noatime /var/lib/r1soft-data

Then update /etc/fstab so it persists.

Network — TCP/1167 and replication bandwidth

Each agent connects on TCP/1167 to push block data. Idle connections are trivial; an active backup pulls 50–300 Mbit/s per agent during the initial full and 5–20 Mbit/s during incrementals.

Sizing:

• Single 1 Gbit NIC: comfortable for 30 agents on staggered schedules. Saturates if you run more than five concurrent fulls.
• 10 Gbit NIC: required if you replicate to another SBM. Disk Safe Replication will saturate 1 Gbit during catch-up.

Set policy concurrency under Policy → Advanced → Maximum Concurrent Replicas to a number your NIC can sustain. The default of 10 is too high on a 1 Gbit link with a large fleet.

Topology — when to split

A single SBM scales to roughly 75–100 agents before the Derby database becomes the bottleneck — search and reporting queries against the recovery point catalogue get slow and the web UI starts timing out.

Above that, run multiple SBMs grouped by tenant or region. A common pattern for hosts:

• One SBM per shared-hosting node group (about 50 agents each)
• A dedicated SBM for high-value reseller accounts on hourly policies
• A replication target SBM in a second datacenter that pulls from all primaries

Compare this to JetBackup's per-server model in our R1Soft vs JetBackup comparison — the centralised SBM is the trade-off you're sizing around.

Worked example: 30 agents, 5 TB protected

A typical shared-hosting fleet on cPanel:

• 30 cPanel agents, average 170 GB each = 5.1 TB source
• Hourly policy, 30-day retention, daily merge
• Single primary SBM, no replication (yet)

Required spec:

A bare-metal box at this spec costs roughly the same as one extra hosting node — well inside the licensing budget for a fleet at this size. Pricing tiers and per-agent costs are covered on the R1Soft license page and our overview of hosting licence pricing.

Sanity checks after deployment

Two metrics to watch in the first week:

1. Merge duration. Settings → Server Backup → Reports → Policy History. If a daily merge runs past your scheduled backup window, you're storage-bound — add IOPS, not capacity.
2. Heap watermark. The dashboard heap chart should hover under 75%. Sustained above means raise the heap.

If merges spill into backup hours, agents queue, recovery point intervals slip, and customer-facing SLAs miss before any visible alert fires.

FAQ

Next steps

• Install the R1Soft agent on AlmaLinux once the SBM is sized and ready
• Set up Disk Safe Replication to a secondary SBM for offsite copies — and size the standby with the same math
• Fix R1Soft hcpdriver kernel module errors if agent installs fail to build the block driver