{"id":3452,"date":"2026-09-29T19:10:26","date_gmt":"2026-09-29T19:10:26","guid":{"rendered":"https:\/\/www.ucartz.com\/blog\/server-maintenance-checklist\/"},"modified":"2026-09-30T05:40:36","modified_gmt":"2026-09-30T05:40:36","slug":"server-maintenance-checklist","status":"publish","type":"post","link":"https:\/\/www.ucartz.com\/blog\/server-maintenance-checklist\/","title":{"rendered":"Server Maintenance Checklist: Daily, Weekly, Monthly and Yearly"},"content":{"rendered":"\n

Short answer:<\/strong> server maintenance is the routine work that keeps a server secure, fast and recoverable: applying updates, watching disks and logs, proving that backups can be restored, and reviewing who has access. A simple rhythm works for most Linux servers: quick health checks every day (automate them), updates and a log review every week, a restore test and access review every month, and a bigger review of hardware, operating-system support and disaster recovery once a year. We checked the commands below on Ubuntu 24.04 and AlmaLinux 9; they also work on Debian and Rocky Linux unless a note says otherwise.<\/p>\n\n\n\n

\"Terminal
Quick checks from the checklist: uptime, disk space, pending updates and whether a reboot is needed.<\/figcaption><\/figure>\n\n\n\n

Daily: is everything healthy?<\/h2>\n\n\n\n

These checks take a minute by hand, but the real goal is to have monitoring alert you, so you only log in when something is wrong.<\/p>\n\n\n\n

uptime                      # load averages and time since the last boot\nsystemctl --failed          # services that have crashed or failed to start\ndf -h                       # free disk space per filesystem\ndf -i                       # free inodes (a disk can be \"full\" with space left)\nfree -h                     # memory and swap in use\njournalctl -p err -b --no-pager | tail -n 20   # latest errors since boot<\/code><\/pre>\n\n\n\n
On a healthy server, systemctl --failed<\/code> prints 0 loaded units listed.<\/code> Also confirm that last night’s backup job finished: check its log or the date of the newest backup file. A backup that stopped weeks ago without anyone noticing is a bad thing to discover in an emergency.<\/p>\n\n\n\n
Weekly: updates, disks and logs<\/h2>\n\n\n\n
Install updates<\/h3>\n\n\n\n
On Ubuntu and Debian:<\/p>\n\n\n\n
sudo apt update\napt list --upgradable\nsudo apt upgrade<\/code><\/pre>\n\n\n\n
On AlmaLinux and Rocky Linux:<\/p>\n\n\n\n
sudo dnf check-update\nsudo dnf upgrade<\/code><\/pre>\n\n\n\n
Security updates should not wait for the weekly slot, so let the server install them itself. According to Ubuntu’s documentation<\/a>, the unattended-upgrades package is installed by default and is switched on by two lines in \/etc\/apt\/apt.conf.d\/20auto-upgrades<\/code>. On our Ubuntu 24.04 test system the file contained:<\/p>\n\n\n\n
APT::Periodic::Update-Package-Lists \"1\";\nAPT::Periodic::Unattended-Upgrade \"1\";<\/code><\/pre>\n\n\n\n
On AlmaLinux and Rocky Linux, install dnf-automatic<\/a> and enable the timer that downloads and installs updates:<\/p>\n\n\n\n
sudo dnf install dnf-automatic\nsudo systemctl enable --now dnf-automatic-install.timer\nsystemctl list-timers 'dnf-automatic*'<\/code><\/pre>\n\n\n\n
For more detail, see how to set up automatic updates on Linux<\/a>.<\/p>\n\n\n\n
Check whether a restart is needed<\/h3>\n\n\n\n
Updated libraries and kernels only take effect after a service restart or a reboot. On Ubuntu, the file \/var\/run\/reboot-required<\/code> exists when a reboot is needed. On Ubuntu and Debian, needrestart<\/code> lists services still running old code (-r l<\/code> means list only, restart nothing):<\/p>\n\n\n\n
ls \/var\/run\/reboot-required\nsudo needrestart -r l<\/code><\/pre>\n\n\n\n
On AlmaLinux and Rocky Linux:<\/p>\n\n\n\n
sudo dnf needs-restarting -r<\/code><\/pre>\n\n\n\n
When nothing is pending it prints No core libraries or services have been updated since boot-up.<\/code> and Reboot should not be necessary.<\/code> Plan reboots for a quiet hour and tell your users.<\/p>\n\n\n\n
Check disk health and RAID (dedicated servers)<\/h3>\n\n\n\n
sudo smartctl -H \/dev\/sda      # SATA or SAS disk\nsudo smartctl -H \/dev\/nvme0    # NVMe drive\ncat \/proc\/mdstat               # software RAID status\nsudo mdadm --detail \/dev\/md0   # details of one array<\/code><\/pre>\n\n\n\n
These are for physical disks, so run them on a dedicated server. The options come from the smartctl<\/a> and mdadm<\/a> manuals. A failing health result, or an array that reports a missing or failed disk, needs action now, not next week. Our guides show how to use smartctl<\/a> and how to let smartd watch the disks for you<\/a>.<\/p>\n\n\n\n
Review logs and logins<\/h3>\n\n\n\n
journalctl --disk-usage             # space used by the systemd journal\nsudo journalctl --vacuum-size=500M  # trim it if it has grown too big\nlast -n 20                          # recent logins\nsudo lastb -n 20                    # recent failed logins<\/code><\/pre>\n\n\n\n
Logins you do not recognise are worth investigating straight away. Make sure application logs are rotated too; see log rotation with logrotate<\/a>.<\/p>\n\n\n\n
Monthly: restores, access and exposure<\/h2>\n\n\n\n