Uptime, Backups and Monitoring: Server Administration That Holds Up
Server administration is judged entirely by absence. When it is done well, nothing happens — no outages, no data loss, no 3am phone calls. That makes it easy to underfund, right up until the morning a database is gone and the most recent backup is from March.
This is what the work actually consists of, and where it usually fails.
Backups: The Only Test That Counts Is a Restore
Every business has backups. Far fewer have backups that have been restored. The gap between those two states is where most catastrophic data loss lives.
A backup you have never restored is a hypothesis, not a safeguard. We have seen backups running nightly for two years that turned out to contain an empty directory, because a path changed during a migration and nobody checked.
The standard worth holding to is the 3-2-1 rule: three copies of the data, on two different media types, with one copy off-site. For a typical business server that means the live data, a local snapshot for fast recovery, and an off-site copy for disaster recovery.
Two numbers decide the design:
- Recovery Point Objective — how much data you can afford to lose. Nightly backups mean up to 24 hours of work gone.
- Recovery Time Objective — how long you can afford to be offline. Restoring 500 GB from an off-site archive over a modest connection can take most of a day.
Both should be written down and agreed before an incident, not discovered during one. And both should be verified by an actual restore, on a schedule, to a separate environment.
Monitoring: Catch It Before the Customer Does
The purpose of monitoring is not to record that something broke. It is to give you enough warning to act before anyone notices.
The layers worth having:
| Layer | What it watches | Warns you about |
|---|---|---|
| External uptime | Is the site reachable from outside | Total outages, DNS and certificate failures |
| Resource | CPU, memory, disk, I/O | Trends toward exhaustion, days ahead |
| Application | Error rates, response times, queue depth | Degradation before it becomes an outage |
| Certificate | TLS expiry dates | Expiry, weeks in advance |
| Backup | Did the job run and produce a plausible file | Silently failing backups |
Disk space deserves special mention. It is the single most common cause of avoidable outages, it always gives warning, and the warning is trivially easy to act on. A disk filling at a steady rate tells you a week in advance. An alert at 80 percent turns an emergency into a scheduled task.
Certificate expiry is the second. Automated renewal exists and works, yet expired certificates still take sites offline regularly because renewal was configured once and never monitored.
Alert Fatigue Is a Real Failure Mode
A monitoring system that sends forty notifications a day trains people to ignore it. When the important one arrives, it is in the same pile as thirty-nine routine ones.
The discipline is to alert only on things a human must act on now. Everything else belongs on a dashboard to be reviewed, not pushed. If an alert fires and the correct response is “yes, that happens”, either fix the underlying cause or stop alerting on it.
Updates: The Balance Nobody Gets Perfectly Right
Apply security patches immediately and you risk breaking something. Delay them and you risk being compromised. Both failure modes are real.
The approach that works in practice separates the two categories. Security patches for the operating system and exposed services go on automatically, promptly, because the exposure window matters more than the small risk of disruption. Application and framework updates go through a staging environment first, on a regular schedule — monthly for most businesses.
What is not acceptable is the third option, which is what we find most often: updates applied when someone remembers, which in practice means during an incident.
Security Basics That Prevent Most Incidents
Sophisticated attacks exist. They are not what compromises most business servers. The mundane measures cover the overwhelming majority:
- SSH keys only, no password authentication. This single change eliminates brute-force entirely.
- A firewall that denies by default. Open only the ports that must be open.
- Automatic banning of repeated failures. Cheap, effective, standard.
- Separate accounts per service. A compromised application should not own the machine.
- Logs shipped off the server. Logs stored only locally are the first thing an intruder edits.
- Documented, tested recovery. Knowing how to rebuild from backup is part of security, not separate from it.
Documentation Is Part of the Infrastructure
The most dangerous server in any organisation is the one only one person understands. When that person is unavailable — holiday, illness, a new job — the business discovers how much undocumented knowledge it was relying on.
The minimum: what runs where, how to access it, where backups live and how to restore them, who the providers are and how to reach them, and what to do when the common failures occur. A single document, kept current, is worth more than an elegant setup nobody else can operate.
What Goes Wrong Most Often
From the incidents we are called into, ranked by frequency:
- Disk full — always preventable, always with warning
- Certificate expired — automated renewal that stopped working unnoticed
- Backup that had been failing silently for weeks
- An update applied without testing, at the worst possible time
- A compromise through an outdated application component
- DNS change made without checking propagation or TTL
Not one of these is exotic. Every one is prevented by monitoring and routine. That is the entire job.
Frequently Asked Questions
How often should backups run?
Frequently enough that the maximum data loss is acceptable. For a site updated daily, nightly is fine. For a system taking orders continuously, hourly or continuous replication. The business decides by answering how much work it can afford to redo.
Is managed hosting enough on its own?
It covers the infrastructure layer well. It does not cover your application, your data or your configuration. Managed hosting backups are usually for their disaster recovery, not yours — verify you can restore a single file from a specific date before relying on it.
How much monitoring is enough for a small business?
External uptime checks, disk and memory alerts, certificate expiry warnings, and confirmation that backups completed. That covers most real incidents and costs very little.
Should updates be fully automatic?
Security patches for the OS and exposed services, yes. Application and framework versions, no — those go through staging. The distinction matters because the risk profiles are different.
What is a realistic uptime target?
99.9 percent allows about 43 minutes of downtime a month and is achievable with good practice on a single well-run server. Higher targets require redundancy, which multiplies cost. Pick the number the business actually needs.
Who should have root access?
As few people as possible, each with their own key, and every action logged. Shared root credentials make it impossible to know who did what, which matters most exactly when something has gone wrong.
The Bottom Line
Good server administration is routine performed consistently. Backups tested rather than assumed. Monitoring that warns rather than reports. Updates on a schedule rather than in a panic. Documentation that lets someone else take over.
None of it is difficult. All of it is easy to defer, and the cost of deferring only becomes visible on the day it matters.
Our server administration and IT maintenance services cover exactly this ground, including the restore tests most setups never get. For standards and reference, the CIS Benchmarks remain the most practical hardening guidance available.