Cara Upgrade Ubuntu 24.04 ke 26.04 di VPS

Kapan Ubuntu 24.04 dapat di-upgrade ke 26.04?

Anda dapat meng-upgrade Ubuntu 24.04 ke 26.04 pada VPS setelah rilis poin 26.04.1 dirilis, yang dijadwalkan pada 27 August 2026. Sebelum itu, server 24.04 tidak akan menampilkan rilis baru tersebut, dan ini memang disengaja. Ubuntu 26.04 LTS (Resolute Raccoon) dirilis pada 23 April 2026, tetapi Canonical baru membuka jalur upgrade LTS ke LTS pada rilis poin pertama karena rilis tersebut menggabungkan perbaikan bug instalasi dan upgrade yang ditemukan selama beberapa bulan pertama. Jika penomoran ini masih baru bagi Anda, 26.04.1 bukan Ubuntu yang berbeda, melainkan 26.04 yang sama dengan perbaikan selama empat bulan yang telah dimasukkan ke media, sehingga versi inilah yang pertama kali akan ditawarkan Canonical kepada server yang sudah ada.

Jalankan pemeriksaan pada mesin 24.04 pada awal August 2026. Hasilnya adalah sebagai berikut:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

Itu bukan kesalahan pada server Anda. /etc/update-manager/release-upgrades berisi Prompt=lts pada Ubuntu Server. Artinya, alat tersebut hanya menawarkan rilis long term support berikutnya, dan hanya setelah rilis poin .1 tersedia. Jika Anda menetapkan Prompt=normal, alat tersebut akan memandu Anda melalui 24.10, 25.04, dan 25.10 secara berurutan. Rilis interim tersebut semuanya sudah mencapai end of life. Biarkan tetap pada lts dan tunggu. Jadwal Canonical dapat berubah, jadi periksa kembali jika tanggal tersebut berlalu tanpa perubahan.

Setiap perintah di bawah ini harus Anda jalankan sendiri pada server Anda, sesuai urutan yang diberikan. Release upgrade tidak dapat diuji terlebih dahulu pada mesin yang sedang di-upgrade. Proses ini mengganti kernel dan C library, serta memerlukan reboot untuk menyelesaikannya.

Apakah Anda perlu melakukan upgrade?

Ubuntu 24.04 menerima pembaruan keamanan standar hingga 2029, jadi server produksi yang berfungsi baik tidak memiliki batas waktu untuk upgrade. Lakukan upgrade karena Anda memerlukan sesuatu yang tersedia di 26.04: PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2, atau kernel 7.0. “Versinya bertambah” bukan alasan untuk menyentuh mesin yang melayani pelanggan.

Jangan melakukan upgrade di tempat jika salah satu kondisi berikut berlaku:

• Anda belum pernah membuka console provider (VNC atau serial) dan login melalui console tersebut. Console itu adalah satu-satunya cara untuk kembali mengakses server jika SSH gagal. Mengetahui bahwa console tidak berfungsi setelah Anda terkunci di luar server sudah terlambat.
• Anda tidak dapat menanggung downtime selama satu jam dan tidak memiliki rollback.
• Stack Anda bergantung pada repository pihak ketiga yang belum menerbitkan paket untuk resolute.
• Server tersebut dibangun secara manual lebih dari dua tahun lalu dan tidak ada yang mengetahui apa saja yang terpasang di dalamnya.

Alternatifnya sering kali lebih baik: buat VPS 26.04 baru, instal stack Anda dan pulihkan datanya, lalu alihkan DNS setelah server baru memberikan respons dengan benar. Anda dapat mempertahankan server lama tetap berjalan sampai server baru terbukti berfungsi baik. Dengan demikian, rollback cukup dilakukan dengan mengubah DNS, bukan melalui restore. Jika memilih cara ini, mulai dari sepuluh menit pertama pada VPS baru dan bangun server baru tersebut dengan benar.

Langkah 1: buat cadangan yang dapat dipulihkan

Gunakan dua lapisan karena keduanya dapat gagal dengan cara yang berbeda. Snapshot dari provider mencakup seluruh disk dan dapat dipulihkan dalam hitungan menit, tetapi dibuat saat database sedang menulis data. Karena itu, snapshot tersebut konsisten terhadap crash, bukan konsisten terhadap aplikasi. Cadangan tingkat file dengan restic, yang disimpan di luar server menyediakan file individual dan salinan yang tetap tersedia jika akun Anda dikunci.

Buat dump database secara manual terlebih dahulu. Dump adalah satu-satunya cadangan database yang dapat Anda percaya tanpa menghentikan database.

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 hanya membuat dump yang konsisten untuk tabel InnoDB. Database harus dihentikan jika berisi tabel MyISAM. Tarball /etc adalah berkas yang akan paling sering Anda gunakan karena berisi semua file konfigurasi yang akan ditanyakan oleh proses upgrade.

Cadangan yang belum pernah Anda pulihkan hanyalah perkiraan. Ambil satu file dari cadangan tersebut sekarang, sebelum Anda membutuhkannya dalam kondisi tertekan.

Langkah 2: selesaikan patch 24.04 terlebih dahulu

do-release-upgrade menolak berjalan pada sistem dengan status paket yang rusak. 24.04 yang baru dipatch sebagian membuat setiap kegagalan berikutnya lebih sulit dianalisis.

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

dpkg --audit yang tidak menampilkan apa pun berarti tidak ada paket yang dikonfigurasi sebagian. apt-mark showhold yang tidak menampilkan apa pun berarti tidak ada paket yang dikunci pada versi yang dapat menghambat upgrade. Lepaskan setiap paket yang tercantum dengan sudo apt-mark unhold dan nama paket, atau terima bahwa penahanan tersebut memiliki alasan dan hentikan proses di sini.

Lakukan reboot jika kernel berubah. Dengan begitu, upgrade berjalan pada mesin yang menggunakan kode yang dianggap sedang dijalankannya.

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

Kemudian periksa ruang disk. Upgrader mengunduh seluruh kumpulan paket baru sebelum memasang apa pun. Jika ruang tidak cukup, proses akan dibatalkan dengan pesan yang menyebutkan filesystem terkait.

df -h / /boot

Jika ruang kosong pada / kurang dari sekitar 5 GB, proses biasanya gagal pada tahap ini. /boot yang berukuran kurang dari 300 MB akan menyebabkan kegagalan berikutnya saat instalasi kernel, dengan pesan No space left on device. Kernel lama biasanya menjadi penyebabnya, dan sudo apt --purge autoremove akan menghapusnya.

Ada satu hal lagi yang harus dihentikan sebelum memulai. Jika pembaruan keamanan otomatis berjalan di tengah proses, pembaruan tersebut akan menahan dpkg lock dan release upgrader berhenti dengan Could not get lock /var/lib/dpkg/lock-frontend. Jalankan sudo systemctl stop unattended-upgrades terlebih dahulu, lalu mulai ulang proses setelah selesai.

Langkah 3: periksa repositori pihak ketiga dan paket yang dipin

do-release-upgrade menonaktifkan setiap sumber apt yang bukan berasal dari Ubuntu, karena paket yang dibuat untuk noble dapat merusak sistem resolute. Setelah itu, do-release-upgrade mengaktifkan kembali sumber yang dikenali dan membiarkan sumber lainnya tetap dinonaktifkan. Pahami konfigurasi yang Anda gunakan sebelum alat tersebut menentukannya untuk Anda.

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 menggunakan dua format di direktori tersebut: file .list satu baris dalam format lama, dan file .sources deb822 dengan field Types: dan Suites:. Keduanya dinonaktifkan oleh proses upgrade. ubuntu-security-status --thirdparty mencantumkan paket terinstal yang tidak disediakan oleh arsip Ubuntu mana pun. Ini adalah jumlah aktual paket tambahan yang Anda pasang. Apa pun yang tercantum dalam /etc/apt/preferences.d/ adalah pin. Pin yang ditulis untuk noble akan terus memilih paket lama pada rilis baru.

Untuk setiap repositori pihak ketiga, pastikan vendor telah menerbitkan repositori untuk codename baru sebelum memulai. Daftar suite Docker tersedia di https://download.docker.com/linux/ubuntu/dists/, dan vendor lain menyediakan direktori dengan struktur yang sama. Sumber yang diarahkan ke suite yang tidak tersedia akan menghasilkan keluaran berikut pada apt update pertama setelah upgrade:

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

Biarkan sumber tersebut tetap dinonaktifkan hingga vendor menerbitkannya. Mengubah codename ke codename yang memang didukung vendor dapat menyebabkan Anda memasang paket yang ditautkan ke library sistem yang salah.

Langkah 4: jalankan upgrade di tmux, bukan dalam shell SSH biasa

Jika koneksi Anda terputus saat do-release-upgrade berjalan dalam shell login biasa, proses tersebut menerima SIGHUP dan berhenti di tengah proses unpacking. Akibatnya, dpkg berada dalam kondisi konfigurasi setengah selesai, dan server mungkin tidak lagi memiliki network stack yang berfungsi untuk menerima koneksi ulang. Jalankan proses tersebut di dalam terminal multiplexer agar tetap berjalan di server saat client Anda terputus.

sudo apt install -y tmux
tmux new -s upgrade

Di dalam sesi tersebut:

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

Proses upgrader memulai SSH daemon kedua pada port 1022 sebelum mengubah apa pun, dan menampilkan informasi tersebut:

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.

Proses tersebut tidak membuka firewall untuk port itu karena membuka akses firewall tanpa meminta persetujuan akan menimbulkan perubahan yang tidak diharapkan. Buka port 1022 sendiri sebelum memulai, lalu tutup kembali setelah selesai menjalankan sudo ufw delete allow 1022/tcp. Ingat bahwa provider Anda mungkin menjalankan firewall kedua di control panel, di luar server.

Jika koneksi tetap terputus, login kembali dan jalankan tmux attach -t upgrade. Proses upgrade tetap berjalan selama Anda terputus.

Langkah 5: tangani prompt file konfigurasi dengan cermat

dpkg hanya menampilkan prompt untuk file yang Anda atau sebuah script ubah. Karena itu, setiap prompt tersebut berkaitan dengan file yang sengaja Anda edit. Menekan enter agar prompt hilang dapat membuat server yang telah diperkuat diam-diam kembali menggunakan konfigurasi default.

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] ?

Tekan D terlebih dahulu, setiap kali. Periksa perubahan, lalu pertahankan versi Anda dengan N. Default-nya sudah berupa N, dan itu adalah jawaban yang aman karena file Anda saat ini berfungsi, sedangkan file dari paket belum pernah dijalankan pada mesin ini.

Mempertahankan file Anda memiliki konsekuensi: Anda tidak mendapatkan default baru. Bandingkan dan selaraskan setelahnya, setelah server aktif dan Anda tidak sedang berada di bawah tekanan waktu.

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

Setiap file yang tercantum adalah versi maintainer yang disimpan di samping file Anda. Bandingkan keduanya satu per satu, lalu salin pengaturan yang penting. Dua hal memerlukan perhatian khusus: /etc/ssh/sshd_config, karena jawaban yang salah akan mengakhiri sesi Anda, dan konfigurasi web server, karena jawaban yang salah akan membuat situs tidak aktif.

Upgrade tersebut juga menanyakan service mana yang harus di-restart melalui needrestart. Terima seluruh daftar. Daemon yang masih berjalan menggunakan file shared library yang telah dihapus dari disk dapat mengalami crash saat menangani request berikutnya, ketika Anda tidak sedang memantaunya.

Langkah 6: reboot, lalu periksa mesin

sudo reboot

Setelah mesin kembali aktif:

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 harus melaporkan Release: 26.04 dan Codename: resolute. uname -r harus menampilkan kernel 7.0. systemctl --failed harus mencantumkan unit sebanyak nol, dan apa pun yang tercantum menjadi tugas Anda berikutnya. apt update terakhir mengambil pembaruan yang diterbitkan sejak image rilis dibuat.

PostgreSQL 16 ke 18: cluster yang diam-diam tertinggal

Ubuntu 24.04 menyediakan PostgreSQL 16, sedangkan 26.04 menyediakan PostgreSQL 18. Proses upgrade menginstal 18 berdampingan dengan 16 dan tidak memindahkan data Anda. Layer postgresql-common Debian membuat cluster kosong baru untuk major version baru pada port berikutnya yang tersedia. Dengan demikian, 16 tetap menggunakan port 5432 beserta seluruh data Anda, sedangkan 18 berada dalam keadaan kosong pada port 5433. Aplikasi Anda tetap terhubung ke 5432 dan tidak ada masalah yang terlihat. Karena itu, banyak orang baru menyadarinya beberapa bulan kemudian.

pg_lsclusters

Jika terdapat dua cluster dalam daftar, berarti Anda belum melakukan migrasi. Lakukan migrasi saat aplikasi dapat dihentikan:

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

Hapus cluster 18 yang kosong terlebih dahulu karena pg_upgradecluster tidak akan menulis ke cluster target yang sudah ada. Metode default mencadangkan 16 lalu memuatnya kembali ke 18, sehingga Anda memerlukan ruang disk kosong kira-kira sebesar ukuran database. -m upgrade menggunakan pg_upgrade dan jauh lebih cepat pada database berukuran besar. Setelah selesai, baca kolom Port: cluster baru mengambil alih port 5432, sedangkan cluster lama dibiarkan dalam keadaan berhenti. Jalankan proses analyze sendiri karena cluster yang baru dimuat belum memiliki statistik dan query pertama akan berjalan lambat.

Uji aplikasi pada cluster baru selama beberapa hari. Setelah itu, hapus cluster lama:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

Direktori data cluster lama adalah sarana rollback tercepat yang Anda miliki. Jangan menghapusnya pada hari upgrade.

MySQL 8.0 ke 8.4: opsi yang dihapus dan membuat server berhenti

26.04 memutakhirkan MySQL dari 8.0 ke 8.4 LTS, dan dua perubahan dapat membuat server bermasalah.

Pertama, mysqld menolak start jika konfigurasinya berisi opsi yang dihapus pada versi baru. default_authentication_plugin adalah opsi yang paling umum karena banyak panduan lama menyarankan Anda untuk mengaturnya. Service gagal start, dan journalctl -u mysql -n 50 menyebutkan variabel yang tidak dikenal tersebut secara langsung. Hapus baris itu dari file di bawah /etc/mysql/mysql.conf.d/, lalu sudo systemctl start mysql.

Kedua, plugin mysql_native_password tidak lagi diaktifkan secara default pada 8.4, sehingga akun yang masih menggunakannya sama sekali tidak dapat login. Periksa saat Anda masih menggunakan 8.0:

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

Migrasikan setiap akun yang menampilkan mysql_native_password sebelum upgrade, lalu perbarui password pada konfigurasi aplikasi Anda:

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

Jika library client terlalu lama untuk menggunakan caching_sha2_password, Anda dapat mengaktifkan kembali plugin lama tersebut pada 8.4 dengan menambahkan mysql_native_password=ON di bawah [mysqld]. Gunakan ini hanya sebagai solusi sementara dengan batas waktu, karena plugin tersebut akan dihentikan sepenuhnya.

PHP 8.3 hingga 8.5: vhost Anda mengarah ke socket yang sudah tidak ada

24.04 menyertakan PHP 8.3, sedangkan 26.04 menyertakan PHP 8.5. Paket dipasang ke path yang memiliki nomor versi, dan tidak ada proses yang menulis ulang konfigurasi web server Anda. vhost nginx yang berisi fastcgi_pass unix:/run/php/php8.3-fpm.sock; kini mengarah ke socket yang tidak dibuat oleh proses apa pun. Akibatnya, setiap permintaan PHP mengembalikan 502, dan log error nginx berisi:

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

Arahkan ke socket baru, uji konfigurasi, lalu lakukan 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

Pada Apache dengan mod_php, gejalanya berbeda. Apache sama sekali tidak dapat start, dan sudo apache2ctl -t melaporkan bahwa libphp8.3.so tidak dapat dimuat karena file tersebut tidak ada. Modul yang diaktifkan adalah symlink ke paket yang sudah tidak tersedia.

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

Jika Anda membuat server berdasarkan stack LAMP pada Ubuntu 24.04, kedua path tersebut perlu diperiksa karena panduan itu menggunakan nama modul dan socket yang memiliki nomor versi.

Konfigurasi tuning php.ini Anda juga tidak ikut berpindah. memory_limit, upload_max_filesize, dan pengaturan lain yang Anda tetapkan berada di /etc/php/8.3/, sedangkan tree baru dimulai dengan nilai default. Bandingkan kedua file tersebut, lalu salin nilainya secara manual. Menyalin seluruh file lama ke file baru akan membawa nilai default 8.3 ke instalasi 8.5. Setelah itu, jalankan php -m dan bandingkan hasilnya. Ekstensi yang dipasang sebagai php8.3-redis memerlukan paket php8.5-. Jika ekstensi tersebut berasal dari PPA, upgrader menonaktifkan sumber itu sehingga ekstensi tersebut tidak tersedia.

Sertifikat memerlukan pemeriksaan tersendiri. Jalankan sudo certbot renew --dry-run setelah upgrade. Perintah ini menguji seluruh jalur pembaruan, termasuk hook reload web server, tanpa mengubah sertifikat yang sedang digunakan. Hook yang memanggil nama service atau binary yang telah berubah akan gagal pada tahap ini dan terlihat langsung, bukan gagal secara diam-diam setelah 60 hari. Certbot dengan Let's Encrypt pada nginx menjelaskan bentuk hook tersebut.

SSH: kegagalan yang mengakhiri sesi yang sedang Anda gunakan

Prompt sshd_config adalah tempat pengguna dapat terkunci dari server. Menjawab Y memasang file milik maintainer, yang membuang PermitRootLogin, PasswordAuthentication, AllowUsers, Port, dan setiap baris lain yang Anda tambahkan. Jika firewall Anda hanya mengizinkan port khusus, sedangkan konfigurasi dari paket listen pada 22, koneksi berikutnya akan ditolak dan sesi yang sedang Anda gunakan menjadi sesi terakhir yang Anda miliki.

Cegah masalah ini sebelum upgrade. /etc/ssh/sshd_config pada 24.04 diawali dengan Include /etc/ssh/sshd_config.d/*.conf, dan OpenSSH mempertahankan nilai pertama yang dibacanya untuk setiap pengaturan. Jadi, drop-in yang disertakan di bagian atas akan mengalahkan semua pengaturan di bawahnya. Pindahkan pengaturan Anda ke file yang tidak dimiliki 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

Setelah tidak ada lagi konfigurasi Anda di /etc/ssh/sshd_config, prompt tersebut tidak lagi penting. Apa pun jawaban Anda, pengaturan tetap dipertahankan karena berada di file lain.

Port khusus memerlukan satu pemeriksaan tambahan karena port tersebut mungkin tidak berada di lokasi yang Anda perkirakan:

systemctl is-enabled ssh.socket

Jika perintah tersebut menampilkan enabled, systemd mengelola port yang sedang listen, dan baris Port di sshd_config diabaikan. Ubuntu telah menggunakan socket activation untuk sshd sejak 22.10. Inilah sebabnya perubahan pada Port 2222 tampaknya tidak berpengaruh. Tetapkan port tersebut pada unit socket dengan sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

ListenStream= yang kosong wajib ada. Nilai yang diwarisi akan dihapus. Tanpa nilai tersebut, socket juga akan listen pada 22 selain 2222. Terapkan dengan sudo systemctl daemon-reload && sudo systemctl restart ssh.socket.

Setelah upgrade, sebelum menutup sesi yang sedang Anda gunakan:

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

Kemudian buka terminal kedua pada komputer Anda dan login kembali. Shell yang berfungsi pada terminal kedua adalah satu-satunya bukti yang dapat diandalkan. Biarkan sesi pertama tetap terbuka sampai Anda berhasil masuk. Memperkuat SSH pada VPS membahas pengaturan yang sebaiknya dipertahankan dalam drop-in tersebut.

Jika sudah terlambat, web console dari provider Anda menyediakan login yang tidak menggunakan SSH sama sekali. Login melalui console tersebut, perbaiki konfigurasi, jalankan sudo sshd -t, lalu restart service. Console itulah alasan Anda harus menguji akses console sebelum upgrade, bukan saat upgrade berlangsung.

FAQ

Mengapa do-release-upgrade menampilkan "No new release found" di Ubuntu 24.04?

Karena /etc/update-manager/release-upgrades berisi Prompt=lts pada Ubuntu Server, dan pengaturan tersebut hanya menawarkan rilis long term support berikutnya setelah point release pertamanya tersedia. Ubuntu 26.04 LTS dirilis pada 23 April 2026, dan 26.04.1 dijadwalkan pada 27 August 2026. Hingga tanggal tersebut, server 24.04 tidak akan menemukan rilis baru. Biarkan pengaturan tersebut apa adanya, jangan menggantinya ke Prompt=normal, karena penggantian itu akan mengarahkan proses melalui interim release.

Apakah saya harus me-reboot server untuk menyelesaikan upgrade?

Ya. Upgrade memasang kernel baru, library C baru, dan sistem init baru. Sistem yang sedang berjalan tetap menggunakan versi lama hingga di-restart. do-release-upgrade meminta reboot pada akhir proses. Mesin yang dibiarkan berjalan hingga "nanti" berarti masih menjalankan campuran dari dua rilis. Setelah server kembali aktif, periksa uname -r untuk melihat kernel baru dan systemctl --failed untuk menemukan service yang tidak berhasil berjalan kembali.

Sebaiknya saya melakukan upgrade in-place atau membuat server 26.04 baru?

Buat server baru jika memungkinkan. VPS baru memungkinkan Anda memasang stack, memulihkan data, dan menguji semuanya saat server lama masih melayani trafik. Dengan demikian, rollback cukup dilakukan melalui perubahan DNS, bukan pemulihan dari backup. Lakukan upgrade in-place jika server menyimpan state yang sulit dipindahkan, provider menagih biaya per mesin, atau Anda memiliki snapshot dan akses console yang sudah teruji. Proses in-place sudah umum dilakukan, tetapi selama proses berlangsung, Anda tidak dapat kembali dengan mudah.

Apa yang terjadi jika koneksi SSH saya terputus selama upgrade?

Dalam login shell biasa, proses menerima SIGHUP lalu berhenti di tengah proses. Akibatnya, dpkg berada dalam kondisi terkonfigurasi sebagian. Jalankan proses di dalam tmux atau screen agar proses tetap berjalan. Setelah terhubung kembali, jalankan tmux attach -t upgrade untuk melanjutkannya. Upgrader juga menjalankan SSH daemon cadangan pada port 1022 sebagai jalur masuk kedua. Namun, upgrader tidak membuka firewall untuk port tersebut. Karena itu, izinkan port 1022 terlebih dahulu, lalu tutup kembali setelah selesai.

Situs PHP saya mengembalikan 502 setelah upgrade. Apa yang rusak?

Path socket PHP FPM berubah sesuai versinya. Ubuntu 24.04 menjalankan PHP 8.3, sedangkan 26.04 menjalankan PHP 8.5. Karena itu, /run/php/php8.3-fpm.sock sudah tidak ada, sementara vhost nginx Anda masih merujuk ke path tersebut. Log error nginx menampilkan connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory). Perbarui fastcgi_pass agar menggunakan socket versi 8.5, jalankan sudo nginx -t, lalu reload nginx. Pada Apache dengan mod_php, perbaikan yang setara adalah sudo a2dismod php8.3, kemudian sudo a2enmod php8.5 dan restart.