Server Management

Someone whose job it is to watch them

Servers rarely fail dramatically. They fill a disk. They miss a backup. They run an unpatched service for eight months because the person who knew about it changed jobs. Management is mostly the discipline of noticing these things while they are still boring.

We take over the running of servers you already have — ours or someone else's — and make that discipline somebody's actual responsibility.

What we take on

• Monitoring: availability, disk headroom, memory pressure, certificate expiry, and whether last night's backup actually finished.
• Patching on a schedule, with changes recorded rather than applied quietly at 2am.
• Backup verification. A backup nobody has restored is not a backup, it is a hope with a filename.
• Hardening: firewall rules reviewed, access list reviewed, services nobody uses any more switched off.
• Log review for the patterns that precede an outage rather than the ones that follow it.
• A person to call, who has the inventory in front of them when you do.

Backups: the part everyone assumes is fine

The widely used baseline is the 3-2-1 rule: three copies of the data, on two different types of media, with one copy off-site. It exists to remove single points of failure — a failed disk costs you one copy, a fire or a ransomware event costs you the copies in the same building.

Two numbers make the rule operational. RPO (recovery point objective) is how much data you can afford to lose, measured in time between backups. RTO (recovery time objective) is how long you can afford the restore to take. A four-hour RTO with a one-hour RPO is a clear bar; without those numbers written down, backup frequency and retention are guesses.

Then there is the part that decides whether any of it worked: restore testing. Backup jobs fail quietly and for boring reasons — a job reports success for months while skipping a volume that was added after it was written. The failure is invisible until the day it matters. A practical cadence is file-level restores monthly, application-level recovery quarterly, and a full environment exercise annually.

We run that cycle and report what it found, including the times it found something.

Taking over an inherited setup

We start by documenting what is actually running, because inherited servers almost never match the documentation they came with. That first pass typically surfaces the same things: a service left listening from a project that ended, a cron job nobody can explain, an SSH key belonging to a contractor who finished two years ago, a backup writing to a disk on the same machine.

You get that inventory whether or not you continue with us. It is the honest starting point for any decision about the servers, including the decision to take them somewhere else.

In-house, ad hoc, or managed

When we are not the right fit

• You already have a systems team doing this work. Paying twice for the same discipline makes no sense.
• You want someone to be reachable at any hour for anything. Say so explicitly at the start so response expectations are written down rather than assumed.
• The servers are running software nobody has support for any more. We can document the risk, but we cannot patch what no longer receives patches.

The first thirty days

Taking over someone else's servers starts with finding out what is true, which is rarely what the documentation says. The first month follows the same shape every time.

1. Inventory. What is installed, what is listening on which port, what runs on a schedule, what the disks look like, where the backups go and whether they have ever been restored.
2. Access review. Who has accounts, who still works there, which keys belong to contractors whose work finished, which credentials are shared between people.
3. Immediate risks first. Anything unpatched and internet-facing, anything running as root that does not need to be, backups writing to the same machine they are backing up.
4. Baseline. Monitoring connected so there is a normal to compare against; without one, "the server seems slow" cannot be answered.
5. Written plan. What we found, what we fixed, what we recommend fixing next and what it depends on.

That plan is yours regardless of what you decide afterwards. A month of documentation has value even if the servers end up somewhere else.

What "patching on a schedule" means in practice

Applying every update the moment it appears is not a strategy — it is how a business discovers that a minor version bump changed behaviour, at 4pm on a Friday. Applying nothing until something forces it is the other failure, and the more common one.

The workable middle is a defined cadence with two lanes. Security updates that are actively exploited go on quickly, with a note to you. Everything else batches into a scheduled window, is applied to a staging copy first where one exists, and gets recorded — what changed, when, and what it touched.

The record is the part people skip and the part that pays off. When an application starts behaving differently on a Tuesday, the question is always "what changed?", and a maintained changelog turns a day of investigation into a five-minute check.

Updates that require a restart — kernel patches in particular — are scheduled with you rather than applied whenever they land.

Frequently asked questions