PBS Backup Host Outage: Evidence Checklist After a Kernel Update

Your Proxmox host keeps dropping dead during PBS backups after a kernel update — damn annoying. Before you start randomly rolling back kernels, grab the right evidence. Here’s exactly what to collect so you’re not guessing blind.

Check the kernel logs first

This is the most direct clue. The kernel ring buffer often catches the last gasp before a crash. Run:

journalctl -k -b -1

That shows kernel messages from the previous boot. Look for oops, panic, hung tasks, or anything about I/O errors near the time of the outage. If the host hard-locks without a trace, you might need to set up netconsole or a serial console to capture it live — but start here.

Grab the PBS task log

On the PBS server, check the backup task that ran when the host died:

proxmox-backup-manager task list --limit 20

Then get the full log for that task ID. It’ll show you how far the backup got — was it during the dirty-bitmap phase? Mid-transfer? That narrows down whether it’s I/O load, network, or something in the QEMU block layer.

Watch the system load during a backup

If you can reproduce it (and you probably can), run this on the Proxmox host while a backup kicks off:

dmesg -w &
vmstat 1 | tee /tmp/backup-stats.log

This dumps memory and I/O stats every second. If you see a spike in blocked processes (the ‘b’ column in vmstat) right before the outage, it’s likely an I/O stall — maybe a storage driver bug or a timeout in the kernel block layer.

Check for hardware or driver issues

New kernels sometimes break driver compatibility. Look at your hardware and driver messages:

lspci -k
dmesg | grep -i error

If you see AER (Advanced Error Reporting) or PCIe errors, that’s a smoking gun. Also check SMART data on the backup target disks — a failing drive can lock up the whole bus.

Compare kernel versions

Boot the previous kernel and see if the problem disappears. That’s the fastest test. To list installed kernels:

dpkg --list | grep pve-kernel

Then pin the working one in grub. If it’s stable, you’ve confirmed a kernel regression. Report it to the Proxmox forum with the evidence above — they’ll actually have something to work with.

My take

Don’t waste hours tweaking PBS settings or blaming network hiccups. This smells like a kernel I/O path issue, and the logs will tell you. If you’re seeing hangs during other heavy I/O, like when VM processes stall when rebooting an adjacent node, it might be the same root cause. Collect the data, isolate the kernel, and move on. This is a homelab — don’t let it eat your weekend.

If you’d rather pay for this

Proxmox Backup Server is free, and the checklist above is the price you pay for that: you are the one who notices, diagnoses and fixes it.

Two things are worth money here, and they are different things. A Proxmox subscription buys the enterprise repository — slower, more tested kernels — which is aimed squarely at the failure mode in this post, plus a support contact when it is 2am and the checklist has run out. It is priced per socket per year, in tiers. Separately, offsite storage buys you the case the checklist cannot help with, which is the backup host being gone rather than broken; object storage sits in the region of a handful of dollars per terabyte per month, which is close to nothing for a homelab-sized dataset. At the commercial end, Veeam and its competitors sell the orchestration and reporting around backups rather than the backups themselves.

The honest test is not what the subscription costs, it is what a failed restore costs. If the answer is “an evening”, keep doing this by hand. If the answer is anything with a client attached to it, buy the boring option.

This checklist is one of four write-ups on backups that look successful and protect nothing; the others are collected in Proxmox Backup & Recovery.