PBS Replication: Throttle, Schedule & Pause Guide

When PBS replicates your backups to a remote server, an offsite copy can easily saturate your link and stall the very VMs you're trying to protect. PBS 4.2 gives you sync controls—bandwidth throttling, off-peak scheduling, and schedule management—so that replication slips into a quiet window instead of fighting your daily workload. Here's how to pause, throttle, and queue replication jobs without eating bandwidth or disrupting running VMs.

Key Takeaways

• Throttle — A bandwidth limit caps replication throughput so a large job never starves your live VMs.
• Schedule — Cron windows push the offsite copy to quiet hours where the link is otherwise idle.
• Pause — Disabling or narrowing a schedule stops future runs on demand, with no hot-pause for an active transfer.
• Manage — The Replication tab and pbs-replicator let you watch status, prune old data, and re-run on demand.

What PBS sync controls actually do

PBS replication copies your backup data from a local PBS server to a remote one, so a lost rack or a fire still leaves you an offsite copy. Unlike a one-time file copy, replication is incremental and idempotent—only new or changed chunks travel across the wire, and re-running a job is safe because already-transferred chunks are skipped. That makes it a natural fit for nightly offsite copies, but it also means a replication job can run for a long time and consume real bandwidth.

The three controls map to real problems

The controls map onto the issues you'll actually hit in a busy homelab:

• Bandwidth throttling keeps a replication job from grabbing the whole link.
• Scheduling confines the job to a window when the link is otherwise idle.
• Schedule management lets you pause, resume, or re-run without hand-editing any config files.

These controls live in the Replication tab of the PBS web UI—the one PBS 4.0 rebuilt from the ground up—and through the pbs-replicator command, so you can drive them either way. Your replication is only as useful as the snapshots behind it, so if retention and snapshot cleanup still feel fuzzy, read up on snapshot management for backups before you tune the network side of things.

How to throttle replication so it stops hogging bandwidth

The most immediate control is a bandwidth limit. PBS applies it per replication job, measured in KB/s, whether you set it in the UI or on the command line.

Command line

On the server itself, pass --bwlimit to pbs-replicator:

pbs-replicator --all --bwlimit 10000

This replicates every VM at 10,000 KB/s, roughly 10 MB/s. To target a single guest instead of everything, scope it with --vmid:

pbs-replicator --vmid 100 --bwlimit 5000

In the web UI

Open the Replication tab, edit the replication job, and enter a bandwidth limit in the schedule settings. Same effect, no SSH required.

A bandwidth limit only affects the network path between the two PBS servers—it doesn't touch local disk writes on either side. Your VMs keep reading and writing to their local storage at full speed, which is why throttling replication rarely disrupts them the way a full unthrottled sync can.

Here's the gotcha that catches most people out: the very first replication of any VM is always a full transfer, not an incremental one. If you run that first job against a 200 GB VM on a 1 Gbps link, expect roughly 30 to 45 minutes of throughput regardless of your --bwlimit—you're moving the whole dataset once. After that, daily reps usually move only a few hundred megabytes, and the bandwidth limit is what keeps those small jobs from bumping into a video call or a busy backup window.

How to schedule offsite replication into quiet hours

Throttling shares the link; scheduling avoids it entirely. PBS schedules use standard five-field cron expressions, and you set them in the replication job's schedule tab.

A few realistic windows for a homelab:

Schedule	Cron expression	Runs
Nightly at 3:15 AM	15 3 * * *	Every night
Weekly backup Sunday 2 AM	0 2 * * 0	Every Sunday
Weekday nights only	0 22 * * 1-5	Mon–Fri evenings

Pair the schedule with a bandwidth limit and you get a job that starts in a quiet window and stays gentle even if something else wakes up. If your offsite strategy already includes cloud storage, replication to a second PBS box pairs nicely with an S3 tier for defense in depth—but that's a separate job from local-to-local replication, so keep the two schedules independent.

The honest tradeoff here is timing: a narrower window or a harder throttle means the copy finishes later. If you cap bandwidth too aggressively or shrink the window too much, a large job may not complete before the next scheduled run starts, and you'll begin the next cycle on stale data. Pick a window that's comfortably longer than your worst-case sync time.

How to pause and resume a replication schedule

PBS doesn't ship a hot-pause button that interrupts a transfer already in flight. What it does give you is schedule control, which covers the cases where you realistically need to pause:

• Maintenance or a downed link — disable the schedule so no job starts while you're working.
• A busy day — narrow the cron window so the job only runs overnight, effectively pausing it during business hours.
• Resuming — re-enable the schedule or widen the window again; the next run picks up where it left off because replication is incremental.

In the Replication tab, disabling a schedule is just toggling it off. There's no way to freeze a job mid-transfer, so if you need to stop a transfer immediately, let it finish the current run and disable the schedule for the next one. That's a limitation worth knowing before you rely on "pause" during an incident.

How to manage and monitor replication jobs

The Replication tab is your dashboard: it shows each job, its last run time, how much data transferred, and whether it succeeded. Use it to spot a job that's failing or taking longer than usual.

The Replication tab

Watch for a job that suddenly transfers far more data than usual—that usually means the previous run didn't finish and had to catch up, often a sign your window is too short. A failed run is easier to catch here than in any log file, and you can trigger a manual re-run straight from the tab.

On the command line

pbs-replicator gives you finer control. You can scope a run to a node, a storage, or a single snapshot, and you can prune old retained data at the same time:

pbs-replicator --node web01 --prune '--keep-daily 7 --keep-weekly 4'

The --prune string mirrors the retention rules you'd set elsewhere—keep the last seven daily and four weekly snapshots on the remote side. Pruning during replication keeps the remote datastore from growing without a second pass.

If you have a large fleet, running one big replication job can be slower than a handful of smaller ones. Parallel sync jobs can shrink your backup window considerably, so if you're juggling dozens of guests it's worth pairing a bandwidth limit with a few targeted jobs rather than one giant --all.

Which control matches your workload

Rather than reach for every control at once, match the tool to the problem:

Goal	Control	Where you set it
Cap throughput on a shared link	Bandwidth limit	Scheduler field or --bwlimit
Run only in a chosen window	Cron schedule	Replication tab
Stop future runs entirely	Disable schedule	Replication tab toggle
Replicate on demand	Manual run	Replication tab or pbs-replicator

Bandwidth limit and schedule usually work together: schedule the job for 2 AM and cap it at 10 MB/s so it never hurts anything. Reach for disabling the schedule only when you genuinely need to halt replication, like during a link swap or a remote-site outage.

Conclusion

PBS 4.2's sync controls let you throttle, schedule, and pause replication so offsite backups fit a quiet window instead of fighting your live VMs. Set a bandwidth limit, confine the job to an off-peak cron window, and watch it from the Replication tab. Your next step: pick one replication job, add a --bwlimit, and schedule it for 2 AM to see how much headroom you actually have.