Sunucuyu kesintisiz güncelleme
Bir sunucu güncellemesiz bırakılamaz, ama her güncelleme siteyi durdurma riski taşır. Bu risk bir süreçle giderilir: küçük güvenlik düzeltmeleri otomatik olarak kurulur, büyük değişiklikler anlık görüntü, kontrol ve hazır bir geri alma planıyla planlı biçimde yapılır, yeniden başlatmalar ise bakım penceresinde toplanır. Bunun tek bir VPS'te nasıl kurulacağına bakalım.
Sunucu güncellemeleri iki türlüdür ve her birine farklı davranmak gerekir. Güvenlik düzeltmeleri sık çıkar, az şey değiştirir ve neredeyse hiçbir şeyi bozmaz; bunları aynı gün otomatik olarak kurmak en iyisidir. Planlı güncellemeler, yani işletim sisteminin, PHP'nin, veritabanının ya da panelin yeni sürümü, programların davranışını değiştirir; bu yüzden hazırlanır ve test edilir. Site kesintileri çoğu zaman güncellemenin kendisinden değil, büyük bir değişikliğin küçük bir değişiklik gibi kurulmasından kaynaklanır.
Otomatik güvenlik güncellemeleri
Ubuntu Server'da unattended-upgrades paketi varsayılan olarak kurulu ve etkindir: günde bir kez yalnızca güvenlik güncellemelerini kurar, /etc/apt/apt.conf.d/50unattended-upgrades dosyasındaki diğer kaynaklar ise yorum satırı olarak kapalıdır. Sıklık 20auto-upgrades dosyasında ayarlanır, günlük /var/log/unattended-upgrades/ dizinine yazılır. Debian aynı paketi kullanır, ancak minimal kurulumda paket bulunmayabilir; nasıl etkinleştirileceği Debian Wiki sayfasında anlatılıyor.
AlmaLinux ve diğer RHEL uyumlu sistemlerde aynı işi dnf-automatic görür. Varsayılan olarak güncellemeleri kurmaz: /etc/dnf/automatic.conf dosyasında upgrade_type = security ve apply_updates = yes ayarlanır, ardından dnf-automatic.timer zamanlayıcısı etkinleştirilir.
İki araç da varsayılan olarak sunucuyu yeniden başlatmaz. Bu doğrudur: sunucu yoğun saatte yeniden başlamamalıdır. Ama yeniden başlatmayı unutmak da olmaz: güncellenen çekirdek ve kütüphaneler ancak yeniden başlatmadan sonra devreye girer. Ubuntu ve Debian'da yeniden başlatma gerektiğini /run/reboot-required dosyası, AlmaLinux'ta dnf needs-restarting -r komutu bildirir. Bu kontrolü sunucu izlemeye eklemek, yeniden başlatmanın kendisini ise bakım penceresinde yapmak gerekir.
Planlı güncellemeden önce anlık görüntü
Her büyük değişiklikten önce sağlayıcının panelinde diskin anlık görüntüsü (snapshot) alınır. Güncelleme ters giderse sunucuyu dakikalar içinde eski haline döndürür. accsly.io kataloğuna göre (Kasım 2026) 2.247 VPS sağlayıcısından 1.644'ünde yedekleme koşulları açıklanmış ve bunların 318'inde anlık görüntüler açıkça belirtilmiş. Sağlayıcı anlık görüntü sunmuyorsa, güncellemeden önce geri yükleyerek daha önce test ettiğiniz tam bir yedek gerekir.
İki çekince var. Anlık görüntü genellikle sunucunun diskiyle aynı yerde saklanır ve yedeğin yerini tutmaz: depolamada bir arıza olursa ikisi birden kaybolur. Ayrıca çalışan bir veritabanının anlık görüntüsü tutarsız olabilir; bu yüzden öncesinde veritabanının dökümü alınır ya da yazma kısa bir süre durdurulur. Yedeklemenin baştan sona nasıl kurulacağı VPS yedekleri: stratejiler ve araçlar yazısında anlatılıyor, yedekler için alanı olan paketler ise yedekler için VPS sayfasında.
Tek bir VPS'te blue-green ve sıralı güncelleme
Kesintisiz güncelleme düzenleri, yük dengeleyicinin arkasında birkaç sunucunun bulunduğu büyük sistemlerden gelir: blue-green iki tam kopya tutar ve trafiği birinden diğerine geçirir, sıralı (rolling) güncelleme ise sunucuları teker teker devreden çıkarır. Tek bir VPS'te aynı fikirler işletim sistemine değil, ama uygulamaya uygulanabilir.
- Sürüm dizinleri. Sitenin her sürümü ayrı bir dizine, örneğin
releases/2026-11-07dizinine yerleştirilir, web sunucusu isecurrentsembolik bağlantısına bakar. Yeni sürüm yanında hazırlanır (bağımlılıklar, derleme, önbellek), ardından bağlantı tek bir komutla değiştirilir. Geri almak için bağlantıyı önceki dizine döndürmek yeterlidir. - Uygulamanın iki örneği. Yeni sürüm başka bir portta ya da başka bir konteynerde başlatılır, kontrolden geçer, ardından nginx ona yönlendirilir. nginx yapılandırmasının yeniden yüklenmesi bağlantıları koparmaz: nginx belgelerine göre ana süreç önce yapılandırmayı denetler ve hata varsa eskisiyle çalışmaya devam eder, eski işçi süreçler de kendi istemcilerine hizmeti tamamlar. Yine de öncesinde
nginx -tçalıştırılır. Uygulamaların konteynerlerde nasıl çalıştırılacağı VPS'te Docker: nereden başlamalı yazısında anlatılıyor. - Uyumlu veritabanı geçişleri. İki sürüm birlikte çalıştığı sürece veritabanı ikisine de uymalıdır. Bu yüzden şema değişiklikleri adımlara bölünür: önce yeni sütunlar ve tablolar eklenir, bunları kullanan kod yayına alınır ve eski yapı ancak bir sonraki sürümde kaldırılır.
İşletim sisteminin kendisini yeni bir ana sürüme tek sunucuda kesintisiz yükseltmek mümkün değildir. Daha güvenilir yol, yeni sistemle ikinci bir VPS açmak, siteyi oraya taşımak, kontrol etmek ve kayıtların yaşam süresini önceden düşürerek DNS'i değiştirmektir; bunun nasıl yapılacağı Sunucu sahibi için alan adları ve DNS yazısında anlatılıyor. Taşınma süresince ikinci sunucuyu saatlik ücretlendirmeyle almak kullanışlıdır. Bu tür taşınmaların daha seyrek yaşanması için sistem sürümünün nasıl seçileceği Sunucu için Linux dağıtımları: Ubuntu, Debian, AlmaLinux yazısında.
Yeniden başlatmadan çekirdek güncellemesi
Canlı çekirdek yamalama (live patching), sunucuyu yeniden başlatmadan çalışan çekirdekteki kritik güvenlik açıklarını kapatır. Ubuntu'da bu, Ubuntu Pro aboneliğinin parçası olan Livepatch hizmetidir: kişisel kullanım için beş makineye kadar ücretsizdir. RHEL uyumlu sistemler için ticari hizmetler de dahil olmak üzere kendi mekanizmaları vardır.
Teknolojinin sınırları var. Yalnızca çekirdeğin izleyebildiği (trace) işlevler yamalanabilir; bu sınırlama Linux çekirdeği belgelerinde açıklanmıştır, bu yüzden düzeltmelerin bir kısmı yalnızca yeni çekirdekle gelir. Canonical, Livepatch'in planlı yeniden başlatmaları ortadan kaldırmadığını, yalnızca bunları bakım penceresine ertelemeyi sağladığını açıkça belirtir. VPS için en önemlisi: kendi çekirdeğiniz yalnızca KVM sanallaştırmasında olur. OpenVZ ve LXC'de çekirdek ortaktır ve onu sağlayıcı günceller; ayrıntılar KVM mi OpenVZ mi: hangisini seçmeli? yazısında.
Bakım penceresi ve geri alma
Bakım penceresi, yeniden başlatmalara ve planlı değişikliklere izin verilen, ziyaretçinin en az olduğu önceden seçilmiş zamandır; genellikle ana kitlenin saat dilimine göre gece. Bu zaman rastgele değil, sitenin istatistiklerine göre belirlenir. Siteyi müşteriler ya da çalışanlar kullanıyorsa önceden bilgilendirilirler. Bakım penceresi yalnızca sizin için değildir: sağlayıcı da bakım çalışmaları yapar ve bunları nasıl duyurduğu SLA ve uptime: sağlayıcılar ne vaat ediyor yazısında ele alınıyor.
Geri alma planı bir şey bozulduktan sonra değil, çalışmalara başlamadan önce hazırlanır:
- arıza belirtilerini (günlüklerdeki hatalar, yanıt süresinin artması, temel sayfaların kontrolünün başarısız olması) ve onarmaya daha fazla uğraşmadan geri alacağınız süreyi önceden belirleyin;
- kod için sembolik bağlantıyı ya da nginx'i önceki sürüme geri çevirin;
- AlmaLinux'ta paketler için son işlemi geri alan
dnf history undokomutu vardır; Ubuntu ve Debian'da paketleri geri almanın standart bir yolu yoktur, bu yüzden orada anlık görüntüye güvenilir; - anlık görüntü tüm diski geri döndürür ve ondan sonra yazılan her şey (siparişler, mesajlar, kayıtlar) kaybolur. Bu yüzden riskli bir güncelleme süresince site bakım moduna ya da salt okunur moda alınır.
Güncellemeden sonra temel sayfaları ve hata günlüklerini kontrol edin, yanıt süresini olağan değerlerle karşılaştırın. Yayına almadan önce yük testi yaptıysanız, aynı senaryo büyük bir güncellemeden sonra sitenin yavaşlayıp yavaşlamadığını hızla gösterir.