Sunucuda Ubuntu 24.04 mü 26.04 mü? Yükseltme Kararını Nasıl Vermeli

Sunucuya SSH ile bağlandığınızda giriş ekranında yeni bir satır belirdi:

New release '26.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

Parmağınız Enter'ın üstünde duruyor. Bir yanda "sistemi güncel tutmak" refleksi, diğer yanda üzerinde üç yıldır sorunsuz çalışan bir e-ticaret sitesi, bir PostgreSQL örneği ve müşteriye söz verilmiş bir uptime var. Sorunun teknik kısmı zaten çözülmüş durumda: komutu nasıl çalıştıracağınızı Ubuntu Server sürüm yükseltme yazısında adım adım bulabilirsiniz. Buradaki soru daha zor olanı: çalıştırmalı mısınız, ne zaman ve gerçekten tek seçeneğiniz bu mu?

Yaygın yanlış varsayım şudur: "yeni LTS çıktı, demek ki geçme zamanı geldi." Oysa Ubuntu'nun kendi tasarımı bunun tersini söyler. Yükseltme yolu sürümün çıkışında değil, ilk nokta sürümünde açılır — çünkü Canonical'ın kendisi de ilk birkaç ayı bir stabilizasyon dönemi olarak kabul eder. Bu yazının çıkış noktası da bu: bir sürümün var olması, sizin ona geçmeniz gerektiği anlamına gelmez.

Aşağıda önce takvimi netleştirecek, sonra 24.04'ten 26.04'e geçerken beraberinde gelen paket sıçramalarının uygulamanızı nasıl kırabileceğini somutlaştıracak, ardından çoğu rehberin hiç bahsetmediği üçüncü seçeneği — yükseltmeyip mevcut LTS'te kalmayı — masaya koyacağız. Son bölüm ise en pratik kısmı: üretimde çoğu zaman yerinde yükseltmeden daha kısa kesintiyle biten "temiz kurup taşıma" yaklaşımı.

Ubuntu 26.04 Ne Zaman Çıktı, Yükseltme Yolu Ne Zaman Açıldı#

Ubuntu 26.04 LTS, kod adıyla "Resolute Raccoon", 23 Nisan 2026'da yayımlandı. Depo takma adı (suite) resolute; bu detayı aklınızda tutun, üçüncü parti depolar bölümünde işinize yarayacak.

Ancak 24.04 kullanan bir sunucuya yükseltme teklifi o gün gelmedi. Ubuntu, LTS'ten LTS'e geçişi ilk nokta sürümüne kadar kapalı tutar; 26.04.1 takvime göre 4 Ağustos 2026'da yayımlandı ve yol o zaman açıldı. Yani bu satırları okuduğunuzda teklif yeni geldi, üzerinden aylar geçmedi.

Bu bekleme keyfi değil. İlk dört ayda toplanan hata raporları, sürücü düzeltmeleri ve kritik paket güncellemeleri nokta sürüme girer. Ubuntu'nun kendi mekanizmasının size söylediği şey açıktır: yeni LTS, çıkışında üretim sunucusu için hazır kabul edilmez. Aynı mantığı bir adım ileri götürmek de meşrudur — pek çok deneyimli yönetici bir sonraki nokta sürümü olan 26.04.2'yi (yaklaşık altı ay sonrasını) bekler.

Sisteminizin durumunu ve size ne teklif edildiğini şu komutlarla görebilirsiniz:

# Hangi sürümdesiniz, depo takma adınız ne
lsb_release -ds
grep -E '^(VERSION_ID|VERSION_CODENAME)=' /etc/os-release

# Yalnızca kontrol et, hiçbir şey yapma
do-release-upgrade -c

# Teklifin davranışını belirleyen ayar
grep -v '^#' /etc/update-manager/release-upgrades

Son dosyadaki Prompt değeri üç seçenek alır: lts (yalnızca LTS'ten LTS'e teklif et — sunucular için varsayılan), normal (ara sürümleri de teklif et) ve never. Beklemeye karar verdiyseniz never yazmak, her SSH girişinde aynı satırı görüp bir gün dalgınlıkla Enter'a basma riskini ortadan kaldırır.

Bir de sık atlanan kural var: LTS'ten LTS'e geçiş tek adımlıdır. 22.04'teyseniz doğrudan 26.04'e gidemezsiniz; önce 24.04'e, sonra 26.04'e geçmeniz gerekir. Bu, iki ayrı bakım penceresi ve iki ayrı risk demektir — kararınızı verirken hesaba katın.

Aciliyetiniz Hangi Sürümde Olduğunuza Bağlı#

"Yükseltmeli miyim?" sorusunun cevabı büyük ölçüde takvimde saklı. Ubuntu LTS sürümleri beş yıl standart güvenlik bakımı alır; Ubuntu Pro aboneliğiyle bu süre genişletilmiş güvenlik bakımına (ESM) uzar.

Tablodan çıkan üç farklı durum var:

22.04 kullanıyorsanız gerçek bir aciliyet var. Standart bakımın bitmesine yaklaşık dokuz ay kaldı. Bu tarihten sonra ana depodaki paketler için ücretsiz güvenlik yaması gelmez. Planınızı şimdi yapın; hedefiniz 26.04 değil 24.04 olsun, çünkü tek adım kuralı geçerli ve 24.04 dört yıldan uzun destek sunuyor.

24.04 kullanıyorsanız aciliyet yok. Mayıs 2029'a kadar tam destek altındasınız. Yükseltmeyi bugün yapmanın tek gerekçesi teknik bir ihtiyaç olmalı: yeni çekirdeğin desteklediği bir donanım, uygulamanızın zorunlu kıldığı bir PHP veya Python sürümü, ya da yeni bir sistem kütüphanesi. Bunlardan hiçbiri yoksa acele etmenin karşılığı sadece risktir.

26.04'e yeni kurulum yapıyorsanız durum farklıdır. Sıfırdan kurulan bir sunucuda yükseltme riski yoktur; test edip beğenirseniz doğrudan 26.04 ile başlamak, ömrü en uzun seçenektir. Karar kriterleri için sunucu için doğru Linux dağıtımını seçme yazısı yardımcı olur.

24.04'ten 26.04'e Geçerken Gerçekte Neler Değişiyor#

Sürüm yükseltmesi bir çekirdek güncellemesi değildir; altınızdaki tüm yazılım yığınının ana sürümü aynı anda değişir. Ubuntu 24.04 ile 26.04 arasında iki ara sürüm (24.10, 25.04, 25.10) bulunduğu için birikmiş fark hatırı sayılır:

Tablodaki her satır tek başına yönetilebilir. Tehlikeli olan, hepsinin aynı gece ve aynı anda değişmesidir. Bir uygulama bozulduğunda hangi sıçramanın sorumlu olduğunu ayıklamak, baskı altındayken en zor iştir.

PHP 8.3'ten 8.5'e: İki Minör Sürüm Birden#

En çok siteyi bu satır kırar. 24.04'ün sistem PHP'si 8.3, 26.04'ünki 8.5 — yani 8.4 tamamen atlanır. PHP'de tipik ilerleme şudur: bir kullanım önce deprecated uyarısı verir, bir sonraki sürümde ölümcül hataya döner. İki sürüm birden atladığınızda uyarı aşamasını hiç görmez, doğrudan beyaz ekranla karşılaşırsınız.

Somut bir örnek: PHP 8.4 ile örtük nullable parametre tipi (function f(Foo $x = null)) kullanımdan kaldırıldı; doğrusu ?Foo $x = null yazmaktır. Eski bir Composer bağımlılığında duran böyle bir imza, güncelleme sırasında logları uyarıyla doldurur.

Yükseltmeden önce kodunuzu hedef sürümde çalıştırın. Sistem PHP'sine bağımlı kalmak yerine PHP sürümünü işletim sisteminden ayırmak da geçerli bir stratejidir; bu durumda OS yükseltmesi PHP'nizi zorlamaz. Yaklaşımın ayrıntısı PHP sürüm yönetimi yazısında.

# Hangi PHP sürümü nereden geliyor
apt policy php8.3-fpm
php -v

# Kurulu PHP eklentilerini not alın; hedef sürümde hepsi olmayabilir
dpkg -l | grep -E '^ii\s+php[0-9.]+-' | awk '{print $2}'

MySQL 8.0'dan 8.4 LTS'e: Eski Parola Eklentisi#

MySQL 8.4'te mysql_native_password kimlik doğrulama eklentisi varsayılan olarak devre dışıdır. Eski bir uygulama ya da eski bir istemci kütüphanesi bu eklentiyle oluşturulmuş bir kullanıcıyla bağlanmaya çalıştığında bağlantı reddedilir. Belirti tanıdıktır: siteniz "veritabanına bağlanılamıyor" der, mysql komut satırından bağlanmak ise çalışır.

Geçici çözüm eklentiyi açmaktır:

# /etc/mysql/mysql.conf.d/uyumluluk.cnf
[mysqld]
mysql_native_password=ON

Kalıcı çözüm ise kullanıcıları modern eklentiye taşımaktır (ALTER USER ... IDENTIFIED WITH caching_sha2_password BY '...'), çünkü eski eklenti sonraki MySQL sürümlerinde tamamen kaldırılıyor.

Replikasyon kullanıyorsanız ikinci bir konu var: 8.4 ile eski terminolojiyi kullanan komutlar kaldırıldı. CHANGE MASTER TO artık çalışmaz, yerine CHANGE REPLICATION SOURCE TO geçti. Otomasyon betiklerinizde bu komut geçiyorsa yükseltme sonrası replikasyon sessizce kurulamaz.

Python 3.12'den 3.14'e ve Sanal Ortamlar#

Python'un ana sürümü değiştiğinde, o sürüme göre derlenmiş C uzantıları çalışmaz. venv ile oluşturduğunuz sanal ortamlar sistem Python'una sembolik bağla bağlıdır; sürüm değişince ortam bozulur ve ModuleNotFoundError ile karşılaşırsınız. Çözüm ortamı silip yeniden oluşturmak ve bağımlılıkları yeniden kurmaktır — ama bu, requirements.txt dosyanızın gerçekten eksiksiz olmasını gerektirir. Yükseltmeden önce pip freeze > requirements-yedek.txt almayı unutmayın.

Üçüncü Parti Depolar: "resolute" Yoksa Yükseltme Yarım Kalır#

Yerinde yükseltmelerin en yaygın çıkmazı burasıdır. do-release-upgrade, tanımadığı depoları devre dışı bırakır ve o depolardan gelen paketleri ya eski sürümde bırakır ya da kaldırır. Sonuç: yükseltme "başarıyla" biter, ama Node.js sürümünüz düşmüştür veya Docker gitmiştir.

Sorumlu genellikle şunlardan biridir: ondrej/php PPA, NodeSource, Docker'ın kendi deposu, PostgreSQL'in PGDG deposu, MongoDB, Grafana, bir izleme ajanı. Bunların resolute takma adı için paket yayınlaması zaman alır; bazıları hiç yayınlamaz.

Yükseltmeden önce her deponun hedef sürümü destekleyip desteklemediğini tek tek doğrulayın:

# Klasik .list ve yeni deb822 .sources dosyalarındaki tüm URI'leri çıkar
grep -rhoE '^deb\s+(\[[^]]*\]\s+)?\S+' /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>/dev/null
grep -rh '^URIs:' /etc/apt/sources.list.d/*.sources 2>/dev/null

# Bir deponun resolute yayınlayıp yayınlamadığını sor
curl -sI https://ppa.launchpadcontent.net/ondrej/php/ubuntu/dists/resolute/Release | head -1

200 OK dönerse depo hazırdır. 404 dönerse iki seçeneğiniz vardır: yükseltmeyi erteleyin ya da o bileşeni farklı bir yoldan (resmi depo, konteyner, kaynaktan derleme) sağlamayı planlayın. Depo yapısı ve apt policy kullanımını tazelemek isterseniz apt paket yönetimi yazısı iyi bir başvuru.

APT 3.x'e geçişin de ayrı bir yan etkisi var: çıktı formatı yenilendi. apt komutu zaten "kararlı bir komut satırı arayüzü değildir" uyarısını basar; çıktısını grep ile ayrıştıran izleme betikleriniz varsa apt-get ve makine okunur seçeneklere geçirin.

Panel Kullanıyorsanız Kararı Siz Vermiyorsunuz#

Sunucunuzda cPanel, Plesk veya benzeri bir kontrol paneli varsa yukarıdaki tartışmanın çoğu geçersizdir. Karar sizin değil, panelin destek matrisinindir.

cPanel & WHM aynı anda yalnızca tek bir Ubuntu LTS sürümünü destekler; yeni bir LTS nitelendirildiğinde bir öncekini kullanımdan kaldırır. Bu satırların yazıldığı tarihte desteklenen sürüm 24.04'tür ve 26.04 henüz desteklenmemektedir. Plesk tarafında da durum benzer: 26.04 desteği yol haritasında bekliyor, henüz üretim için yayımlanmadı.

Bunun anlamı nettir: panelli bir sunucuda do-release-upgrade çalıştırmak, çalışan bir kurulumu desteklenmeyen bir zemine taşımaktır. Panel güncellemeleri durur, destek talepleriniz "desteklenmeyen işletim sistemi" gerekçesiyle kapanır ve geri dönüş için elinizde yalnızca snapshot kalır. Panel satıcısı resmî desteği duyurana kadar bekleyin — ve duyurduğunda bile, kendi belgelerindeki yükseltme prosedürünü izleyin, genel Ubuntu prosedürünü değil.

Üçüncü Seçenek: Yükseltmeyin, Ubuntu Pro ile Bekleyin#

Çoğu rehber soruyu ikili sunar: yükselt ya da desteksiz kal. Üçüncü bir yol var ve pek çok üretim sunucusu için en akılcısı budur.

Ubuntu Pro, LTS sürümlerinin beş yıllık standart bakımını genişletilmiş güvenlik bakımıyla on yıla çıkarır ve kapsamı yalnızca ana depoya değil, universe deposundaki paketlere de yayar. Kişisel kullanımda beş makineye kadar ücretsizdir (resmî Ubuntu topluluk üyeleri için bu sınır elliye çıkar); ticari kullanımda sunucu başına yıllık ücretlendirilir ve tek bir plansız kesintinin maliyetiyle karşılaştırıldığında çoğu zaman ucuz kalır.

# Mevcut durum: hangi servisler açık, kaç paket ESM kapsamında
pro status --all
pro security-status

# Token ile bağla ve genişletilmiş bakımı aç
sudo pro attach <TOKEN>
sudo pro enable esm-infra esm-apps

Ancak kapsamı doğru anlayın. ESM size güvenlik yaması verir; yeni sürüm vermez. Uygulamanız PHP 8.4 veya Python 3.13 gerektiriyorsa Ubuntu Pro bunu çözmez — o ihtiyaç yükseltmeyi ya da bileşeni sistem dışından sağlamayı zorunlu kılar. Pro'nun çözdüğü sorun tektir ve önemlidir: "destek bitiyor" baskısıyla aceleye getirilmiş bir yükseltmeyi gereksiz kılmak.

Beklemeye karar verdiyseniz iki şeyi de yerine getirin: Prompt=never ile MOTD teklifini kapatın ve otomatik güvenlik güncellemelerinin gerçekten çalıştığını doğrulayın; kurulumu unattended-upgrades ile otomatik güncelleme yazısında anlattık. Beklemek, ihmal etmek değildir.

Yerinde Yükseltme mi, Temiz Kurup Taşıma mı?#

Yükseltmeye karar verdiniz. Şimdi asıl kritik seçim geliyor ve deneyimli yöneticilerin cevabı çoğu zaman sezgiye ters düşer.

Yerinde yükseltme "tek gecede biter" göründüğü için tercih edilir, ama bu görünüş yanıltıcıdır: süre öngörülemezdir ve işlem başladıktan sonra durup düşünme lüksünüz yoktur. Temiz kurulum hazırlığı uzun sürer, buna karşılık kesintinin tamamı sizin kontrolünüzdedir ve her adımı canlıya dokunmadan doğrularsınız.

Pratik akış şöyledir: yeni bir sunucu açıp 26.04 kurun, uygulamayı ve veritabanını taşıyın, /etc/hosts dosyanıza yeni IP'yi yazarak siteyi kendi bilgisayarınızdan gerçek alan adıyla test edin, her şey doğrulandığında alan adının TTL değerini birkaç saat önceden 300 saniyeye düşürün, DNS kaydını çevirin ve eski sunucuyu en az bir hafta kapatmadan bekletin. Bir sorun çıkarsa yaptığınız tek şey DNS'i geri çevirmek olur.

Yerinde yükseltmeyi tercih etmeniz gereken durumlar da var: IP adresinin değişmemesi gerekiyorsa (üçüncü taraf beyaz listeler, e-posta gönderim itibarı, lisans bağları), taşınacak veri terabaytlarcaysa ya da sunucu fiziksel bir makineyse. Bu durumlarda snapshot alın, konsol erişiminizin (VNC/KVM) çalıştığını önceden test edin — SSH yapılandırması yükseltmeden çıkamayacak bir hâle gelirse tek kurtuluşunuz odur — ve sshd -t ile yapılandırmanızı yeniden başlatmadan önce doğrulayın.

60 Saniyelik Karar Ağacı#

1. Sunucuda cPanel/Plesk gibi bir panel var mı? Varsa: panel resmî destek duyurana kadar bekleyin. Karar burada biter.
2. Ubuntu 22.04'te misiniz? Evetse: Mayıs 2027'den önce 24.04'e geçin. 26.04 hedefiniz değil; tek adım kuralı geçerli.
3. 24.04'tesiniz ve uygulamanız sistem PHP/Python paketine bağımlı mı? Evetse: önce bir test sunucusunda 26.04 üzerinde çalıştırın. Çalışmıyorsa bekleyin veya bileşeni sistem dışına taşıyın.
4. Üçüncü parti depolarınızın hepsi resolute yayınlıyor mu? Hayırsa: erteleyin.
5. Hepsi olumluysa ve gerçekten yeni bir bileşene ihtiyacınız varsa: paralel bir 26.04 sunucusu kurup taşıyın; yerinde yükseltmeyi yalnızca IP veya veri hacmi sizi zorluyorsa seçin.
6. Hiçbiri geçerli değilse: hiçbir şey yapmayın. 24.04, Mayıs 2029'a kadar tam destekli. Ubuntu Pro ile bu süre daha da uzuyor.

Sunucunuz snapshot alabilen bir sanallaştırma platformundaysa — Clou.TR'nin sanal sunucu ürünlerinde olduğu gibi — hangi yolu seçerseniz seçin işlemden hemen önce bir anlık görüntü alın. Bedeli birkaç dakika, karşılığı geri dönüş garantisidir.

Sıkça Sorulan Sorular#

Ubuntu 26.04 çıktığına göre 24.04 artık güvensiz mi?#

Hayır. Ubuntu 24.04 LTS, Mayıs 2029'a kadar standart güvenlik bakımı almaya devam ediyor; kritik açıklar için yamalar aynı hızda yayımlanıyor. Yeni bir LTS'in çıkması öncekini geçersiz kılmaz, yalnızca daha yeni paket sürümleri sunar. Güvenlik gerekçesiyle acele etmeniz gereken tek durum, standart bakım süresi dolmak üzere olan 22.04 ve daha eski sürümlerde olmanızdır.

22.04'ten doğrudan 26.04'e geçebilir miyim?#

Desteklenen yol iki adımlıdır: önce 24.04, sonra 26.04. do-release-upgrade size zaten yalnızca bir sonraki LTS'i teklif eder. Atlamaya zorlamak paket bağımlılıklarını çözülemez hâle getirir ve sistemi yarı yükseltilmiş bırakır. Zamanınız kısıtlıysa 22.04'ten temiz bir 26.04 kurulumuna taşınmak, iki ardışık yerinde yükseltmeden hem daha hızlı hem daha güvenlidir.

Yükseltme sırasında SSH bağlantım koparsa ne olur?#

do-release-upgrade bu ihtimale karşı 1022 portunda ikinci bir sshd örneği başlatır ve ilerlemeyi screen benzeri bir oturumda sürdürür, ancak buna güvenmek yerine işlemi baştan tmux veya screen içinde başlatın. Kopma anında oturum devam eder, yeniden bağlanıp tmux attach ile kaldığınız yerden izlersiniz. Konsol (VNC/KVM) erişiminizin çalıştığını da önceden doğrulayın.

Ubuntu Pro ticari sunucuda ücretsiz mi?#

Hayır. Ücretsiz katman kişisel kullanım içindir ve beş makineyle sınırlıdır; resmî Ubuntu topluluk üyeleri elli makineye kadar yararlanabilir. Ticari kullanımda sunucu başına yıllık abonelik gerekir. Karar verirken karşılaştırmanız gereken şey, aboneliğin bedeli ile plansız bir yükseltme kesintisinin ve olası veri kaybının maliyetidir; çok sunuculu ortamlarda hesap genellikle yükseltmeye doğru döner.

Yükseltmeden sonra eski çekirdek sürümüne dönebilir miyim?#

GRUB menüsündeki "Advanced options" altından eski bir çekirdekle açılış yapabilirsiniz, ancak bu yalnızca çekirdek kaynaklı bir sorunu çözer. Sürüm yükseltmesi kütüphaneleri, systemd'yi ve yapılandırma dosyalarını da değiştirdiği için tam geri dönüş yolu yoktur. Gerçek geri dönüş yöntemi, işlemden önce alınmış bir snapshot ya da hâlâ ayakta duran eski sunucudur.

Yükseltme sonrası hangi kontrolleri yapmalıyım?#

Önce servislerin ayakta olduğunu (systemctl --failed), sonra web sunucusu, veritabanı ve PHP-FPM sürümlerinin beklediğiniz gibi olduğunu doğrulayın. Ardından uygulamanın hata loglarını en az bir gün izleyin; sürüm sıçramalarından kaynaklanan sorunlar çoğu zaman ilk dakikada değil, az kullanılan bir sayfa açıldığında ortaya çıkar. dpkg -l | grep '^rc' ile kaldırılan ama yapılandırması kalan paketleri de gözden geçirin.