R1Soft throttling: limit backup bandwidth, disk I/O, and CPU

The first complaint after rolling out R1Soft on a busy shared-hosting fleet is almost always the same: MySQL latency spikes, customer sites get slow, and the on-call engineer pins it to a recovery point that started at 14:00 against a noisy neighbour. Block-level CDP reads as fast as the disk subsystem will let it — which is exactly what you want for an off-hours full and exactly what you do not want at peak.

This guide covers the four throttles that actually matter on a production R1Soft deployment: schedule windows, per-server network caps, per-policy disk read limits, and OS-level process priority on the agent host. They stack, and most operators get away with only the first two.

Where R1Soft consumes resources

The agent has three moving parts and each one hits a different bottleneck.

• hcpdriver (kernel module). Traps block writes so the next recovery point only ships changed blocks. Negligible CPU, near-zero RAM, and you cannot throttle it directly — it sits in the block layer.
• buagent (user-space process). Reads dirty blocks off disk, compresses them (zstd by default since agent 6.16), and ships them to the Server Backup Manager. This is where almost all the cost lives: read I/O on the source disk, CPU for compression, and outbound network on the agent.
• Server Backup Manager (SBM). Receives blocks, deduplicates against the disk safe, and writes to storage. SBM-side bottlenecks are a separate problem — see SBM sizing if your backups slow down even when the agent has headroom.

Throttling is mostly about telling buagent to read less aggressively. Everything else follows from that.

Schedule windows — the first throttle

Before touching bandwidth or I/O caps, fix the schedule. A policy that runs hourly between 09:00 and 23:00 on a hosting server will hurt customers regardless of how well-tuned it is.

A sane default for a shared-hosting cPanel fleet:

• Full sweep: weekly, Sunday 02:00–06:00 local time.
• Hourly recovery points: every two hours between 22:00 and 08:00, then every six hours during the day.
• MySQL application-aware lock: only during the off-hours windows. The FLUSH TABLES WITH READ LOCK covered in application-aware backups blocks writes for milliseconds on a healthy server and seconds on a busy one.

In the SBM web UI, open the policy, go to the Schedule tab, and define separate hourly and daily entries with explicit start-hour and end-hour bounds. Avoid the "Continuous" preset on production hosting — it will queue a recovery point the moment the previous one finishes and effectively never lets the disk rest.

Network bandwidth caps per server

The per-server bandwidth throttle is the bluntest and most reliable knob. It applies to all policies protecting that agent and is enforced by the SBM regardless of how much the agent wants to push.

In the SBM, go to Servers, edit the protected server, and find Network Throttle under the Advanced section. The fields are:

• Maximum bandwidth (KB/s). Hard cap on inbound bandwidth from this agent.
• Throttle schedule. Time-of-day windows when the cap applies. Outside the window, the agent runs unthrottled.

A realistic shape for a 1 Gbps agent uplink shared with customer traffic:

• 08:00–22:00: cap at 10,000 KB/s (≈80 Mbit/s).
• 22:00–08:00: no cap.

This is the right place to enforce "backups must not eat more than half my uplink at peak". It will not protect the agent's disk subsystem from being read into the ground — that needs the next throttle.

Disk read throttling at the policy level

The policy itself has a read-rate limit that constrains how fast buagent will pull blocks off the source disk. Open the policy, go to Settings → Performance, and set:

• Maximum read rate (MB/s). A ceiling on how fast the agent reads from the protected volumes.
• Maximum concurrent disk reads. How many parallel read streams the agent will issue. On NVMe, four to eight is fine. On SATA SSD, two. On spinning disks, one.

For a busy cPanel server on a single NVMe drive, 100–200 MB/s during the day and unlimited at night is a sensible starting point. Measure baseline disk utilisation with iostat -xz 5 during a backup; if %util on the data disk sits above 70 % while customer sites are responsive, you have headroom. Above 90 % is where MySQL pidstat starts showing I/O wait.

Agent-side process priority

When the SBM-side throttles are not enough — typically because the agent is on a tiny VPS where even a moderate backup load competes with the customer's own MySQL — drop buagent to a lower scheduling priority on the agent itself.

# Lower CPU priority (nice +10) and I/O priority (best-effort, lowest)
systemctl edit cdp-agent

Add:

[Service]
Nice=10
IOSchedulingClass=best-effort
IOSchedulingPriority=7

Then reload and restart:

systemctl daemon-reload
systemctl restart cdp-agent

This guarantees that any process with a lower nice value — MySQL, PHP-FPM, the Exim queue runner — preempts the backup agent under contention. It does not slow backups when the system is idle, which is exactly the behaviour you want.

The hcpdriver kernel module runs in interrupt context and cannot be reniced; it does not need to be, since its overhead is constant regardless of policy activity.

Verifying the throttle is working

Three quick checks:

# Network: confirm the agent is hitting the cap, not exceeding it
iftop -i eth0 -f "port 1167"

# Disk: confirm read MB/s on the source volume is below your policy cap
iostat -xz 5

# Process: confirm buagent is actually reniced
ps -o pid,ni,cls,pri,cmd -C buagent

If buagent shows NI 0 after editing the systemd unit, the override did not apply — check systemctl cat cdp-agent for the effective config and confirm you reloaded the daemon. If iostat shows the source disk pinned at 100 % even with the read-rate cap configured, the cap is probably set on the wrong policy — verify by opening Settings → Performance on the exact policy that owns the running recovery point.

FAQ

Next steps

• Right-size the receiving end with R1Soft Server Backup Manager sizing.
• Tighten database-consistent snapshots in R1Soft MySQL application-aware backups.
• Plan off-site copies without compounding your throttling problem in Disk Safe and Site-to-Site Replication.