Upgrading an Ubuntu server safely

Every Ubuntu release has an end-of-support date. After it, security fixes stop, and the server slowly becomes a risk. Upgrading to the next release keeps it supported, but a release upgrade changes a lot at once: new versions of PHP, Python, databases and system tools. On a server you care about, that needs a plan.

This guide explains when to upgrade, how to prepare, how to run the upgrade without losing your connection, what to check afterwards and what to do if it goes wrong. It also covers the alternative many experienced admins prefer: building a fresh server on the new release and moving to it. Debian has a similar but different process, so Debian users should follow Debian's own release notes.

What is in this guide

• A few words you will see
• When to upgrade
• Upgrade in place, or rebuild?
• Before you start
• 1. Check what you are running
• 2. Back up, and test the backup
• 3. Make a list of what the server does
• 4. Bring the current release fully up to date
• 5. Run the upgrade inside tmux
• 6. Answer the prompts carefully
• 7. Reboot and check everything
• 8. Tidy up
• If it goes wrong
• Troubleshooting
• Limits
• When to step up

A few words you will see

Term	What it means
Release	A version of Ubuntu, named by year and month, such as 24.04 for April 2024.
LTS	Long-term support. LTS releases come out every two years and get years of security updates. Most servers use them.
Interim release	A release between LTS versions, with only a short support period.
End of support	The date after which a release no longer gets security updates.
Point release	An update to an LTS release, such as .1 or .2, that bundles fixes.
do-release-upgrade	Ubuntu's official tool for moving to the next release.
PPA or third-party repository	An extra source of packages added by you or an installer.

When to upgrade

• Plan ahead of end of support. Check your release's support dates on Ubuntu's official release pages. Upgrading in a calm month beats rushing in the last week.
• LTS to LTS only. On a server, go from one LTS release to the next. By default, the upgrade tool only offers the new LTS once its first point release is out, after early bugs have been fixed. Waiting for that is sensible.
• Not just before something important. Do not upgrade a shop the week before a sale, or a club site the day before an event.

Upgrade in place, or rebuild?

	Upgrade in place	Rebuild on a fresh server
How it works	The upgrade tool changes the existing server	Set up a new VPS on the new release and move your data
Effort	Less, if the server is simple	More, but very predictable
Downtime	The site is affected while the upgrade runs and during checks	Almost none: the old server keeps running until you switch
If something breaks	Restore from backup, which takes time	Keep using the old server and fix the new one at leisure
Leftover clutter	Years of old settings come along	A clean start
Best for	Simple servers, test boxes, small personal projects	Business sites, complex servers, very old servers

If you choose to rebuild, moving to a new VPS walks through it, and the rest of this guide is optional reading. Running the old and new servers side by side for a few days costs a little extra, but makes the move much safer.

Before you start

• A tested backup. See step 2.
• An hour or two, at a quiet time.
• Access to the console in the VPS control panel, in case SSH stops working.
• At least a few GB of free disk space. Check with df -h.

1. Check what you are running

lsb_release -a
uname -r
df -h /

These show the current release, the running kernel and the free space on the main disk. If you are on an interim release, the upgrade goes to the next interim or LTS release, depending on your settings. If you are several releases behind, you must upgrade one step at a time, and rebuilding is usually easier.

2. Back up, and test the backup

A release upgrade usually works, but you need a way back if it does not. Back up:

• Your websites and app data.
• Databases, exported with their own tools, such as mysqldump.
• Config files you changed, especially in /etc.
• Crontabs, env files and scripts.

Copy the backup off the server, and restore a small part of it somewhere to prove it works. If your VPS control panel offers snapshots, take one as well, but check how restores work before relying on it. Using a storage VPS for backups shows one way to do this.

3. Make a list of what the server does

After the upgrade you will check that each thing still works, so write the list now:

systemctl list-units --type=service --state=running
sudo ss -tlnp
ls /etc/apt/sources.list.d/
php -v
python3 --version

Skip the commands for things you do not use. Note each running service, open port, extra package source and language version. Language versions matter most: a release upgrade often brings a newer PHP or Python, and code written for the old one may need changes.

4. Bring the current release fully up to date

sudo apt update
sudo apt full-upgrade
sudo apt autoremove
sudo reboot

Starting from a fully updated system avoids many upgrade problems. Reboot so the newest kernel is running, then log back in.

5. Run the upgrade inside tmux

If your SSH connection drops during the upgrade, the upgrade can stop halfway, which is the worst outcome. Run it inside tmux, so it keeps going even if you disconnect:

sudo apt install tmux
tmux new -s upgrade

If you are disconnected, log back in and reattach with tmux attach -t upgrade. Screen and tmux explains more.

The upgrade tool also offers to start a backup SSH service on port 1022, in case the main one fails during the upgrade. If you use UFW, open that port for the upgrade only, and close it afterwards:

sudo ufw allow 1022/tcp

Now start the upgrade:

sudo do-release-upgrade

If it says no new release is found, either you are already on the newest LTS, or the next LTS's first point release is not out yet. That is normal, and it is a good reason to wait.

6. Answer the prompts carefully

The upgrade asks a few questions as it goes. Read each one.

• Third-party sources will be disabled. Package sources you added are turned off during the upgrade. You will check and turn them back on in step 8.
• Restart services automatically? Usually yes.
• A config file has changed. When a package's default config file has changed and you edited your copy, you are asked which to keep. If you made changes on purpose, such as to SSH or a web server, keeping your version is usually right. You can view the differences first. Write down each file you are asked about, and check it after the upgrade.
• Remove obsolete packages? Usually yes, but read the list first. If it includes something you rely on, say no and look into it after.

The download and install can take a while. Let it finish. When it asks to reboot, say yes.

7. Reboot and check everything

Log back in and confirm the new release:

lsb_release -a
systemctl --failed

systemctl --failed lists any services that did not start. Then go through your list from step 3:

• Websites and apps load, including pages that use the database and admin logins.
• PHP. If the PHP version changed, PHP-FPM pools and web server settings that name the old version need updating. Check with php -v and ls /etc/php, copy any custom pool files to the new version's folder, and install the same extensions for the new version.
• Python apps. Virtual environments built on the old Python often stop working. Recreate them and reinstall the app's packages.
• Databases start and your apps can reach them.
• Scheduled jobs still run. Check their logs the next day.
• Docker containers came back up, with docker ps.
• SSH settings are still as you set them: sudo sshd -T | grep -E "passwordauthentication|permitrootlogin".

8. Tidy up

• Close the temporary SSH port: sudo ufw delete allow 1022/tcp.
• Check each third-party package source in /etc/apt/sources.list.d/. Turn back on only those that support the new release, following each project's own instructions.
• Remove leftover packages with sudo apt autoremove.
• Check automatic security updates are still on: systemctl status unattended-upgrades.
• Update your notes with the new versions.

If it goes wrong

There is no supported way to downgrade a release. If the upgrade fails badly:

1. Do not panic-fix. If the site is down, decide first whether to restore or repair.
2. If the server will not boot or SSH fails, use the control panel console. Look at sudo journalctl -b -p err for errors.
3. If the upgrade stopped halfway, try sudo dpkg --configure -a and then sudo apt -f install to let it finish.
4. If it cannot be repaired quickly, reinstall the server from the control panel on the new release and restore your backup, or restore a snapshot if you took one.

This is the main reason rebuilding on a second server is safer for important sites: the old one keeps running while you sort out the new one.

Troubleshooting

Symptom	Likely cause	Fix
"No new release found"	Already on the newest LTS, or the next LTS's first point release is not out	Wait, or check the support dates on Ubuntu's official pages
Upgrade refuses to start, packages held back	The current system is not fully updated	Repeat step 4
Not enough free space	Disk too full for the download	Free space with sudo apt clean and by removing old files. See Linux server tools
Website shows PHP code or a 503 error	PHP version changed, and the web server still points at the old one	Update the PHP-FPM socket path or pool files for the new version
Python app fails to start	Its virtual environment was built for the old Python	Recreate the virtual environment and reinstall packages
A package from an extra source is missing	Third-party source disabled during the upgrade	Turn it back on, if it supports the new release
Cannot log in after reboot	SSH settings changed during the config file prompts	Use the console and check the SSH settings files

Limits

• Upgrades change a lot. Even when the upgrade itself succeeds, your apps may need work for new language and database versions.
• No downgrade. Your backup is your only way back.
• Old servers are harder. Servers that skipped several releases, or have many extra package sources, are more likely to have problems. Rebuilding is often quicker.
• This guide is for Ubuntu. Debian uses a different process. Follow its release notes.
• Snapshots vary. Do not assume your plan includes snapshots or backups. Check the control panel, and keep your own backups regardless.

When to step up

An upgrade is a good moment to rethink the server. If it was often short of memory, or you want a clean start without years of leftover settings, build the new release on a fresh, bigger VPS and move across. The old server stays as your safety net until the new one is proven. How to read VPS specs helps you choose the size.

To compare what is available now, start with the cheapest RackNerd VPS guide and check the sales page.