The Complete Linux Server Maintenance Checklist

Linux servers have a well-earned reputation for reliability, but reliable doesn't mean maintenance-free.

A production server is constantly changing. Security updates are released. Log files grow. Databases become larger. Certificates expire. User accounts change. Applications are updated. Storage fills up. Traffic increases. Backups fail. Software eventually reaches the end of its supported lifecycle.

Without regular maintenance, small issues can accumulate until they become performance problems, security risks, or unexpected downtime.

At AcuNett, we've been administering Linux servers for more than 25 years. We've learned that the best server maintenance is usually preventative. It's much easier to address a filesystem that is approaching capacity than one that has already reached 100%, and it's much better to discover a failed backup during a routine review than during a disaster recovery attempt.

This Linux server maintenance checklist covers the areas we recommend reviewing on an ongoing, monthly, quarterly, and annual basis.

Linux Server Maintenance at a Glance

A good server maintenance program should cover several major areas:

• Operating system updates
• Security
• Server monitoring
• Disk and filesystem health
• CPU and memory utilization
• Backups
• Web and database services
• User access
• SSL certificates
• Logs
• Application software
• Performance
• Capacity planning
• Operating system lifecycle

Not every task needs to be performed manually or on the same schedule. Many checks should be automated, while others benefit from periodic review by an experienced Linux administrator.

Ongoing Linux Server Maintenance

Some aspects of server maintenance shouldn't wait for a monthly checklist.

Critical infrastructure should be monitored continuously so administrators can identify important problems as they develop.

Monitor Server Availability

Production servers should have external monitoring that verifies they're reachable.

For web servers, this should ideally include HTTP or HTTPS checks rather than relying only on ping.

A server can respond to network traffic while the web server or application itself is unavailable.

Monitor Critical Services

The services required by the server's workload should be monitored individually.

Depending on the environment, these may include:

• Apache
• NGINX
• LiteSpeed
• PHP-FPM
• MySQL
• MariaDB
• PostgreSQL
• DNS
• SMTP
• IMAP
• Application-specific processes

If a critical service stops, the administrator should know before customers begin reporting the problem.

Monitor CPU and System Load

CPU utilization and system load can provide early warning of resource problems.

Temporary increases may be completely normal, but sustained or unexpected changes should be investigated.

High load can result from:

• Traffic increases
• Database activity
• PHP processes
• Backup jobs
• Disk I/O
• Scheduled tasks
• Runaway processes
• Malicious traffic

Monitoring should focus on changes from the server's normal behavior rather than relying entirely on a single universal threshold.

Monitor Memory and Swap

Linux intentionally uses available memory for caching, so high memory utilization isn't automatically a problem.

Administrators should monitor available memory, application consumption, swap utilization, and trends over time.

Increasing swap activity or repeated memory exhaustion may indicate that an application needs tuning or the server requires additional resources.

Monitor Disk Space

Disk utilization should be monitored continuously.

A full filesystem can cause databases, websites, email, logging, and other services to fail.

Storage can disappear quickly because of:

• Growing log files
• Database growth
• Website uploads
• Email
• Temporary files
• Backups stored locally
• Application-generated data

Alerts should provide enough warning for administrators to investigate before the filesystem reaches a critical level.

Monitor Inode Usage

Linux filesystems can run out of inodes even when storage capacity remains available.

This is particularly relevant for servers containing extremely large numbers of small files, such as cache files, session files, or email messages.

When a filesystem exhausts its available inodes, applications may be unable to create new files.

Monitor Backups

Every scheduled backup should be monitored for successful completion.

A backup system can fail silently while the production server continues operating normally.

At a minimum, you should know:

• Whether the backup ran
• Whether it completed successfully
• When the last successful backup occurred
• Whether offsite copies were created
• Whether backup storage has sufficient capacity

Monitor SSL Certificate Expiration

SSL certificate renewal is commonly automated, but automation can fail.

Monitoring certificate expiration provides time to correct DNS, validation, configuration, or renewal problems before visitors receive certificate warnings.

Monthly Linux Server Maintenance Checklist

Monthly maintenance provides an opportunity to review the server beyond the immediate alerts generated by monitoring systems.

1. Review Operating System Updates

Check for available operating system and security updates.

Depending on the distribution, this may include updates for:

• Linux kernel
• System libraries
• SSH
• Web server software
• Database software
• PHP
• Security tools
• System utilities

Important security updates should generally be handled promptly rather than waiting for a monthly review, but the monthly maintenance cycle is a good opportunity to confirm that routine patch management is working properly.

2. Determine Whether a Reboot Is Required

Some updates, particularly kernel and low-level system updates, may require a reboot before the server is fully running the updated software.

A server can sometimes appear completely patched while still running an older kernel loaded before the update.

Administrators should determine whether a reboot is required and schedule it appropriately for production systems.

3. Review Disk Usage

Look beyond current free space and review how disk utilization has changed.

Ask:

• Which filesystems are growing?
• How quickly are they growing?
• Are databases consuming significantly more storage?
• Are logs being rotated correctly?
• Are temporary files accumulating?
• Are old backups consuming production storage?

Trend data is often more useful than the current percentage alone.

4. Review System Resource Usage

Examine CPU, memory, swap, system load, and disk I/O trends from the previous month.

Look for recurring spikes or gradual increases.

If resource usage is growing consistently, investigate before the server reaches its limits.

5. Review Backup History

Don't simply confirm that today's backup succeeded.

Review backup history for recurring failures, unusually small backups, unusually large backups, incomplete jobs, or storage problems.

Unexpected changes in backup size can sometimes reveal an underlying problem worth investigating.

6. Check Backup Storage Capacity

Backup repositories also have finite storage.

Verify that retention policies are working and sufficient capacity remains for future backups.

Running out of backup storage can cause future jobs to fail even while production storage has plenty of free space.

7. Review Important Logs

Server logs can reveal recurring problems that haven't yet caused a major outage.

Depending on the server, review relevant:

• System logs
• Authentication logs
• Web server error logs
• Database logs
• Firewall logs
• Application logs

The objective isn't necessarily to manually read every line. Look for recurring errors, unusual events, and patterns that deserve investigation.

8. Review Failed Login Activity

Internet-facing servers routinely receive automated login attempts.

Review authentication activity for unusual patterns involving:

• SSH
• Control panels
• Email accounts
• Application administration

Repeated failures are common, but unusual changes may indicate a targeted attack, compromised credentials, or ineffective brute-force protection.

9. Review Firewall Activity

Check firewall and security tools for unusual activity.

Look for significant changes in blocked connections, repeated attacks, or services receiving unexpected traffic.

10. Check Critical Website and Application Functionality

Monitoring may confirm that a website returns a successful HTTP response, but that doesn't guarantee every important function works.

For business-critical applications, periodically verify functionality such as:

• Login systems
• Contact forms
• Checkout processes
• Search
• File uploads
• API integrations
• Scheduled tasks

11. Review Database Health

For database-driven servers, review the database environment for signs of developing problems.

This may include:

• Database size
• Slow queries
• Connection utilization
• Resource consumption
• Replication status where applicable
• Database errors

Database requirements often increase gradually as applications accumulate data.

12. Review Control Panel Updates

If the server runs cPanel & WHM, Plesk, DirectAdmin, Webmin/Virtualmin, or another control panel, verify that the platform is current and updating correctly.

Control panels interact with many critical server services and should be included in regular maintenance.

Quarterly Linux Server Maintenance Checklist

Quarterly maintenance should take a broader look at security, access, configuration, and capacity.

1. Review User Accounts

Review accounts with access to the server.

This may include:

• Linux users
• SSH users
• Sudo privileges
• Control panel administrators
• FTP and SFTP accounts
• Database users
• Application administrators

Remove accounts belonging to employees, contractors, developers, or vendors who no longer require access.

2. Review SSH Access

Verify that SSH access remains appropriately restricted.

Review:

• Authorized SSH keys
• Users permitted to connect
• Root login policy
• Authentication methods
• IP restrictions where appropriate

Old SSH keys should be removed when they're no longer needed.

3. Review Administrative Privileges

Check which users have sudo or other elevated permissions.

Administrative access should follow the principle of least privilege: users should have only the access required to perform their responsibilities.

4. Review Firewall Rules

Firewall configurations tend to accumulate rules over time.

A port may have been opened temporarily for a migration or vendor integration and never closed afterward.

Quarterly reviews should ask:

• Which ports are publicly accessible?
• Are they still required?
• Are IP-based exceptions still valid?
• Are there old or duplicate rules?
• Are administrative services more exposed than necessary?

5. Review Listening Services

Identify services listening for network connections and confirm that each one is expected.

If software is no longer needed, disabling or removing it reduces the server's attack surface and maintenance requirements.

6. Review Software Versions

Inventory important software and verify that it remains supported.

This can include:

• PHP
• MySQL or MariaDB
• PostgreSQL
• Apache
• NGINX
• LiteSpeed
• Control panels
• Application runtimes

Software can continue functioning long after it stops receiving security updates, so operational status alone isn't enough.

7. Review Website and Application Software

If the server hosts WordPress, Joomla, or other applications, review their maintenance status too.

Check:

• Core application versions
• Plugins and extensions
• Themes and templates
• Third-party libraries
• Unsupported components

A fully patched Linux server can still be compromised through an outdated web application.

8. Test a Backup Restore

A successful backup report tells you that the backup process completed. It doesn't guarantee that the data can be restored correctly.

Periodically perform a test restore.

Depending on the environment, this may involve restoring:

• Individual files
• A database
• A website
• A hosting account
• An entire server environment

Restore testing can reveal missing data, incomplete configurations, corrupted backups, or procedures that don't work the way everyone assumed they would.

9. Review Backup Retention

Confirm that the backup retention policy still meets business requirements.

A business may discover that keeping only a few days of backups is insufficient when a problem goes unnoticed for several weeks.

Consider whether you need:

• Daily backups
• Weekly retention
• Monthly retention
• Long-term archives

10. Verify Offsite Backups

At least one backup copy should generally exist outside the production server.

If the server experiences catastrophic hardware failure, filesystem corruption, compromise, or another major incident, a backup stored only on the same machine may not provide meaningful protection.

11. Review SSL Certificates

Check certificates across websites, administrative interfaces, mail services, and other encrypted services.

Confirm:

• Certificates are valid
• Renewal automation is working
• Certificate chains are correct
• Required hostnames are covered
• Deprecated TLS settings aren't unnecessarily enabled

12. Review Server Performance

Compare current performance with previous periods.

Has CPU utilization increased?

Is the database consuming more memory?

Are backup jobs taking longer?

Has disk I/O increased?

Are applications responding more slowly?

Gradual performance changes are easier to address before they become severe.

13. Review Capacity

Estimate whether current resources will remain adequate for the next several months.

Consider:

• CPU
• Memory
• Storage
• Database growth
• Backup storage
• Network utilization

Capacity planning allows upgrades to be scheduled instead of performed during an emergency.

Annual Linux Server Maintenance Checklist

Annual maintenance is an opportunity to step back from day-to-day operations and evaluate whether the server's overall architecture still makes sense.

1. Review the Linux Operating System Lifecycle

Determine how long the current Linux distribution and version will continue receiving security updates.

Whether you're running AlmaLinux, Rocky Linux, Ubuntu, Debian, RHEL, or another distribution, every release eventually reaches end of life.

If the server is approaching the end of its supported lifecycle, begin planning the upgrade or migration well in advance.

2. Review the Complete Software Stack

Evaluate the lifecycle of major software components.

This may include:

• Linux distribution
• PHP versions
• Database servers
• Web servers
• Control panels
• Programming runtimes
• Business applications

Several components reaching end of life around the same time may make a larger migration more practical than upgrading each piece individually.

3. Perform a Security Review

Review the overall server hardening configuration.

Consider:

• Firewall configuration
• SSH security
• User access
• Administrative privileges
• Running services
• File permissions
• Authentication policies
• Security monitoring
• Brute-force protection

A server that was properly hardened several years ago may have changed significantly since its original deployment.

4. Review Disaster Recovery Procedures

Backups are only one part of disaster recovery.

Consider what would happen if the entire production server disappeared today.

Do you know:

• Where the backups are stored?
• How to access them?
• How to provision replacement infrastructure?
• Which DNS changes would be required?
• Which applications need to be restored first?
• Which credentials and licenses are required?
• Who is responsible for each part of recovery?

Documenting these answers before an emergency can significantly reduce recovery time.

5. Review Monitoring Coverage

Applications and infrastructure change over time, but monitoring configurations don't always change with them.

Review whether all current critical services are being monitored.

A new application may have been deployed six months ago without anyone adding its background processes or API endpoint to the monitoring platform.

6. Review Server Documentation

Update documentation for:

• Server purpose
• Operating system
• Applications
• Network configuration
• Firewall rules
• Backup locations
• Monitoring
• Administrative access
• Important dependencies
• Third-party services

Documentation is particularly valuable when the administrator who originally built the server isn't available during an incident.

7. Review Whether the Server Is Still Properly Sized

The server you needed three years ago may not be the server you need today.

Business growth may justify additional resources, while application changes may mean you're paying for capacity that is no longer necessary.

Review actual historical utilization rather than assuming the current configuration is still appropriate.

8. Review the Hosting Architecture

Consider whether the current architecture still meets the business's reliability and performance requirements.

Questions might include:

• Should shared hosting move to a VPS?
• Has a VPS workload grown enough to justify dedicated infrastructure?
• Should applications and databases be separated?
• Does the environment need additional redundancy?
• Would newer infrastructure improve performance?
• Is the server still located appropriately for its users?

Infrastructure shouldn't be changed simply because something newer exists, but it should be periodically evaluated against current requirements.

Linux Server Maintenance Checklist Summary

Ongoing

• Monitor uptime and availability
• Monitor critical services
• Monitor CPU and system load
• Monitor memory and swap
• Monitor disk space and inodes
• Monitor backup jobs
• Monitor SSL certificate expiration
• Respond to critical alerts

Monthly

• Review operating system updates
• Check whether a reboot is required
• Review disk growth
• Review resource utilization trends
• Review backup history
• Check backup storage capacity
• Review important logs
• Review authentication activity
• Review firewall activity
• Check critical application functionality
• Review database health
• Verify control panel updates

Quarterly

• Review user accounts
• Review SSH access and keys
• Review administrative privileges
• Review firewall rules
• Review listening services
• Review software versions
• Review website and application software
• Perform a test restore
• Review backup retention
• Verify offsite backups
• Review SSL/TLS configuration
• Review server performance
• Review capacity requirements

Annually

• Review the Linux operating system lifecycle
• Review the complete software stack
• Perform a broader security review
• Review disaster recovery procedures
• Review monitoring coverage
• Update server documentation
• Review server sizing
• Review the overall hosting architecture

Maintenance Should Be Based on the Server

This checklist provides a strong starting point, but there is no universal maintenance schedule that fits every Linux server.

A small web server has different requirements from a large database server. A cPanel hosting server running hundreds of websites requires different maintenance from a dedicated application server. Infrastructure supporting financial transactions may require more frequent reviews than a development environment.

The maintenance schedule should reflect:

• The server's purpose
• The applications it runs
• The importance of the data
• Traffic and workload
• Security requirements
• Acceptable downtime
• Recovery requirements

Automate What Makes Sense

A good maintenance strategy doesn't require an administrator to manually inspect every server metric every morning.

Many tasks can and should be automated.

Automation can handle:

• Availability checks
• Resource monitoring
• Disk alerts
• Backup jobs
• Backup failure notifications
• SSL expiration alerts
• Log rotation
• Security notifications

Automation provides consistency and makes it easier to manage larger environments.

But automation doesn't eliminate the need for administration. Someone still needs to review the results, investigate abnormal behavior, plan changes, and make decisions when the automated systems report a problem.

Don't Turn Maintenance into a Checkbox Exercise

The purpose of server maintenance isn't simply to complete a checklist.

The checklist is there to help administrators notice changes.

If disk utilization increased 20% since the previous review, the important task isn't checking the "disk space" box. It's determining why the increase occurred and whether it will create a future problem.

If backups technically completed but their size suddenly dropped by 80%, that deserves investigation.

If CPU utilization has steadily increased for six months, capacity planning may be necessary even though the server hasn't generated an alert yet.

Good server maintenance requires interpreting what the data means.

Preventative Maintenance Is Easier Than Emergency Recovery

Many Linux server emergencies begin as small, manageable problems.

A filesystem slowly fills up. A certificate renewal begins failing. A database grows beyond its original configuration. An old administrator account remains active. A backup job stops running. An operating system approaches end of life.

Regular maintenance gives administrators opportunities to address those issues before they affect the business.

After more than 25 years of Linux server administration, we've found that some of the most successful maintenance work is the work customers never notice.

The disk didn't fill up. The certificate didn't expire. The unsupported operating system was migrated before security updates ended. The failed backup was corrected before anyone needed it.

Nothing dramatic happened because the problem was handled early.

Ongoing Linux Server Maintenance from AcuNett

At AcuNett, Linux server administration has been at the center of our business for more than 25 years.

We help businesses maintain Linux servers running websites, applications, databases, hosting platforms, and other critical infrastructure.

Our Linux server management services can include operating system maintenance, security updates, server hardening, monitoring, backup management, performance troubleshooting, software lifecycle management, and ongoing administrative support.

Whether you're maintaining a single VPS, a dedicated server, a cPanel hosting environment, or a larger Linux infrastructure, AcuNett can help keep the systems your business depends on secure, monitored, backed up, and properly maintained.