A server that is running looks like a server that does not need attention. That is the most expensive illusion in a company’s IT. Most serious failures we deal with did not start suddenly: they were announced by a filling disk, repeating warnings in the logs, or a backup that had been “successful” for months but from which nobody had tried to restore anything.
A monthly check is the minimum rhythm at which such signals can be noticed in time. It does not matter whether the server sits in your office closet or runs in the cloud: the questions are the same, only who is responsible for the physical part changes.
Below is the checklist we use ourselves. It works both as an internal checklist and as a way to verify what your current provider actually does.
Updates and security
1. Operating system and application updates
Check that all security updates are installed, that the server was restarted afterward and that no patches are pending. A common mistake is that updates are downloaded but not installed, because someone postponed the restart “to next weekend” six months ago. Check not only Windows or Linux but also the applications running on the server: database engines, accounting systems, remote access tools.
2. Antivirus and endpoint protection
Make sure the protection agent is running, its signatures are up to date and the management console sees the server as active. Review last month’s detections: even if they were blocked, repeated attempts show where the threat is coming from. On the servers we manage we use Bitdefender GravityZone, but the principle holds for any solution: protection without review is only a licence.
3. Access review
Pull a list of all accounts that have access to the server: local, domain, remote desktop, VPN. Check whether it includes former employees, former suppliers or “temporary” accounts created a year ago. Only those who really need administrator rights this month should have them. This is one of the first checks an auditor asks about under NIS2 or DORA requirements.
Data and recovery
4. Backup restore test
Not “is the backup successful” but “can we restore from it”. Every month restore at least one file, folder or database to a separate location and check that the data opens. Once a quarter it is worth restoring a whole virtual machine in a test environment and measuring how long it takes. That time is your real recovery time, not the one written in the plan. If backups are kept only on the same network, consider immutable backups that are invisible from the network. They are the only ones that survive ransomware attacks, which look for backups first and destroy them.
5. Disk space and its trend
The free space figure today matters less than how it is changing. If a disk filled by a few percent in a month, calculate when it will be full and plan now. The most common causes: growing logs, temporary files, old backups on the local disk, and database transaction logs that nobody truncates.
6. Database maintenance
A database is a separate system with its own needs. Check index fragmentation, statistics updates, transaction log size and whether the database’s own backup jobs are running. An accounting or warehouse system that has “started to slow down” usually has a database problem, not a server problem. If this keeps recurring, a separate database maintenance agreement is worth considering.
Signals the server sends on its own
7. System and application logs
Review the error and warning logs for the whole month, not just the last day. Look for repeating entries: failed logins from one address, disk read errors, services that restarted several times a night. One entry is a coincidence; twenty identical ones are a future failure or an attack in progress.
8. Monitoring system and its alerts
Check that monitoring still watches what it should: all servers, all services, all disks. New disks and virtual machines often end up outside monitoring. Review which alerts were ignored during the month. If one fires every day and nobody reacts, either change the threshold or fix the cause. Ignored monitoring is worse than none, because it creates a feeling of security.
9. Performance metrics
Compare processor, memory and disk load with last month. Slowdown is gradual and employees get used to it, until one day the accounting report takes an hour to generate. A monthly trend lets you plan to add resources before, not after.
Physical environment and external dependencies
10. Temperature, UPS and hardware health
If the server is on your premises, check the room temperature, the condition of the fans and the hardware management interface warnings about disks, power supplies or memory. Uninterruptible power supply (UPS) batteries age silently: check the self-test result and how many minutes it would really hold. A battery that held twenty minutes three years ago may hold two today. In the cloud this part is the provider’s job, but it is worth knowing how it is organised.
11. Certificates and domains
List all the SSL/TLS certificates the server uses: website, email, VPN, remote desktop gateway, internal applications. Check expiry dates and whether automatic renewal works. An expired certificate stops a service just like a failure does, but it is the easiest to predict. Add domain and licence expiry dates to the same list.
12. Documentation and change log
Write down what changed on the server this month: updates installed, settings changed, new accounts, replaced hardware. It takes ten minutes, and half a year from now, when something stops working, it will be the only way to know where to start. Documentation is also what almost every security audit asks for.
How to organise it so it really happens
A checklist changes nothing if it stays in an article. In our experience three things work.
First, a fixed date. For example, the first Tuesday of the month is server day. Not “when there is time”, because there is never time.
Second, a responsible person and a signed checklist. Not so that someone can be blamed, but so that it is clear what has been done. If an external provider does it, ask for a monthly report with the same twelve points.
Third, automation where possible. Disk space, certificate expiry, backup status and log anomalies can be checked automatically every day, leaving a person to review the results and run the restore tests. This is how our server management works: monitoring tells us before it tells you, and the monthly check becomes a report, not firefighting.
Where to start
- Pull out this list and mark which items were checked in your company last month. If fewer than half, that is your baseline, not a reproach.
- Start with item four: this week restore one file from a backup. If it fails, everything else can wait.
- Review access and disconnect everything that is no longer needed. It takes an hour and is the biggest security win for the lowest cost.
- Set a server day and a responsible person. If there is nobody in the company for this, consider external server management that includes all twelve items.
- After three months, compare: how many warnings were noticed before they became failures.
A server that someone looks over every month rarely fails unexpectedly. And if it does fail, there is something to restore from.
