Updated October 2026 for AlmaLinux 9, Debian 12 and Ubuntu 24.04 (dnf and apt).
Most Linux server outages aren’t exotic. A disk fills up, a drive dies in an array nobody was watching, or a kernel update sat uninstalled for six months. This checklist covers the routine Linux server maintenance that prevents those, with the commands for AlmaLinux/Rocky 9 (dnf) and Debian 12/Ubuntu 24.04 (apt).
Linux server maintenance checklist
1. Apply updates, and know when you need a reboot
Patching comes first. Subscribe to your distribution’s security announcements so you hear about the big ones, and don’t wait for them to install the small ones.
On AlmaLinux or Rocky 9:
dnf check-update
dnf updateinfo list updates security # pending security fixes only
dnf upgrade # everything
dnf upgrade --security # security fixes onlyOn Debian 12 or Ubuntu 24.04:
apt update
apt list --upgradable
apt upgradeFor hands-off security patching, Ubuntu already ships unattended-upgrades and applies security updates automatically. On Debian, install it with apt install unattended-upgrades and turn it on with dpkg-reconfigure -plow unattended-upgrades. On the RHEL family, install dnf-automatic, set upgrade_type = security in /etc/dnf/automatic.conf, and run systemctl enable --now dnf-automatic-install.timer.
Updates aren’t finished until the new code is actually running. A patched kernel or glibc does nothing for you while the old one is still loaded. Check:
# AlmaLinux/Rocky: exit code 1 means a reboot is needed
dnf needs-restarting -r
# Debian/Ubuntu: check the running kernel, list services to restart
needrestart -k
needrestart -r l
ls /var/run/reboot-required # Ubuntu creates this when a reboot is dueUbuntu ships needrestart in its server images and runs it after every apt transaction. On Debian 12 you’ll need to apt install needrestart. Neither Ubuntu’s automatic updates nor dnf-automatic reboots for you by default, so put a reboot window on the calendar. Monthly works for most single servers.
2. Watch disk space and inodes
A full filesystem is still one of the most common causes of downtime. Treat 80% used as a warning and 90% as an emergency, and remember you can run out of inodes with free space left over.
df -h # space per filesystem
df -i # inodes per filesystem
du -xh --max-depth=1 / | sort -h # what's eating the root filesystem
lsof +L1 # deleted files still held open by a processThat last one catches a classic: someone deletes a huge log, but the process writing to it still holds the file open, so df doesn’t budge until you restart that service.
3. Keep logs rotated, and read them
Two systems handle logs on a modern distro. Plain files in /var/log are rotated by logrotate, configured in /etc/logrotate.conf and /etc/logrotate.d/. Anything that writes its own log files (an app, a custom daemon) needs its own entry there, or it’ll grow until the disk fills. Test a config without changing anything:
logrotate -d /etc/logrotate.confThe systemd journal is the other one. See how much space it takes and trim it:
journalctl --disk-usage
journalctl --vacuum-time=30dThen actually read them. Errors since the last boot and OOM-killer events are the two worth a regular look:
journalctl -p err -b
journalctl -k | grep -i -E 'out of memory|oom'4. Check RAID and drive health
A degraded array works fine right up until the second disk goes. Software RAID (mdadm) is easy to check:
cat /proc/mdstat
mdadm --detail /dev/md0Hardware RAID needs the controller vendor’s tool: storcli for Broadcom/LSI cards (it replaced MegaCLI), arcconf for Adaptec/Microchip, perccli on Dell PERC. Check the vendor’s docs for your exact model.
For the drives themselves, smartmontools reads SATA, SAS and NVMe health data:
smartctl -H /dev/sda # quick pass/fail
smartctl -a /dev/sda # full attributes
smartctl -a /dev/nvme0 # NVMeReallocated, pending and uncorrectable sector counts that keep climbing mean the drive is on its way out. On NVMe, watch “Percentage Used” and “Media and Data Integrity Errors”. Enable smartd so you get warned instead of having to remember to look. The smartmontools documentation covers the options.
5. Verify backups by restoring them
A backup job that reports success is not a backup. Restore something on a schedule: a single file monthly, a full database or server into a test environment every quarter. Check that the restored data is current, not from the day the job silently started failing. If you’d rather run backups off-site, Veeam Cloud Connect backups are one option.
6. Monitor, so the server tells you first
Everything above is a manual check. Monitoring turns it into an alert. At minimum, watch disk usage, load, memory and swap, RAID state, the services you care about, and whether the website itself answers. Prometheus with node_exporter, Zabbix and Netdata are all common choices; pick one and make sure alerts reach a phone as well as an inbox.
7. Check out-of-band access before you need it
IPMI, iLO and iDRAC give you a remote console when SSH is gone, after a bad firewall rule or a kernel that won’t boot. Log in once in a while to confirm it works and the password is current. The BMC’s event log also records hardware trouble that never makes it into syslog:
ipmitool sel listMemory errors, overheating and power supply faults show up there. Any of them deserves a quick response.
8. Review who has access
People leave, contractors finish, keys stay behind. Every few months, go through the accounts with a login shell in /etc/passwd, each user’s ~/.ssh/authorized_keys, and /etc/sudoers plus /etc/sudoers.d/. Remove what shouldn’t be there.
9. Use SSH keys, not passwords
Use key-based SSH and set PasswordAuthentication no in your sshd configuration once you’ve confirmed your key works. Any password you keep for sudo, the BMC or a control panel should be long and random, generated by a password manager or with a diceware-style passphrase.
Don’t have the time or staff for this? Our fully managed dedicated servers include OS updates and security patches on request, monitoring of load, RAID, swap, services and website uptime, and troubleshooting and server administration.
