Taming My Daily Backup Script’s CPU Spikes with `nice` and `ionice`

Why CPU Spikes Hurt Your Backup

Running a nightly backup with rsync or tar is a staple of any homelab or self‑hosted server. Even if the backup finishes in a few minutes, a sudden burst of CPU usage can push the system into a state where interactive work stalls, background services lag, or even the backup itself stalls due to contention. On a machine that also hosts a web server or a desktop, those spikes become noticeable. The good news is that Linux gives you two lightweight knobs—nice and ionice—to dial the priority of a process without touching the kernel or installing extra software.

nice adjusts the niceness value of a process, a number from ‑20 (highest priority) to 19 (lowest). The default is 0. A higher niceness means the scheduler will give the process less CPU time relative to others.

nice -n 10 rsync -a /data /mnt/backup

Dynamic Priority Adjustment

If you want to keep the backup running but let it yield more aggressively when the system is busy, you can combine nice with cpulimit. cpulimit caps the CPU usage of a process to a percentage, but it’s an extra tool. For most cases, a static niceness of 10–15 is enough.

nice -n 15 rsync -a /data /mnt/backup

A niceness of 15 is a common sweet spot: the backup still completes in a reasonable time, but the interactive shell and GUI apps stay responsive.

ionice: Taming Disk I/O

While nice deals with CPU, ionice handles block‑device I/O priority. The I/O scheduler in the kernel (cf. the CFS scheduler for CPU) can be tuned per‑process. ionice offers three classes:

Class	Description	Typical Use
`-c 0` (Realtime)	Highest priority, no throttling	Rarely needed; use only for critical tasks
`-c 1` (Best‑Effort)	Default class	Most backups
`-c 2` (Idle)	Runs only when the disk is idle	Good for nightly backups on busy servers

ionice -c 2 -n 7 rsync -a /data /mnt/backup

The -n parameter is only meaningful for the Best‑Effort class; for Idle it’s ignored. Setting the class to Idle tells the kernel to postpone the I/O until the disk is otherwise unused, which is ideal for a nightly job that can wait a few minutes.

Choosing the Right Class

Realtime – Use only if you’re backing up a critical system that must finish before the next boot. It can starve other processes.
Best‑Effort – Default; good if you want a balance between speed and fairness.
Idle – Best for a background job that can tolerate a delay. On a busy server, the job may finish later in the night.

Combining nice and ionice

The two tools are orthogonal, so you can stack them:

nice -n 15 ionice -c 2 rsync -a /data /mnt/backup

This command tells the scheduler: give this process low CPU priority and only use the disk when idle. In practice, the backup will run slower but will not interfere with day‑to‑day use.

Practical Script Example

Below is a minimal backup script that incorporates both nice and ionice. It also logs progress and exits cleanly if the target is unreachable.

#!/usr/bin/env bash
set -euo pipefail

SRC="/data"
DST="/mnt/backup"
LOG="/var/log/backup.log"

# Ensure destination is mounted
if ! mountpoint -q "$DST"; then
    echo "$(date '+%F %T') - Destination $DST not mounted" | tee -a "$LOG"
    exit 1
fi

# Run rsync with low priority
nice -n 15 ionice -c 2 rsync -a --delete --info=progress2 "$SRC/" "$DST/" >>"$LOG" 2>&1

Monitoring with `top` and `iotop`

After launching the script, you can verify that the process is indeed low‑priority:

top -p $(pgrep -f rsync)

You should see a high PRI value (e.g., 15) and a low CPU%. For I/O, iotop shows the process in the Idle class:

sudo iotop -o

The IO column will be minimal, and the process will only appear when the disk is idle.

Trade‑offs and Caveats

When nice is Insufficient

If the backup still spikes the CPU, it may be because the algorithm (e.g., rsync’s delta transfer) is inherently CPU‑heavy. In that case, consider:

Splitting the backup into smaller chunks (e.g., per‑directory).
Using rsync’s --compress flag to reduce data size, at the cost of CPU.

Potential Race Conditions

Running nice and ionice does not guarantee that the backup will finish at a predictable time. If the system is under heavy load, the job may be delayed indefinitely. For mission‑critical backups, schedule them during known low‑traffic windows or use a dedicated backup machine.

Security Implications

Lowering priority does not expose the system to new vulnerabilities. However, if the backup destination is a network share, ensure that the mount uses

linux open-source