The server you haven't touched in 12 years is now the target: how to update it without breaking it

The server you assumed was untouchable

We all have one. A VPS with a Debian or Ubuntu you installed ten or twelve years ago, serving something that "can't be touched" —a website, an internal API, a panel— and that's been running so long without trouble you've almost forgotten it exists. You haven't run an apt upgrade on it in ages. And yet there it is, unbothered. You considered it bulletproof precisely because of that: in a decade, nobody ever found anything in it.

Well, sit down, because that logic just flipped. We warned about it when Mythos started uncovering 27-year-old flaws in kernels that had been in production for decades: there are now machines capable of auditing an entire codebase and stitching invisible flaws into working exploits, at a scale no human can match. And that server of yours, running twelve-year-old software, is the easiest bite on the menu.

What kept you safe wasn't the machine's strength: it was that scanning it with a magnifying glass was expensive and slow. That's over. The good news: bringing it up to date is perfectly doable without breaking what runs on top. Here's the plan, step by step, no drama.

Before you touch ANYTHING: a snapshot you can roll back to

Golden rule number one, the one that separates an afternoon of maintenance from a weekend of panic: don't touch a single package without a way back first.

• Snapshot the whole machine. If your provider (Hetzner, DigitalOcean, OVH, etc.) offers snapshots, do it now. It's the only thing that lets you undo everything at once if something goes wrong.
• Back up what actually matters: databases (mysqldump/pg_dump), configuration (/etc), application data and, if there's a website, its document root.
• Write down the starting state. Save the output of these commands to a file; it'll be your map:

uname -a                 # current kernel
lsb_release -a           # distro version (or cat /etc/os-release)
dpkg -l > packages.txt   # inventory of installed packages
ss -tulpn                # what's listening and on which port
systemctl list-units --type=service --state=running

If you take a single sentence home from this whole article, make it this one: the snapshot beforehand is not optional.

Step 1 — Know what you're dealing with (and whether the distro is still alive)

Before updating, check the most important thing: whether your distribution version still receives security support or is already dead (EOL, End Of Life).

• Look at the output of lsb_release -a. An Ubuntu 16.04 or a Debian 9, for instance, haven't seen a patch in years.
• An EOL distro is exactly the problem: even if you run apt upgrade, there are no patches to apply because the repositories no longer publish them. You're updating to nothing.

This defines your path. If the distro still has support, Step 2 is enough. If it's EOL, you'll also need Step 3 (release jump) or, in extreme cases, migrating to a fresh machine.

Step 2 — Bring packages and the kernel up to date

For a still-supported distro, the bulk of the work is this:

apt update                       # refresh the package index
apt upgrade                      # update without removing anything
apt full-upgrade                 # allow major changes (kernel, dependencies)
apt autoremove --purge           # clean up what's no longer needed

A couple of warnings that save you scares:

• The kernel only takes effect after a reboot. You can update the kernel package, but until you reboot you're still running the old one. Check with uname -r before and after.
• If during the update a menu pops up asking what to do with a modified config file (*.dpkg-dist / *.dpkg-new), don't click blindly: "keep the current version" is usually the safe bet if you edited that config by hand.
• Can't be bothered to babysit this every month? Enable automatic security updates:

apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

Step 3 — The release jump (if your distro is dead)

This is where people break a sweat, and rightly so: jumping a major version is the most delicate part. But it has a method.

• Go one version to the next, never in leaps. From Ubuntu 18.04 you go to 20.04, then 22.04… not straight to the latest. Each jump, its own reboot and check.

On Ubuntu:

apt update && apt full-upgrade   # first get current on the existing version
do-release-upgrade               # official release-upgrade assistant

On Debian, the jump is manual: you edit the repositories in /etc/apt/sources.list (changing the codename: buster → bullseye → bookworm…) and then:

apt update && apt full-upgrade

• Between one jump and the next, reboot and verify the site and services are still alive. If something breaks, you fix it with a single context jump, not with five versions stacked on top.
• Is the machine so old it drags too much fragile customization? Sometimes it's cleaner to spin up a fresh VPS on the current version and migrate —we cover it in detail in how to migrate a VPS with zero downtime— than to drag twelve years of patches over patches.

Step 4 — What breaks (and how not to panic)

Updating for real means some things will change version, and that can affect what runs on top. The usual suspects:

• PHP: going from PHP 7.x to 8.x breaks old code. Check that your application tolerates the new version before making the jump, or install the specific version you need and log it as debt to resolve.
• MySQL/MariaDB: major version changes can touch the data format. That's why the mysqldump at the start wasn't optional.
• Services and configs: check that Nginx/Apache, your cron jobs, your certificates and your sockets are still standing after each reboot.

The strategy that never fails: change little, reboot, verify. Don't go updating the distro, PHP and the database all at once; chain the changes and verify between each.

Step 5 — While you're at it, close the door

If you're going to touch the server, take the chance to leave it decent. Four cheap moves that raise the bar a lot:

• SSH with a key, not a password, and PermitRootLogin no.
• A minimal firewall (ufw or nftables): open only what you actually use (ss -tulpn tells you what's listening that shouldn't be).
• fail2ban to stop brute-force hammering.
• Automatic security updates (the unattended-upgrades from Step 2) so this doesn't sit frozen for another twelve years.

The recommendation, no hedging

A server that's "been running for years untouched" isn't an achievement, it's a dormant risk. What changed with tools like Mythos isn't that your machine is suddenly weaker: it's that scanning it with an industrial magnifying glass is now cheap, and whatever's wrong will eventually be found. The only defense that ages well isn't luck, it's update discipline.

If you've got one of those machines around and your stomach turns at the mere thought of touching it —because "if it works, don't touch it"— that's exactly the server we should talk about. We bring it up to date with a snapshot, a plan and a guaranteed way back, without your services noticing a thing. Before someone who shouldn't takes a look.