How to Update the OS on Your VDS

Updating the OS on a VDS closes known vulnerabilities, but a failed update on a remote server can leave you locked out. The difference between apt upgrade and do-release-upgrade is the difference between a routine task and an event you should plan for in advance.

Updating Packages (Ubuntu/Debian)

# Refresh the package list from the repositories
apt update

# Upgrade all packages without removing anything installed
apt upgrade -y

# Upgrade while replacing configs and possibly removing packages
apt full-upgrade -y

# Clean up packages no longer needed as dependencies
apt autoremove -y

The difference between upgrade and full-upgrade matters: the former never removes installed packages, even if the new version's dependencies would otherwise require it, and in that case it simply skips upgrading the conflicting package. The latter allows removal to resolve dependencies — so it should be run deliberately, after reviewing the planned actions before confirming.

Upgrading the Distribution

# Ubuntu 20.04 → 22.04, the latest LTS at the time of the move
do-release-upgrade

# Debian: the careful path via changing sources
sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list
apt update && apt full-upgrade -y

On Ubuntu, do-release-upgrade checks for a new LTS release itself, downloads the packages, and migrates the configs of known services. Debian has no separate utility for this: moving to a new release is a matter of swapping the codename in your package sources and running a full full-upgrade, so the risk of configuration conflicts is higher and needs to be checked by hand.

Common Update Errors Explained

The error E: Unable to correct problems, you have held broken packages means some packages are pinned (apt-mark hold) or conflict on dependency versions. Check the list of pinned packages with apt-mark showhold and remove the pin before updating, unless it was intentional.

dpkg: dependency problems prevent configuration of package-name:
 package-name depends on libssl3 (>= 3.0.0); however:
  Version of libssl3 on system is 1.1.1.

This error most often appears when repositories from different releases are mixed — for example, if sources.list still has lines from the old distribution version alongside the new ones. The fix is to check /etc/apt/sources.list and the files in /etc/apt/sources.list.d/ for the old release codename.

An SSH connection dropping during do-release-upgrade used to mean the upgrade process was interrupted. Modern versions of the utility bring up a backup SSH daemon on an alternate port (usually 1022) for the duration of the upgrade — but you should not rely on that: it is safer to run the upgrade inside screen or tmux, so the session survives a dropped connection.

Comparing Update Methods

Method	What it changes	Downtime risk	When to use
apt upgrade	Minor package versions	Low	Regularly, every 1–2 weeks
apt full-upgrade	Packages with dependency changes	Medium	After a security bulletin, before a major release
do-release-upgrade	The entire distribution (Ubuntu)	High	Moving to a new LTS every 1–2 years
Codename change (Debian)	The entire distribution (Debian)	High	Moving to a new stable release

Important Before You Upgrade

Create a server snapshot in the control panel — it is the only quick way back if a distribution upgrade breaks the boot process.
Upgrade during a period of low load, and warn your users in advance if this is a distribution upgrade rather than a routine apt upgrade.
Check the versions of critical services (PHP, MySQL, Nginx) before upgrading — a major OS upgrade often drags a major upgrade of these packages along with it, which is a separate config migration on its own.
Reboot the server after the upgrade and check that all the services you need start automatically, not just the one that is still running from before.

When to Delay the Update or Do It Differently

A major distribution upgrade should not be run blindly in the following cases:

The server carries production load with no standby node — it is better to first run the upgrade on a clone (a snapshot spun up as a separate VDS) and only then on the live one.
Packages from third-party PPAs or repositories built for a specific distribution version are in use — after the upgrade they may fail to resolve dependencies or simply disappear from the available list.
There is no current database backup — migrating MySQL or PostgreSQL to a new major version as part of an OS upgrade may require a separate dump export and import.

Verifying the Result

Check the release version: lsb_release -a or cat /etc/os-release should show the expected version.
Check the status of key services: systemctl status nginx mysql php8.2-fpm — all should be active (running), not just installed.
Check the kernel log for errors after the reboot: dmesg | grep -i error.
Open the site or application from outside and confirm it responds the same way it did before the update — the PHP or MySQL version may have changed and affected the code's behavior.

If the update touches the kernel and you want to confirm the new kernel actually loaded after the reboot, the uname -r command shows the version, and the details of rebuilding modules are covered in the article on updating the Linux kernel. The firewall is worth checking separately after a release change too — sometimes the UFW package updates with changed defaults, which is covered in the article on configuring UFW on a VDS.

Frequently asked questions

Is a reboot required after every apt upgrade, or only when the kernel itself was updated?

A reboot is not required after every regular package upgrade — most updated services simply need a restart of their own process, which a package manager often does automatically. A reboot only becomes necessary when the kernel, systemd, or certain core libraries change, since those stay loaded in memory until the whole system restarts, not just the affected service.

If full-upgrade wants to remove a package that is actually still needed, what is the safer move instead of just confirming it?

Stop and read the list of planned removals before confirming anything, then check whether that package is pinned or depends on something being replaced. Often the safer path is resolving the underlying dependency conflict directly, or postponing that particular upgrade step, rather than letting the tool remove a package the server still relies on for its daily work.

Does restoring a server snapshot taken before a major OS upgrade also undo any database changes made since then?

Yes, a full server snapshot captures the entire disk state at that moment, databases included, so restoring it rolls everything back together, not just the system files. Any data written after the snapshot, including new database rows, disappears along with the upgrade, which is exactly why a separate, more recent database backup matters for anything written during that window.

Does keeping packages updated regularly mean security patches get applied automatically, or does someone still need to run the upgrade manually each time?

Regular package updates still need to be run deliberately rather than happening by themselves; nothing patches the server automatically just because new versions exist in the repository. Treating it as a routine task on a predictable schedule actually closes known vulnerabilities in time, since an unapplied update sitting in the repository gives no protection to the running server.