Moving ZFS scrubs off the first Sunday

On Debian the zfsutils-linux package ships a cron job that scrubs every pool on the second Sunday of the month. My offsite backup also runs on Sunday night, and so does the monthly SMART long test. Three disk-heavy jobs on one night, on four spinning drives, is how you end up with a scrub that takes eleven hours instead of five.

What was happening

zpool status during the overlap showed the scrub crawling along at a fraction of its normal rate, and the backup job's log had timeouts I'd been ignoring for months.

  scan: scrub in progress since Sun Sep 14 00:24:01 2026
        4.71T / 13.2T scanned at 118M/s, 3.02T / 13.2T issued at 76.4M/s
        0B repaired, 22.87% done, 1 days 14:06:51 to go

The fix

I disabled the packaged job and wrote two systemd timers instead, so each pool gets its own night and nothing lands on Sunday.

# /etc/systemd/system/zfs-scrub@.timer
[Unit]
Description=Monthly scrub of ZFS pool %i

[Timer]
OnCalendar=*-*-08 02:00
RandomizedDelaySec=1h
Persistent=true

[Install]
WantedBy=timers.target

# /etc/systemd/system/zfs-scrub@.service
[Unit]
Description=Scrub ZFS pool %i

[Service]
Type=oneshot
ExecStart=/usr/sbin/zpool scrub -w %i

The -w flag makes zpool scrub wait until the scrub finishes, so the unit's runtime in systemctl list-timers actually means something.

systemctl enable --now zfs-scrub@tank.timer

Result

The October scrub finished in 5h12m with no errors, and the backup ran clean the following Sunday. The SMART long tests now run on the 20th. Boring, which is the goal.