Ubuntu 24.04から26.04へのアップグレード手順

Ubuntu 24.04 はいつ 26.04 にアップグレードできますか？

VPS では、Ubuntu 24.04 を今すぐ 26.04 にアップグレードできます。Canonical が 24.04 LTS からのアップグレードを有効にした 29 September 2026 以降、24.04 のサーバーで do-release-upgrade を実行すると 26.04.1 が提示されます。Ubuntu 26.04 LTS (Resolute Raccoon) は 23 April 2026 にリリースされました。しかし Canonical は、最初のポイントリリースが公開されるまで LTS から LTS へのアップグレード経路を開きません。最初の数か月に見つかったインストールおよびアップグレードの不具合が、そのリリースにまとめて修正されるためです。今回は、ポイントリリースの公開後も待機期間が続きました。26.04.1 は 27 August 2026 にリリースされましたが、Canonical は rust-coreutils の最近のバージョンにおけるリグレッションを修正する計画済みのバックポートのため、さらに数週間アップグレードを保留しました。バージョン番号の意味が分かりにくい場合は、26.04.1 は別の Ubuntu ではなく、4 か月分の修正をメディアに統合した同じ 26.04 です。そのため、既存のサーバーに Canonical が最初に提示するバージョンになります。

29 September までは、24.04 のサーバーで確認コマンドを実行すると、次の結果が表示されました。

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

これはサーバーの障害ではありません。現在も同じ結果が表示される場合は、その結果を決める設定を確認してください。Ubuntu Server の /etc/update-manager/release-upgrades には Prompt=lts が設定されています。つまり、このツールが提示するのは次の長期サポートリリースだけであり、Canonical がそのアップグレード経路を開いた場合に限られます。Prompt=normal を設定すると、24.10、25.04、25.10 の順にアップグレードします。しかし、これらの中間リリースはすべてサポート終了になっています。lts のままにしてください。待機中にアップグレードを延期しない場合のため、Canonical は do-release-upgrade -d を提供していました。現在はアップグレード経路が開いているため、サーバーでは告知に記載された通常のコマンドを使用します。開始する前に、26.04.1 で変更された内容とアップグレード経路が開いた時期を確認してください。22.04 のサーバーは、このアップグレードを直接実行できません。アップグレードツールが提示するのは常に次の LTS だけだからです。そのため、24.04 を経由して 22.04 を 26.04 にアップグレードする方法で、最初の移行と、2 回目の移行前に取得するスナップショットについて説明します。

以下のコマンドはすべて、指定された順序で、自分のサーバー上で自分で実行します。アップグレード対象のマシン上で、リリースアップグレードを事前にリハーサルすることはできません。カーネルと C library が置き換えられ、完了には再起動が必要です。

アップグレードすべきか

Ubuntu 24.04 は 2029 まで標準セキュリティ更新を受けられるため、正常に稼働している本番サーバーに期限があるわけではありません。26.04 に含まれる PHP 8.5、PostgreSQL 18、MySQL 8.4 LTS、OpenSSH 10.2、または 7.0 kernel が必要ならアップグレードします。「番号が上がったから」という理由だけで、顧客向けサービスを提供しているマシンに変更を加えるべきではありません。

次のいずれかに該当する場合は、インプレースアップグレードを行わないでください。

• プロバイダーのコンソール（VNC または serial）を開き、そこからログインしたことが一度もない。SSH が使えなくなった場合、そのコンソールだけがサーバーへ戻る手段です。アクセスできなくなってからコンソールが動作しないと判明しても手遅れです。
• 1 時間の停止時間を許容できず、ロールバック手段もない。
• resolute 用のパッケージをまだ公開していない third-party repository にスタックが依存している。
• 2 年以上前に手作業で構築され、何が入っているのか誰も把握していない。

多くの場合、代替策のほうが適切です。新しい 26.04 VPS を構築し、スタックをインストールしてデータを復元します。その後、正常に応答することを確認してから DNS を切り替えます。新しいサーバーの動作を確認するまで古いサーバーを稼働させられるため、ロールバックは復元ではなく DNS の変更で済みます。この方法を選ぶ場合は、新しい VPS で最初の 10 分間に行う作業から始め、新しいサーバーを適切に構築してください。

手順 1: 復元できるバックアップを取得する

障害の発生の仕方が異なるため、2 層構成にします。プロバイダーのスナップショットはディスク全体を対象とし、数分で復元できます。ただし、データベースが書き込み中に取得されるため、アプリケーション整合性ではなくクラッシュ整合性の状態です。サーバー外部に保存した restic によるファイルレベルのバックアップなら、個別のファイルを取得でき、アカウントがロックされても残るコピーを確保できます。

まず、データベースを手動でダンプします。データベースを停止せずに信頼できるバックアップを取得するには、ダンプが唯一の方法です。

sudo -u postgres pg_dumpall | sudo tee /var/backups/pg-all.sql > /dev/null
sudo mysqldump --all-databases --single-transaction --routines | sudo tee /var/backups/mysql-all.sql > /dev/null
sudo tar czf /var/backups/etc-before-upgrade.tgz -C / etc
sudo chmod 600 /var/backups/pg-all.sql /var/backups/mysql-all.sql

--single-transaction は InnoDB テーブルに対してのみ整合性のあるダンプを作成します。MyISAM テーブルではデータベースを停止する必要があります。/etc の tarball は、アップグレードで確認を求められるすべての設定ファイルが含まれているため、実際に使用することになります。

復元したことのないバックアップは、推測にすぎません。必要に迫られる前に、今のうちにその中からファイルを 1 つ取り出してください。

手順 2: まず 24.04 を完全に更新する

do-release-upgradeは、パッケージの状態が壊れているシステムでは実行できません。また、更新が途中まで済んだ 24.04 では、その後に発生する失敗の原因を特定しにくくなります。

sudo apt update
sudo apt full-upgrade
sudo apt --purge autoremove
sudo dpkg --audit
apt-mark showhold

dpkg --auditの出力がない場合、構成途中のパッケージはありません。apt-mark showholdの出力がない場合、dpkg hold が設定されたパッケージはありません。これは APT の優先度 pin は表示しません。優先度 pin は別の仕組みで、パッケージを保留することもあります。手順 3 で確認します。showholdに表示されたパッケージは、パッケージ名を指定して sudo apt-mark unhold で保留を解除します。保留に正当な理由がある場合は、その状態を受け入れてここで中止してください。

kernel が変更された場合は再起動します。システムが実行中だと認識しているコードでアップグレードできるようにするためです。

[ -f /var/run/reboot-required ] && sudo reboot

次に、ディスク容量を確認します。アップグレードプログラムは、インストールを開始する前に新しいパッケージ一式をすべてダウンロードします。空き容量が不足している場合は、対象のファイルシステム名を示すメッセージを出して中止します。

df -h / /boot

/の空き容量が約 5 GB 未満だと、この処理は失敗しやすくなります。/bootが 300 MB 未満の場合は、kernel のインストール中に No space left on deviceで失敗します。通常は古い kernel が原因で、sudo apt --purge autoremoveで削除できます。

開始前に、もう 1 つ停止しておくものがあります。自動セキュリティ更新が処理中に実行されると dpkg lock を保持するため、リリースアップグレーダーは Could not get lock /var/lib/dpkg/lock-frontendで停止します。先に sudo systemctl stop unattended-upgradesを実行し、完了後に再度開始してください。

手順 3: サードパーティーリポジトリと pin 固定パッケージを確認する

デフォルトでは、do-release-upgrade は Ubuntu のものではないすべての apt ソースをコメントアウトします。noble 用にビルドされたパッケージは、resolute システムを壊す可能性があるためです。--allow-third-party オプションを指定すると、代わりにそれらを有効なままにできますが、まさにそのリスクを負うことになります。ツールに判断させる前に、何を引き継ぐのかを把握してください。

ls /etc/apt/sources.list.d/
grep -rhE '^(deb |Types:|URIs:|Suites:)' /etc/apt/sources.list.d/
ubuntu-security-status --thirdparty
ls /etc/apt/preferences.d/

Ubuntu 24.04 では、そのディレクトリに 2 種類の形式があります。従来の 1 行形式の .list ファイルと、Types: および Suites: フィールドを持つ deb822 形式の .sources ファイルです。デフォルトのアップグレードでは、どちらも無効になります。ubuntu-security-status --thirdparty は、Ubuntu のどのアーカイブでも提供されていないインストール済みパッケージを一覧表示します。これは、追加したパッケージの実数を正確に把握する方法です。/etc/apt/preferences.d/ 内のファイルは、名前に拡張子がないか、.pref で終わり、かつ英字、数字、ハイフン、アンダースコア、ピリオドだけで構成されている場合にのみ pin として読み込まれます。APT はそれ以外のファイルを無視し、通常は通知を出します。noble を指定する pin は、アップグレード後もパッケージを古いバージョンに留めることがあります。利用可能なバージョンと pin が設定する優先度によって結果が変わるため、各ファイルを読み、引き続き必要かどうかを判断してください。

各サードパーティーリポジトリについて、作業を始める前に、ベンダーが新しいコードネーム向けのパッケージを公開していることを確認してください。Docker のスイートは https://download.docker.com/linux/ubuntu/dists/ に一覧表示されています。他のベンダーも同じディレクトリを公開しています。存在しないスイートを指すソースがあると、アップグレード後の最初の apt update で次のエラーが表示されます。

E: The repository 'https://download.docker.com/linux/ubuntu resolute Release' does not have a Release file.

ベンダーが公開するまで、そのソースは無効のままにしてください。ベンダーがビルドしていないコードネームに書き換えると、誤ったシステムライブラリにリンクされたパッケージをインストールすることになります。

手順 4: 通常の SSH シェルではなく tmux でアップグレードを実行する

通常のログインシェルで do-release-upgrade の実行中に接続が切れると、プロセスは SIGHUP を受け取り、展開の途中で終了します。その結果、dpkg が不完全な状態になり、再接続に必要なネットワークスタックが動作しなくなる場合があります。代わりにターミナルマルチプレクサ内で実行してください。クライアントとの接続が切れても、プロセスはサーバー上で実行を続けます。

sudo apt install -y tmux
tmux new -s upgrade

そのセッション内で、次を実行します。

sudo ufw allow 1022/tcp
sudo do-release-upgrade

アップグレードプログラムは、変更を加える前に port 1022 で 2 つ目の SSH デーモンを起動し、そのことを表示します。

To make recovery in case of failure easier, an additional sshd will be started on port '1022'. If anything goes wrong with the running ssh you can still connect to the additional one.

ファイアウォールでその port を開くことはありません。許可なくファイアウォールに穴を開けると、予期しない問題になるためです。開始前に自分で 1022 を開き、sudo ufw delete allow 1022/tcp が完了したら閉じてください。プロバイダーが、サーバーの外部にあるコントロールパネルでもう 1 つのファイアウォールを運用している場合があることにも注意してください。

接続がそれでも切れた場合は、再度ログインして tmux attach -t upgrade を実行します。離れている間もアップグレードは実行されていました。アップグレードが続行されず、dpkg の設定が中途半端な状態になっていたり、apt の sources が noble と resolute の混在状態になっていたりした場合は、失敗したリリースアップグレードから復旧する方法でパッケージの状態を修復する手順と、修復を中止して代わりにスナップショットを復元すべきタイミングを説明しています。

手順 5: 設定ファイルのプロンプトには慎重に回答する

dpkg がプロンプトを表示するのは、ユーザーまたはスクリプトが変更したファイルだけです。したがって、各プロンプトは意図的に編集したファイルを示しています。プロンプトを消すために Enter を押すと、強化済みのサーバーが気付かないうちにデフォルト構成へ戻ります。

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?

毎回、最初に D を押します。変更内容を確認してから、N で自分のバージョンを保持します。デフォルトはすでに N であり、安全な選択です。現在のファイルは実際に動作しており、パッケージ側のファイルはこのマシンで実行されたことがないためです。

自分のファイルを保持すると、新しいデフォルト設定は適用されません。サーバーが起動し、時間に追われていない状態になってから、後で差分を統合します。

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-new'

一覧に表示される各ファイルは、メンテナー側のバージョンです。これは自分のファイルの隣に保存されています。1 つずつ差分を確認し、必要な設定を取り込みます。特に注意すべきものは 2 つあります。/etc/ssh/sshd_config は、誤った選択をするとセッションが終了するためです。Web サーバーの設定は、誤った選択をするとサイトが停止するためです。

アップグレードでは、needrestart を使用して再起動するサービスも尋ねられます。すべてのサービスを再起動する選択を受け入れます。ディスクから削除された共有ライブラリファイルを使い続けているデーモンは、後で監視していないタイミングに別のリクエストを処理した際、クラッシュする可能性があります。

ステップ 6: 再起動とマシンの確認

sudo reboot

再起動後に SSH で接続できず、プロバイダーのコンソールに grub rescue> が表示されている場合は、アップグレードで更新された GRUB のモジュールとディスクに書き込まれたブートローダーが食い違っている可能性があるため、GRUB のレスキュープロンプトで止まった VPS を起動させ、再発を防ぐ手順に沿ってコンソールから復旧してください。

再起動後、以下の確認を行います。

lsb_release -a
uname -r
systemctl --failed
journalctl -p err -b --no-pager | head -50
sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove

lsb_release -a を実行し、Release: 26.04 および Codename: resolute が表示されることを確認します。uname -r を実行すると、7.0 カーネルが表示されるはずです。systemctl --failed はユニットを何もリストアップしないのが正常であり、もしリストアップされたものがあれば、それが次に行うべき作業となります。最後の apt update でパッケージインデックスを更新し、apt full-upgrade を実行してアップグレード後に公開された更新プログラムをインストールします。Java で動くサービスがある場合は、java -version を実行してアプリが求める LTS の版がまだ使われているかを確認し、別の版に切り替わっていれば複数の Java の切り替え方と JAVA_HOME の設定に沿って元に戻してください。

PostgreSQL 16 から 18 へ: ひっそり取り残されるクラスター

Ubuntu 24.04 には PostgreSQL 16 が付属し、26.04 には PostgreSQL 18 が付属します。アップグレードでは 18 が 16 と並行してインストールされますが、データは移行されません。Debian の postgresql-common 層は、新しいメジャーバージョン用に空のクラスターを次に空いているポートで作成します。そのため、16 はすべてのデータを保持したまま 5432 番ポートを使い、18 は 5433 番ポートで空の状態になります。アプリケーションは引き続き 5432 番ポートへ接続するため、問題がないように見えます。数か月後にこの問題に気付く人が多いのはそのためです。

pg_lsclusters

クラスターが 2 つ表示される場合、移行は完了していません。アプリケーションを停止できるタイミングで移行してください。

sudo pg_upgradecluster 16 main
pg_lsclusters
sudo -u postgres vacuumdb --all --analyze-only

まず空の 18 クラスターを削除します。pg_upgradecluster は、移行先クラスターがすでに存在するとそこへ書き込めないためです。デフォルトの方式では、16 のデータをダンプして 18 に再読み込みします。そのため、データベースとほぼ同じ容量の空きディスク領域が必要です。-m upgrade は代わりに pg_upgrade を使用するため、大規模なデータベースでははるかに高速です。完了したら Port 列を確認します。新しいクラスターが 5432 番ポートを引き継ぎ、古いクラスターは停止した状態になります。新しく読み込んだクラスターには統計情報がないため、最初のクエリが遅くなります。自分で analyze 処理を実行してください。

数日間、新しいクラスターに対してアプリケーションをテストします。その後で古いクラスターを削除します。

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

古いクラスターのデータディレクトリは、最も迅速にロールバックできる手段です。アップグレード当日に削除しないでください。

MySQL 8.0 から 8.4 へ: 削除されたオプションでサーバーが停止する場合

26.04 では MySQL が 8.0 から 8.4 LTS に更新されます。このとき、2 つの変更によってサーバーが起動しなくなることがあります。

1 つ目は、設定に新しいバージョンで削除されたオプションが含まれていると、mysqld が起動を拒否することです。古いガイドの多くで設定が推奨されているため、default_authentication_plugin がよくある原因です。サービスは失敗し、journalctl -u mysql -n 50 に未知の変数が直接示されます。/etc/mysql/mysql.conf.d/ 配下のファイルからその行を削除し、その後 sudo systemctl start mysql を実行します。

2 つ目は、mysql_native_password プラグインが 8.4 ではデフォルトで有効にならないことです。このプラグインを引き続き使用しているアカウントは、まったくログインできません。8.0 のまま、次のコマンドで確認します。

sudo mysql -e "SELECT user, host, plugin FROM mysql.user;"

mysql_native_password と表示されたアカウントをすべてアップグレード前に移行し、アプリケーション設定のパスワードを更新します。

ALTER USER 'appuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'a new password';

クライアントライブラリが古すぎて caching_sha2_password に対応できない場合は、[mysqld] 配下に mysql_native_password=ON を追加すると、8.4 で古いプラグインを再度有効にできます。ただし、これは期限を定めた暫定措置として扱ってください。このプラグインは完全に廃止される予定です。

PHP 8.3 から 8.5 へ: vhost が消えたソケットを参照しています

24.04 には PHP 8.3 が含まれ、26.04 には PHP 8.5 が含まれます。パッケージはバージョン付きのパスにインストールされ、Web サーバーの設定は書き換えられません。fastcgi_pass unix:/run/php/php8.3-fpm.sock; を保持する nginx の vhost は、どのプロセスも作成しないソケットを参照するため、すべての PHP リクエストが 502 を返し、nginx のエラーログには次のように記録されます。

connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)

新しいソケットを参照するように変更し、設定をテストしてから reload します。

sudo sed -i 's/php8.3-fpm.sock/php8.5-fpm.sock/' /etc/nginx/sites-available/example.com
sudo nginx -t
sudo systemctl reload nginx

mod_php を使用する Apache では症状が異なります。Apache 自体が起動せず、sudo apache2ctl -t はファイルが存在しないため libphp8.3.so を読み込めないと報告します。有効化されたモジュールは、すでに削除されたパッケージへのシンボリックリンクです。

sudo a2dismod php8.3
sudo a2enmod php8.5
sudo systemctl restart apache2

Ubuntu 24.04 で LAMP スタックを構築してサーバーをセットアップした場合は、これら 2 つのパスを確認してください。このガイドでは、バージョン付きのモジュール名とバージョン付きのソケットが設定されるためです。

php.ini のチューニングも引き継がれません。memory_limit、upload_max_filesize、その他に設定した項目は /etc/php/8.3/ に保存され、新しいツリーはデフォルト値から始まります。2 つのファイルを diff で比較し、値を手動で移行してください。古いファイル全体を新しいファイルに上書きすると、8.3 のデフォルト値が 8.5 のインストールに持ち込まれます。続いて php -m を実行して比較します。php8.3-redis としてインストールされた拡張機能には php8.5- パッケージが必要です。PPA から導入した拡張機能の場合、アップグレーダーがそのソースを無効化しているため、拡張機能自体が不足していることがあります。

証明書については、別途 1 つ確認してください。アップグレード後に sudo certbot renew --dry-run を実行します。これは有効な証明書に変更を加えず、Web サーバーの reload hook を含む更新処理全体を実行します。サービス名や変更されたバイナリを呼び出す hook に問題があれば、60 日後に静かに失敗するのではなく、この場で確認できます。nginx で Certbot と Let's Encrypt を使用するでは、これらの hook の設定例を説明しています。

SSH: 作業中のセッションを終了させる障害

sshd_config プロンプトは、ログインできなくなる原因になりやすい箇所です。Y と答えると、maintainer のファイルがインストールされ、既存の PermitRootLogin、PasswordAuthentication、AllowUsers、Port および追加したその他すべての行が破棄されます。ファイアウォールがカスタムポートだけを許可し、パッケージ版の設定が 22 番ポートで待ち受ける場合、次の接続は拒否されます。現在使用しているセッションが、残された最後のセッションになります。

アップグレードの前に対策してください。24.04 の /etc/ssh/sshd_config は Include /etc/ssh/sshd_config.d/*.conf から始まります。OpenSSH は多くの設定で最初に読み込んだ値を保持するため、先頭で読み込まれる drop-in は、後方にある同じ設定より優先されます。一部のキーワードには例外があります。Port と ListenAddress は複数の値を受け付けるため、drop-in の Port 行は、下方で設定されたポートを置き換えず、ポートを追加します。設定を dpkg が管理しないファイルへ移してください。

sudo tee /etc/ssh/sshd_config.d/99-local.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy
EOF
sudo chmod 644 /etc/ssh/sshd_config.d/99-local.conf
sudo sshd -t && sudo systemctl restart ssh

/etc/ssh/sshd_config に自分の設定が残っていなければ、そのプロンプトは問題になりません。どちらを選んでも設定は保持されます。設定は別のファイルにあるためです。

カスタムポートを使用する場合は、想定している場所に設定されていない可能性があるため、もう 1 つ確認が必要です。

systemctl is-enabled ssh.socket

enabled と表示された場合、待ち受けポートを開いているのは sshd ではなく systemd です。Ubuntu は 22.10 以降、sshd で socket activation を使用しています。24.04 では、systemd の generator が sshd の設定から Port と ListenAddress の設定を読み取り、socket の listen address に変換します。ただし、systemd が unit を再読み込みした場合に限ります。そのため、Port 2222 を編集しても何も変わらないように見えます。変更は sudo systemctl daemon-reload && sudo systemctl restart ssh.socket の後に反映され、現在のパッケージ版 sshd_config にもその旨の注記があります。代わりに socket unit へ直接ポートを設定するには、sudo systemctl edit ssh.socket を使用します。

[Socket]
ListenStream=
ListenStream=2222

空の ListenStream= は必須です。継承した値を消去します。これがないと、socket は 2222 に加えて 22 でも待ち受けます。sudo systemctl daemon-reload && sudo systemctl restart ssh.socket で適用します。

アップグレード後、現在のセッションを閉じる前に、次を実行します。

sudo sshd -t
sudo systemctl status ssh.socket --no-pager
sudo ss -lntp | grep -E ':(22|2222)'

次に、自分のマシンで 2 つ目のターミナルを開き、もう一度ログインします。その 2 つ目のターミナルでシェルを使用できることだけが、確認の証拠になります。確認できるまで、最初のセッションは開いたままにしてください。VPS 上の SSH を強化する では、この drop-in に残す価値のある設定を説明しています。

すでに手遅れの場合は、プロバイダーの Web コンソールを使用すると、SSH を使わずにログインできます。そこからログインして設定を修正し、sudo sshd -t を実行して、サービスを再起動します。アップグレード中ではなく、アップグレード前にコンソールへアクセスできることをテストするのは、まさにそのためです。

FAQ

Ubuntu 24.04 で do-release-upgrade が「No new release found」と表示されるのはなぜですか？

2026年9月29日以降は、その表示は出ないはずです。この日に Canonical が 24.04 LTS から 26.04.1 へのアップグレードを有効にしたためです。それ以前は、このメッセージが表示されるのは想定どおりでした。Ubuntu 26.04 LTS は 2026年4月23日にリリースされ、26.04.1 は 8月27日に続いてリリースされました。その後、Canonical が rust-coreutils のリグレッションに対する修正をバックポートしている間、さらに数週間アップグレード経路が閉じられていました。まだ表示される場合は、/etc/update-manager/release-upgrades に Ubuntu Server のデフォルトである Prompt=lts が設定されていることを確認してください。これは次の長期サポートリリースだけを提示します。lts のままにしてください。Prompt=normal に変更すると、interim release を経由することになります。

アップグレードを完了するには、サーバーを再起動する必要がありますか？

はい。アップグレードでは新しい kernel、新しい C library、新しい init system がインストールされます。実行中のシステムは再起動するまで古いものを使い続けます。do-release-upgrade は最後に再起動を求めます。「後で」再起動するまで稼働させたマシンでは、2つの release の要素が混在した状態になります。再起動後は、uname -r で新しい kernel を確認し、systemctl --failed で起動しなかったサービスを確認してください。

その場でアップグレードすべきですか、それとも新しい 26.04 サーバーを構築すべきですか？

可能なら新しいサーバーを構築してください。新しい VPS なら、古いサーバーが引き続きトラフィックを処理している間に stack をインストールし、データを復元して、すべてをテストできます。そのため、ロールバックは backup からの復元ではなく DNS の変更で済みます。サーバーに移行が難しい state が保存されている場合、provider がマシン単位で課金する場合、または snapshot と実績のある console access がある場合は、その場でアップグレードしてください。その場でのアップグレード手順は広く確立されています。ただし、実行中の時間帯は一方向の変更になります。

アップグレード中に SSH 接続が切断されるとどうなりますか？

通常の login shell では、プロセスが SIGHUP を受け取って途中で終了し、dpkg が未設定の状態で残ります。tmux または screen の中で開始すればプロセスが維持されるため、再接続して tmux attach -t upgrade を実行すれば処理を再開できます。upgrader は別の接続経路として port 1022 で予備の SSH daemon も起動します。ただし、その port 用に firewall の設定は変更しないため、先に 1022 を自分で許可し、完了後に閉じてください。

アップグレード後に PHP サイトが 502 を返します。何が壊れたのでしょうか？

PHP FPM の socket path が version によって変わりました。Ubuntu 24.04 は PHP 8.3、26.04 は PHP 8.5 を実行するため、nginx vhost が指定している /run/php/php8.3-fpm.sock は存在しなくなっています。nginx の error log には connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory) が表示されます。fastcgi_pass を 8.5 の socket に更新し、sudo nginx -t を実行してから nginx を reload してください。mod_php を使う Apache の場合は、同等の修正として sudo a2dismod php8.3 を実行し、その後 sudo a2enmod php8.5 と restart を実行します。