A useful Linux maintenance review is not a ritual of running updates and hoping the terminal stays quiet. It is a short, evidence-based check that answers three questions: can the system recover, is it exposed to avoidable risk, and is it behaving differently than expected?

This checklist is designed for a small production environment or a business-critical server. Adjust it for the distribution, hosting model, application, maintenance window, and risk tolerance. Record the commands used, the result, the person reviewing it, and any follow-up work. A checklist without evidence is only a memory aid.

1. Confirm ownership and recovery before changing anything

Start with the system owner, business purpose, support contact, maintenance window, and rollback method. Confirm that backups completed and that a recent restore has actually been tested. A successful backup job does not prove that the data, application, credentials, and configuration can be recovered together.

  • Identify the service owner and the applications running on the host.
  • Check the most recent backup result and retention policy.
  • Verify the date and outcome of the last restore test.
  • Document the rollback point before patching or configuration work.

CISA’s patch-management guidance recommends a verified backup or archive before production patching when a representative standby system is unavailable. That is a sound minimum for any change that could affect availability.

2. Review updates with context

Refresh package information, review available security updates, and note packages that are held, pinned, or supplied by third-party repositories. Do not treat every pending update as an emergency, but do not leave unexplained exceptions indefinitely.

sudo apt update
apt list --upgradable
systemctl status unattended-upgrades
test -f /run/reboot-required && cat /run/reboot-required.pkgs

Ubuntu documents that unattended-upgrades handles security updates by default, while third-party repositories require explicit configuration. Review its allowed origins and logs instead of assuming every installed package is covered.

3. Check capacity, filesystems, and resource trends

A system can be technically online while quietly running out of disk space, inodes, memory, or room for database growth. Compare today’s readings with a baseline so the review catches movement, not just hard failures.

df -h
df -i
free -h
uptime
systemctl --failed

Investigate unexpected growth in logs, uploads, container layers, package caches, database files, and temporary directories. Avoid deleting unfamiliar files simply to reclaim space; establish what created them and whether retention or rotation should change.

4. Review access and exposed services

Confirm that administrative accounts still have a business purpose, SSH keys belong to current users, and privileged access follows least privilege. Then compare listening services and firewall rules with the documented design.

ss -lntup
sudo ufw status verbose
last -a | head
sudo journalctl -p warning --since "30 days ago"

Unexpected listeners, repeated authentication failures, unfamiliar scheduled tasks, or a new privileged account deserve investigation. The objective is not to produce a long log export; it is to explain meaningful exceptions.

5. Test the application, not only the operating system

Check the service from the user’s point of view. Validate a representative login or transaction, certificate expiry, DNS resolution, queues, scheduled jobs, database health, monitoring alerts, and any external integration the application depends on. A green process list cannot prove the workflow is healthy.

6. Close the review with decisions

Record what changed, what was deliberately deferred, who owns each follow-up, and the date of the next review. Track exceptions until they are resolved or formally accepted. For a fleet, move beyond manual notes toward centralized inventory, patch reporting, configuration management, and alerting.

Monthly maintenance record

  • Backup and restore evidence reviewed
  • Security updates and reboot requirements reviewed
  • Disk, inode, memory, load, and failed services checked
  • Accounts, keys, listeners, firewall, and warnings reviewed
  • Application transaction and integrations tested
  • Changes, exceptions, owners, and next date documented

Sources

If the review reveals recurring blind spots, VesperTek can help turn them into a documented maintenance and reporting process that fits the business rather than a generic checklist.