How to back up a server before an Ubuntu release upgrade

Why release upgrades break servers

do-release-upgrade replaces almost every package with the next release's version. Most servers come through fine. The ones that don't usually fail for one of these reasons:

• Third-party repositories and PPAs are switched off. They stay listed, marked Enabled: no, and what you installed from them stays at its old version. Ubuntu calls this the most common cause of upgrade issues.
• Pending updates and holds. The upgrade won't start while any update is waiting, including one for a held package.
• Configuration file prompts. Where you and a package both changed a file, you pick a version. A wrong answer drops your settings or keeps a file the new version can't read.
• Version jumps. Languages and databases move to new major versions.

From 24.04 LTS to 26.04 LTS, these jumps matter most on a server:

Dovecot 2.4 also changed its configuration format, and OpenSSH moves from 9.6 to 10.2. Read the 26.04 summary for LTS users for everything your server runs.

When you can upgrade

Ubuntu offers an upgrade from one LTS to the next only after the new release's first point release. Ubuntu 26.04.1 came out on 27 August 2026, and the upgrade from 24.04 is now offered. You can't skip an LTS: a 22.04 server goes to 24.04 first.

-c only checks: it prints the new version and exits 0, or prints No new release found. and exits 1:

do-release-upgrade -c

Prompt in /etc/update-manager/release-upgrades sets what it looks for: lts, normal (interim releases too) or never. -d forces an LTS upgrade before the point release; Ubuntu advises against it in production.

Take a snapshot, and copies off the server

A snapshot captures the whole disk, so restoring it puts the server back exactly as it was. Take it last, right before the upgrade, with your provider's guide: DigitalOcean, Hetzner, Vultr, Linode, AWS EC2, Lightsail, Google Cloud or Azure.

A snapshot alone has two gaps: it lives in the same cloud account, and it restores all or nothing. So also dump the databases and copy the files that matter elsewhere. Run this guide's commands as root (sudo -i).

install -d -m 700 /root/pre-upgrade

sudo -u postgres pg_dumpall > /root/pre-upgrade/postgres-all.sql

mysqldump --all-databases --single-transaction --routines --events > /root/pre-upgrade/mysql-all.sql

pg_dumpall writes every database and role to one file; --single-transaction reads InnoDB tables without locking them (add -u root -p if root needs a password). See the pg_dump and mysqldump guides. Copy the dumps and your application folders (/var/www, /opt, home directories) off the server with rclone or rsync; the server backup checklist lists what people forget.

Record what the server runs now

This script saves what you'll compare against afterwards, plus a copy of /etc:

#!/usr/bin/env bash
set -euo pipefail
umask 077

OUT="/root/pre-upgrade"
mkdir -p "$OUT"

dpkg --get-selections > "$OUT/packages.txt"
apt-mark showmanual > "$OUT/manual-packages.txt"
apt-mark showhold > "$OUT/held-packages.txt"
systemctl list-units --type=service --state=running --no-legend --plain > "$OUT/running-services.txt"
systemctl list-unit-files --state=enabled --no-legend > "$OUT/enabled-units.txt"
ss -tlnp > "$OUT/listening-ports.txt"
cp -a /etc/apt/sources.list.d "$OUT/"
tar -czf "$OUT/etc.tar.gz" -C / etc

bash /root/pre-upgrade-record.sh

• manual-packages.txt lists what you installed on purpose: the list to rebuild from.
• held-packages.txt should be empty. Release holds with apt-mark unhold <package>.
• listening-ports.txt is the quickest proof later that each service came back.

Two things the script can't capture. For each Python virtual environment, save its packages with <venv>/bin/pip freeze > requirements.txt. And if you run MySQL, find accounts on the old password plugin, which MySQL 8.4 locks out by default:

SELECT User, Host FROM mysql.user WHERE plugin = 'mysql_native_password';

Ubuntu's release notes recommend switching each to caching_sha2_password. This resets the password, so reuse the current one:

ALTER USER 'app'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'current-password';

Run the upgrade

Bring the current release fully up to date, or the upgrade refuses to start. The phased-updates option includes updates Ubuntu is still rolling out:

apt update

apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true

If /run/reboot-required exists, reboot. Check free space with df -h / /boot; the download alone can be several gigabytes. Now take the snapshot.

Over SSH, the upgrader starts a spare sshd on port 1022 in case the main one breaks mid-upgrade, but doesn't open the port in your firewall. Allow it in ufw and your cloud firewall first:

ufw allow 1022/tcp

Find your provider's web console too. Then run the upgrade inside a session that survives a dropped connection:

tmux new -s upgrade

do-release-upgrade

If SSH drops, reconnect and run tmux attach -t upgrade. The upgrader also runs itself inside GNU screen when it's installed; screen -d -r reattaches. Expect these questions:

• Foreign packages: installed from outside the Ubuntu archive. Note them, and check them first afterwards.
• Configuration files: press D to see the difference. The default keeps yours and saves the package's as .dpkg-dist; taking theirs saves yours as .dpkg-old. Some packages ask as a menu.
• PostgreSQL: postgresql-common may offer to upgrade the main cluster automatically, by default with a slow but safe dump and reload inside the upgrade. Say no to do it later, on your schedule.
• Obsolete packages: removed and purged, configuration included; press d to review the list. postgresql-NN packages are never removed automatically, so a cluster keeps its binaries.

Last, it asks to reboot; the upgrade isn't finished until it does. Once you're back on port 22, close the spare port:

ufw delete allow 1022/tcp

Check the server after the reboot

Confirm the new release, then look for units that failed to start:

lsb_release -a

systemctl --failed

Compare the running services with your record. Lines starting with < are services that ran before and don't now:

diff <(awk '{print $1}' /root/pre-upgrade/running-services.txt) <(systemctl list-units --type=service --state=running --no-legend --plain | awk '{print $1}')

Find packages no enabled repository provides any more, leftovers from 24.04 and from the disabled repositories (2>/dev/null hides apt's scripting warning):

apt list --installed 2>/dev/null | grep ',local]'

List the configuration files where you and a package disagreed, and merge what you need:

find /etc -name '*.dpkg-dist' -o -name '*.dpkg-old' -o -name '*.ucf-dist'

• Repositories. Entries the upgrade switched off carry Enabled: no in /etc/apt/sources.list.d/. Check that the vendor publishes packages for 26.04, change the suite from noble to resolute, delete the Enabled: no line and run apt update.
• PHP-FPM. 8.5 listens on /run/php/php8.5-fpm.sock, so sites return 502 until you update fastcgi_pass (nginx) or run a2disconf php8.3-fpm and a2enconf php8.5-fpm (Apache). Your changes in /etc/php/8.3/ don't carry over to /etc/php/8.5/, and versioned extensions such as php8.3-mysql need their 8.5 packages.
• PostgreSQL. Run pg_lsclusters. Unless you let the upgrade convert it, your data is still in the 16 cluster, usually on port 5432, and an empty 18 cluster may sit on the next port. Follow upgrading PostgreSQL to a new major version, and keep postgresql-16 installed until the new cluster is checked.
• MySQL. If an application can't log in, look for mysql_native_password accounts you missed. Ubuntu's notes also allow mysql_native_password=ON under [mysqld] as a stopgap; later MySQL versions drop it.
• Python. Rebuild each virtual environment, which Python's docs treat as disposable: python3 -m venv --clear <venv>, then <venv>/bin/pip install -r requirements.txt.

Roll back if it went wrong

There is no downgrade. do-release-upgrade only moves forward, and apt can't take a whole system back a release. The way back is the snapshot:

1. If the upgraded server took writes you want to keep, dump those databases and copy the dumps off first. A dump from a cluster the upgrade didn't convert loads into the restored server unchanged.
2. Restore the snapshot with your provider's tools, from the guides above. Some providers restore the existing server in place; others build a new server from the snapshot, with a new IP address.
3. Load the newer dumps, and point DNS at the new address if it changed.

Common errors

Frequently asked questions

Can I upgrade Ubuntu 22.04 straight to 26.04?

No. LTS upgrades go one release at a time: 22.04 to 24.04, then 24.04 to 26.04. Back up and check the server between the two.

When can I upgrade from 24.04 to 26.04 LTS?

Now. Ubuntu opens LTS-to-LTS upgrades after the first point release, and 26.04.1 came out on 27 August 2026. do-release-upgrade -c confirms it from your server.

Can I undo an Ubuntu release upgrade?

Not with apt or do-release-upgrade; there is no downgrade. Restore the snapshot you took before, or rebuild from your backups.

Does do-release-upgrade delete my data?

It leaves your own files alone, but it replaces packages, switches off third-party repositories, asks about changed config files and offers to purge obsolete packages, configuration included. That's enough to break a working site, which is why you back up first.