The Monthly Ten Minutes That Keep a Linux Machine From Ever Surprising You

Every Linux machine that fails dramatically has been failing quietly for a month first. The disk that died had been reporting reallocated sectors since August. The boot partition had been filling since the last three kernel updates. The backup job that reported success every night had been writing empty archives since a path changed.

None of that is exotic. All of it is visible in ten minutes a month, provided you look.

Why a ritual beats a reminder

Ad-hoc maintenance happens when something already hurts. A monthly checkup, run on the same day each month, catches drift while it is still cheap to correct. The commands below are safe on a small-office server and on a home desktop, and none of them require downtime.

Take a snapshot first. On btrfs or ZFS a read-only snapshot costs nothing. On ext4, a Timeshift snapshot or a fresh restic run to external storage takes a minute and turns every mistake below from an incident into an inconvenience.

Step 1: Read the journal like a suspicious person

Do not scroll. Filter.

journalctl --since '30 days ago' -p err --no-pager | tail -n 40
journalctl --since '30 days ago' -p warning -g 'fail|error|timeout' --no-pager | tail -n 60
systemctl --failed
systemctl --user --failed

The first two surface errors you have been ignoring. The second pair names any unit that gave up. A failed unit is not always urgent, but a failed unit you cannot explain is a thread worth pulling.

While you are here, confirm the journal is not eating the disk:

journalctl --disk-usage
sudo journalctl --vacuum-size=1G

Step 2: Audit what the kernel left behind

A full /boot is one of the most common reasons a machine suddenly will not boot after an update. List what is installed and remove what is not needed.

Debian and Ubuntu:

sudo apt autoremove --purge
dpkg -l | awk '/^rc/ {print $2}'

Fedora and RHEL:

sudo dnf autoremove
sudo dnf repoquery --installonly --latest-limit=-1

Arch:

pacman -Qtdq | sudo pacman -Rns -
sudo paccache -rk2

Keep the running kernel and one previous. Check df -h /boot afterward, and confirm your package manager's install-only limit reflects your intent rather than the distribution's default.

Step 3: Look at the disks, not the desktop widget

SMART attributes are the closest thing to a warning before failure.

sudo smartctl -H /dev/nvme0
sudo smartctl -A /dev/nvme0 | grep -Ei 'available_spare|percentage_used|media_errors|critical'
sudo smartctl -t short /dev/nvme0

On NVMe, watch Percentage Used and Available Spare. On SATA, watch Reallocated_Sector_Ct and the pending sector count. Any nonzero pending sector is a reason to verify your backup tonight rather than next month. Then check capacity and inodes, because a filesystem can have free space and still be full of inodes:

df -h
df -i

For btrfs, run a scrub monthly. For mdadm RAID, trigger a check and read the mismatch count instead of assuming the array is healthy because it reports as clean.

Step 4: Restore something

A backup job that reports success is a claim, not evidence. Once a month, prove it.

restic snapshots --last 3
restic check --read-data-subset=5%
restic restore latest --target /tmp/restore-test --include /etc/ssh

Then open a file from the restored tree and read it. Borg users can substitute borg check --verify-data and a borg extract of a single path. rsync-based setups get rsync -avn --delete against the destination plus a manual comparison of two directories. Remove the test restore afterward; a test you never clean up is just a slow disk.

Step 5: Patch, firmware included

sudo fwupdmgr refresh --force
sudo fwupdmgr get-updates

Firmware updates carry fixes for NVMe controllers, docks, and batteries that no kernel update will ever touch. Then apply pending system updates and check whether anything is waiting on a restart:

sudo dnf needs-restarting -r
test -f /var/run/reboot-required && cat /var/run/reboot-required

Long uptime is not a virtue. Kernel and libc updates only take effect when you actually restart.

The printable checklist

• Snapshot or backup taken before starting
• Errors from the last 30 days reviewed
• Failed systemd units explained or cleared
• Journal size under 1 GB
• Old kernels pruned; /boot under 50 percent
• SMART attributes read; no pending sectors
• df -h and df -i both comfortable
• btrfs scrub or RAID check scheduled
• One file restored from backup and opened
• Firmware updates applied
• System packages updated
• Restart requirement checked

Twelve items. Most months, ten of them pass silently.

When the checkup finds something

Write it down before you fix it. Half the value of a monthly routine is the record it produces: the sector count that held steady for six months before it moved, the unit that failed the week after a config change. Correct the problem, but keep the note, because next month's checkup starts by comparing against it.

The goal is not a pristine system. It is a boring one, where the failures you do have are small, expected, and already documented.