The second-most-common R1Soft pager event, right after a full disk safe, is a Server Backup Manager that pegs all of its CPU cores and starves the Derby database at 02:05 every night. Every policy in the fleet was created with the default schedule — "Every 1 day at 02:00" — and the moment the clock ticks over, fifty agents start streaming changed-block deltas into the same Tomcat process. The SBM survives, but recovery points run for hours, the web UI times out, and the next morning's first restore request lands on a manager that is still digging itself out.
This guide is the orchestration layer that sits on top of per-agent throttling and SBM sizing. Throttling caps how hard any one policy hits its source server. Sizing tells you how much SBM hardware you need. Concurrency and stagger decide how many of those policies run at once and at what minute past the hour — which on a 50-agent fleet is the difference between a four-hour backup window and a fourteen-hour one.
How SBM schedules work
Server Backup Manager treats every policy as an independent job with three temporal controls.
- Schedule — when the policy is eligible to run. Daily at 02:00, hourly, every 15 minutes, or a cron expression.
- Backup window — the time range within which a queued policy is allowed to start. A policy whose schedule fires at 02:00 with a window of 22:00–06:00 will start immediately; the same policy at 07:00 will wait until 22:00.
- Priority — where the policy sits in the queue when more want to run than the SBM permits.
When a policy's scheduled time arrives, SBM does not start the backup directly. It places the policy on the task queue, and a separate dispatcher picks the next task off the queue whenever a slot is free. The number of slots is the Maximum Concurrent Tasks setting, configured globally on the SBM under Configuration → Options → Backup. Every policy in the fleet shares the same pool.
The trap is that the default value — typically 4 on a fresh install, depending on SBM version — was chosen for a single-host evaluation, not a production fleet. Leave it at 4 and a 50-agent fleet processes in waves of 4, which is too few to finish overnight. Push it to 50 and the SBM disk subsystem collapses under concurrent random I/O.
Set Maximum Concurrent Tasks for your hardware
Concurrency on the SBM is bounded by disk I/O first, then RAM, then CPU. Each running task does two things at once: it receives a stream of changed blocks from the agent, and it writes deltas into the disk safe while reading the parent recovery point's block index. That is a mixed random-read / random-write workload, and the ceiling is set by the storage tier on the SBM.
A defensible starting point, then tune:
| SBM storage tier | Starting concurrent tasks | Notes |
|---|---|---|
| SATA HDD RAID 10 | 4–6 | Random I/O is the wall; do not push past 8 |
| SAS HDD RAID 10 | 8–12 | Acceptable for medium fleets |
| SATA SSD RAID 10 | 16–24 | RAM and Tomcat heap become the next limit |
| NVMe RAID 1 / 10 | 24–48 | Now CPU-bound; size Tomcat heap accordingly |
Each concurrent task holds roughly 200–400 MB of Tomcat heap once block index caching is warm. If you raise Maximum Concurrent Tasks above 16, raise the Tomcat heap (-Xmx in /etc/init.d/cdp-server or the systemd drop-in) by the same proportion — otherwise the SBM will start full GC pauses mid-backup and policies will retry. The sizing guide has the full RAM table.
Stagger policy start times
Even with concurrency tuned, leaving every policy on "Daily at 02:00" wastes the queue. SBM cannot start the 5th task until one of the first 4 finishes — if all four take 90 minutes, the next four don't begin until 03:30, and the 50th doesn't begin until well after sunrise.
Stagger flattens the curve. Two patterns work in production.
Pattern A — block stagger. Sort policies into groups equal to your concurrent task count. Set group 1 to 22:00, group 2 to 22:05, group 3 to 22:10, and so on. The queue is kept full but never piles up. Good for fleets where backup duration per agent is consistent (e.g. all shared-hosting cPanel boxes).
Pattern B — random offset within window. Set the schedule to "Daily" with a backup window of 22:00–06:00 and use a script to assign each policy a random start minute inside the window. SBM's task queue then sees a smooth arrival rate. Easier to maintain because adding a new agent does not require rebalancing groups. Best when agent backup durations vary widely (e.g. mixed shared + reseller + VPS workloads).
To bulk-edit start times without clicking through fifty policies, use the SBM REST API. The endpoint PUT /apiv1/policies/{id} accepts the schedule object and is the only practical way to stagger more than ten agents.
Use the backup window as a hard stop
The schedule says when to start. The backup window says when starting is still allowed. Set both.
A policy with backup window 22:00–06:00 that gets queued at 05:55 will start, run until it finishes (possibly past 06:00 — the window gates starts, not running tasks), and then no further runs of that policy start until 22:00 the next day. This is the correct behaviour: it prevents a backlog from spilling into business hours and tipping the SBM over during peak customer traffic.
If a policy misses its window entirely because the queue was full, SBM logs a POLICY_SKIPPED event and waits for the next window. Monitor these — a fleet that skips more than ~2 % of scheduled runs per week is undersized on concurrency or undertight on stagger.
Priority for the policies that must run
Give your top-revenue or contractually-protected agents Priority High. Everything else stays Normal. Reserve Low for policies you would happily skip if the SBM is saturated — typically dev and staging boxes that share the production SBM.
Priority only affects queue ordering. A High-priority policy does not pre-empt a running Normal task, and it does not exceed Maximum Concurrent Tasks. It only jumps the queue when a slot opens up. That is usually enough — but if you have a customer with an SLA, a dedicated SBM is more honest than relying on priority alone.
Monitor the queue, not the dashboard
The SBM dashboard shows currently running tasks. It does not show queue depth, which is the metric you actually want.
Poll the API every minute during the window and graph the result:
curl -sk -u admin:password \
"https://sbm.example.com:8443/apiv1/tasks?statuses=QUEUED&limit=1000" \
| jq '.results | length'
If queue depth grows monotonically through the window and never reaches zero before the window closes, you are oversubscribed — either raise Maximum Concurrent Tasks (if storage I/O has headroom) or split the fleet across a second SBM. The R1Soft licensing model is per-agent, so adding a second manager only costs hardware.
Worked example: 50 cPanel agents on one SBM
- Hardware: 16 vCPU, 64 GB RAM, NVMe RAID 10 for disk safes.
- Maximum Concurrent Tasks: 20.
- Tomcat heap:
-Xmx24g. - Backup window: 22:00–06:00 (8 hours).
- Stagger: random offset within 22:00–02:00 (4-hour arrival window).
- Per-agent average backup duration: 35 minutes.
Total job-minutes per night: 50 × 35 = 1,750. Available slot-minutes: 20 × 480 = 9,600. Utilisation: 18 %. The fleet finishes well before the window closes, queue depth never exceeds 10, and the morning restore request hits a quiet SBM.
If the fleet grows to 200 agents on the same hardware, utilisation hits 73 % — still survivable but with no headroom for a slow agent. Plan the second SBM before you reach that point. For sizing the replacement, see SBM sizing for production fleets; for the wider cost comparison against alternatives, R1Soft vs JetBackup covers the maths.
Next steps
- R1Soft throttling: bandwidth, disk I/O, and CPU — what to set per-policy once stagger is right.
- R1Soft retention and recovery point cleanup — the other reason your SBM melts at 02:00.
- R1Soft Server Backup Manager sizing — hardware budget before you raise concurrency.