Ubuntu Server Sürüm Yükseltme (do-release-upgrade)

Bir Ubuntu Server kurulumu ilk günün ötesinde uzun bir ömür yaşar. Üzerine web siteleri, veritabanları, e-posta servisleri ve zamanlanmış işler yerleşir; siz farkına bile varmadan üç yıl geçer ve kullandığınız LTS sürümünün destek penceresi kapanmaya başlar. İşte bu noktada "sistemi baştan mı kursam, yoksa yerinde mi yükseltsem?" sorusu masaya gelir. Yerinde yükseltme, yani do-release-upgrade, doğru yapıldığında saatler süren yeniden kurulum ve konfigürasyon işini birkaç komuta indirir. Yanlış yapıldığında ise açılmayan bir sunucu, çakışan konfigürasyon dosyaları ve gece yarısı çalan telefonlarla sonuçlanır.

Bu rehberde bir LTS sürümünden diğerine (örneğin 22.04'ten 24.04'e) geçişi, kıdemli bir sistem yöneticisinin gerçek üretim sunucusunda uyguladığı disiplinle ele alacağız. Önce geri dönüşü mümkün kılan yedek ve snapshot katmanını kuracak, ardından yükseltmeyi bozan en yaygın sebep olan üçüncü parti depoları temizleyecek, do-release-upgrade'i SSH üzerinden kopmadan çalıştıracak, konfigürasyon çakışmalarını bilinçli biçimde karara bağlayacak ve son olarak servislerin gerçekten ayakta olduğunu doğrulayacağız. Amaç yükseltmeyi "umarım olur" işi olmaktan çıkarıp, her adımı önceden bildiğiniz kontrollü bir operasyona dönüştürmek.

Yükseltmeye Başlamadan Önce Bilmeniz Gerekenler#

Ubuntu iki farklı yükseltme yolu sunar ve ikisini karıştırmamak kritik önemdedir. Birincisi apt upgrade ile yaptığınız günlük paket güncellemeleridir; bu, aynı sürüm içinde güvenlik ve hata düzeltmelerini getirir, sürüm numarasını değiştirmez. İkincisi ise do-release-upgrade ile yaptığınız sürüm atlamasıdır; çekirdek, kütüphaneler, systemd, PHP, MySQL gibi temel bileşenlerin ana sürümü değişir. Bu ikinci işlem çok daha köklüdür ve uygulamalarınızın davranışını etkileyebilir.

Ubuntu, LTS sürümleri arasında yalnızca bir sonraki LTS'e atlamanıza izin verir. Yani 20.04 üzerindeyseniz doğrudan 24.04'e geçemezsiniz; önce 22.04'e, ardından 24.04'e yükseltmeniz gerekir. Ara sürümleri (22.10, 23.04 gibi) production'da kullanmak genellikle mantıklı değildir çünkü destek süreleri kısadır. Yükseltme öncesi mutlaka hangi sürümde olduğunuzu ve hedef sürümü netleştirin:

# Mevcut sürümü öğren
lsb_release -a

# Çekirdek ve mimari
uname -r
uname -m

# Kök disk doluluk oranı (yükseltme için en az 5-10 GB boş alan şart)
df -h /

Yükseltme, indirilen paketler ve geçici dosyalar için ciddi disk alanı ister. Kök bölümünüz doluysa işlem yarıda kalır ve sistem tutarsız bir durumda kalabilir. Ayrıca planlamanızı bir bakım penceresine oturtun: canlı trafiğin en az olduğu saatleri seçin, kullanıcılarınıza önceden haber verin ve yükseltmenin yarım saat ile birkaç saat arasında sürebileceğini varsayın. Linux komut satırında hâlâ kendinizi rahat hissetmiyorsanız, temel araçları tazelemek için temel Linux komutları rehberimize göz atmak iyi bir başlangıç olur.

Yükseltme Öncesi Tam Yedek ve Snapshot#

Sürüm yükseltmenin altın kuralı tektir: geri dönebileceğinizden emin olmadan başlamayın. İki koruma katmanı öneririm; ideal olan ikisini birden almaktır.

Birinci katman snapshottır. Sunucunuz bir sanallaştırma platformunda çalışıyorsa (VDS, sanal sunucu veya bulut örneği), hipervizör seviyesinde bir anlık görüntü almak en güçlü güvencedir. Yükseltme tümüyle ters giderse, snapshot'a dönerek dakikalar içinde eski çalışan hâle geri dönersiniz. Clou.TR sanal sunucu ve VDS ürünlerinde bu snapshot yeteneği panelden birkaç tıkla kullanılabilir; yükseltmeden hemen önce bir tane oluşturmayı alışkanlık hâline getirin.

İkinci katman dosya ve veritabanı yedeğidir. Snapshot alamadığınız fiziksel/dedicated ortamlarda ya da ek güvence istediğinizde, kritik verileri ayrı bir yere kopyalayın:

# Sistem konfigürasyonlarını ve web verilerini arşivle
sudo tar czpf /root/onceki-surum-yedek-$(date +%F).tar.gz \
  /etc /var/www /home /srv

# Kurulu paket listesini kaydet (gerekirse yeniden kurmak için)
dpkg --get-selections > /root/paket-listesi.txt
apt-mark showmanual > /root/elle-kurulan-paketler.txt

# MySQL / MariaDB veritabanlarını dök
mysqldump --all-databases --single-transaction \
  --routines --triggers > /root/tum-veritabanlari.sql

Yedeği başka bir makineye taşımayı unutmayın; aynı sunucuda duran yedek, sunucu tümüyle bozulduğunda işe yaramaz. rsync veya scp ile uzak bir konuma kopyalayın. Düzenli, otomatik bir yedekleme düzeniniz yoksa bu iyi bir fırsat: kalıcı bir strateji için yedekleme çözümlerimizi inceleyebilirsiniz. Yedeğin gerçekten alındığını arşiv boyutuna ve mysqldump çıktısının son satırına bakarak doğrulayın; "aldım sanıyordum" en pahalı cümledir.

Üçüncü Parti Depoları ve PPA'ları Devre Dışı Bırakmak#

Sürüm yükseltmelerinin en sık başarısızlık sebebi üçüncü parti paket depolarıdır. do-release-upgrade, yalnızca Ubuntu'nun resmi depolarındaki paketlerin yeni sürümle uyumlu olacağını garanti eder. Ama sisteminizde Ondřej PPA'sı üzerinden kurulmuş bir PHP, harici bir depodan gelen Docker veya Node.js, ya da bir vendor deposu varsa, yükseltici bu paketlerin bağımlılıklarını çözemez ve işlem çakışmalarla durur.

Neyse ki yükseltme aracı, resmi olmayan depoları otomatik olarak devre dışı bırakır. Yine de kontrolü ele almak ve sürprizleri önlemek için bunu elle yapmanızı öneririm. Önce hangi harici kaynaklara sahip olduğunuzu görün:

# Ana kaynak dosyası ve ek depolar
grep -rhE '^deb ' /etc/apt/sources.list /etc/apt/sources.list.d/

# Yeni format (deb822) depoları
ls -1 /etc/apt/sources.list.d/

Ardından üçüncü parti depoları geçici olarak pasifleştirin. En temiz yöntem .list dosyalarının uzantısını değiştirmektir, böylece apt onları görmez ama dosya elinizde kalır:

# Tüm harici depo dosyalarını yedekle ve pasifleştir
sudo mkdir -p /root/apt-devredisi
for f in /etc/apt/sources.list.d/*.list; do
  sudo mv "$f" "/root/apt-devredisi/$(basename "$f").kapali"
done

ppa-purge aracı, bir PPA'dan kurulmuş paketleri resmi Ubuntu sürümlerine döndürmek için de kullanışlıdır; özellikle özel derlenmiş PHP veya PostgreSQL paketlerini önce resmi hâle çevirmek, yükseltme sonrası kaosunu azaltır. Yükseltme tamamlandıktan sonra bu depoları yeni sürümle uyumlu karşılıklarıyla yeniden etkinleştirebilirsiniz; eski focal veya jammy etiketli satırları körlemesine geri açmayın, çünkü depo hâlâ eski sürümü işaret ediyor olacaktır. Son olarak mevcut paketlerinizi güncel duruma getirin, çünkü yükseltici temiz bir zemin ister:

sudo apt update
sudo apt upgrade -y
sudo apt --purge autoremove -y
sudo apt clean

Bu adım, "yükseltmeden önce sistemi tamamen güncel yap" prensibini karşılar. Bekleyen yarım güncellemeler, sürüm atlaması sırasında bağımlılık cehennemine dönüşebilir.

do-release-upgrade ile Adım Adım Yükseltme#

Zemini hazırladıktan sonra asıl işleme geçiyoruz. Öncelikle yükseltme aracının kurulu ve güncel olduğundan emin olun:

sudo apt install -y ubuntu-release-upgrader-core update-manager-core

Ubuntu'nun hangi hedefi sunacağını belirleyen bir ayar vardır. /etc/update-manager/release-upgrades dosyasındaki Prompt değeri LTS ise yalnızca yeni LTS çıktığında yükseltme önerilir, normal ise ara sürümler de teklif edilir. Üretim sunucularında bunu lts tutmanızı öneririm:

grep Prompt /etc/update-manager/release-upgrades
# Çıktı: Prompt=lts

Yeni LTS sürümü çıktıktan sonraki ilk aylarda do-release-upgrade bazen "yeni sürüm bulunamadı" der; bu, Ubuntu'nun yükseltme yolunu kademeli açmasındandır. Erken davranmanız gerekiyorsa -d bayrağıyla (development/erken kanal) zorlayabilirsiniz, ancak bunu yalnızca test sunucusunda tercih edin. Şimdi asıl komut:

sudo do-release-upgrade

Araç sırasıyla şunları yapar: yeni sürümün depo tanımlarını indirir, kaç paketin kurulacağını/kaldırılacağını/güncelleneceğini özetler ve onayınızı ister, paketleri indirir, kurar ve son olarak sistemi yeniden başlatmanızı önerir. Süreç boyunca size birkaç soru sorulur; en kritik olanları konfigürasyon dosyası çakışmalarıdır ve bunlara birazdan ayrı bir bölüm ayıracağız. Aşağıdaki tablo, sıkça karşılaşacağınız istemleri ve önerilen yanıtları özetler:

"Servisleri kurulum sırasında otomatik yeniden başlat" sorusuna Yes demek, her serviste tek tek onay vermek zorunda kalmanızı önler ve uzun kurulumu akıcı kılar. Bu istemi görmeden, tüm süreci sessizleştirmek için önceden şu ortam değişkenini de ayarlayabilirsiniz:

export DEBIAN_FRONTEND=noninteractive
export NEEDRESTART_MODE=a

SSH Üzerinden Güvenli Çalıştırma#

Sunucuya SSH ile bağlıysanız ve yükseltmeyi uzaktan yapıyorsanız, gerçek bir tehlike vardır: SSH oturumunuz koparsa, do-release-upgrade yarıda kalır ve sistem paketlerin yarısı eski, yarısı yeni durumda "brick" olabilir. İnternet bağlantınızdaki anlık bir kesinti bile bu senaryoyu tetikleyebilir. Bu yüzden yükseltmeyi asla doğrudan SSH kabuğunda çalıştırmayın.

do-release-upgrade, SSH üzerinden çalıştırıldığını algılar ve otomatik olarak 1022 portunda ikinci bir SSH sunucusu (kurtarma dinleyicisi) açar. Yine de asıl koruma, işlemi bir terminal çoğaltıcı içinde başlatmaktır. tmux veya screen, oturumunuz kopsa bile işlemin sunucuda çalışmaya devam etmesini sağlar; yeniden bağlanıp aynı oturuma girersiniz:

# tmux ile kalıcı oturum
sudo apt install -y tmux
tmux new -s yukseltme

# tmux içinde yükseltmeyi başlat
sudo do-release-upgrade

# Bağlantı koparsa yeniden bağlan:
#   ssh sunucu
#   tmux attach -t yukseltme

Eğer araç 1022 portunda kurtarma dinleyicisi açtığını söylerse, o portu güvenlik duvarınızda geçici olarak açık tutun; ana SSH servisi yeniden başlatılırken bağlantınız düşerse bu port cankurtaran olur:

sudo ufw allow 1022/tcp
# İkinci bir terminalden test bağlantısı:
#   ssh -p 1022 kullanici@sunucu-ip

Konsol erişiminizin olması da paha biçilmez bir güvencedir. Clou.TR sanal sunucu ve VDS panellerindeki VNC/konsol özelliği, sunucu SSH'a hiç yanıt vermese bile ekrana doğrudan bağlanmanızı sağlar; yükseltme SSH'ı bozsa bile konsoldan sisteme girip düzeltebilirsiniz. Yükseltmeye başlamadan önce konsolun çalıştığını test edin. Sistem yönetiminde kendinizi yalnız hissetmek istemiyorsanız, sunucu yönetimi hizmetimiz bu tür kritik operasyonları sizin adınıza yürütebilir.

Config Dosyası Çakışmalarını Yönetmek#

Yükseltme sırasında karşılaşacağınız en önemli kararlar konfigürasyon dosyalarıyla ilgilidir. Bir paketin yeni sürümü, dağıtım varsayılanı olarak farklı bir config dosyası getirir; ama siz o dosyayı geçmişte elle düzenlemişseniz (örneğin sshd_config, nginx.conf, php.ini), dpkg şu soruyla karşınıza çıkar:

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  : install the package maintainer's version
    N  : keep your currently-installed version
    D  : show the differences between the versions
    Z  : start a shell to examine the situation

Buradaki refleksiniz acele etmemek olmalı. Körlemesine Y derseniz, kendi özel ayarlarınızı (özel SSH portu, güvenlik sıkılaştırmaları, sanal sunucu tanımları) kaybedersiniz. Körlemesine N derseniz, yeni sürümün gerekli olabilecek yeni parametrelerini kaçırırsınız. Doğru yaklaşım önce D ile farkı incelemek, sonra karar vermektir. Genel kuralım şudur: kendi elle düzenlediğiniz kritik dosyalarda mevcut sürümü koruyun (N), yükseltme bittikten sonra yeni varsayılanla karşılaştırıp gerekli parametreleri elle ekleyin. dpkg, kabul etmediğiniz yeni sürümü .dpkg-dist, sizin dosyanızın yedeğini ise .dpkg-old uzantısıyla saklar:

# Yükseltme sonrası bekleyen yeni config sürümlerini bul
sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-old'

# Örnek: yeni ile mevcut arasındaki farkı incele
sudo diff /etc/nginx/nginx.conf /etc/nginx/nginx.conf.dpkg-dist

Servis konfigürasyonlarını yönetirken systemd birim dosyalarının da değişebileceğini unutmayın. Bir servisin yeni sürümü farklı bir unit tanımıyla gelebilir; bu dosyaları ve systemctl ile servis durumlarını yönetmenin ayrıntılarına systemd servis yönetimi rehberimizde değiniyoruz. Web sunucusu konfigürasyonlarında ise küçük bir değişiklik bile siteyi çökertebileceği için, yükseltme sonrası mutlaka söz dizimi testini çalıştırın:

# nginx yapılandırmasını doğrula
sudo nginx -t

# Apache için
sudo apachectl configtest

Yükseltme Sonrası Servis Kontrolü ve Doğrulama#

Yeniden başlatmanın ardından iş bitmemiştir; asıl doğrulama şimdi başlar. Önce sürümün gerçekten değiştiğini teyit edin, ardından tüm kritik servislerin ayakta olduğunu tek tek kontrol edin:

# Sürüm değişti mi
lsb_release -a

# Başarısız (failed) durumdaki tüm servisleri listele
systemctl --failed

# Belirli servislerin durumu
systemctl status nginx mysql php8.3-fpm ssh --no-pager

# Açılışta hata var mı, kritik logları tara
sudo journalctl -p err -b --no-pager | tail -n 40

systemctl --failed çıktısının boş olması gönül rahatlatan bir işarettir. Bir servis başlamıyorsa, çoğu zaman sebep bir config uyumsuzluğu veya sürüm atlamasıyla değişen bir bağımlılıktır; journalctl -u servis-adi ile ilgili servisin loglarına inip kök nedeni bulun. Özellikle PHP gibi ana sürümü değişen bileşenlere dikkat edin: 22.04'te PHP 8.1 iken 24.04'te PHP 8.3'e geçilir, bu da php8.1-fpm yerine php8.3-fpm servisinin ve web sunucusunda güncel soket yolunun kullanılması gerektiği anlamına gelir. Benzer şekilde MySQL/MariaDB ana sürüm atlaması sonrası ilk açılışta veritabanı şemasını kendi kendine güncelleyebilir; büyük veritabanlarında bu birkaç dakika sürebilir, sabırlı olun ve logları izleyin.

Ağ tarafında güvenlik duvarı kurallarınızın ve dinlenen portların yerinde olduğunu doğrulayın. Yükseltmeye özel açtığınız 1022 portunu artık kapatabilirsiniz:

# Dinlenen portlar
sudo ss -tulpn

# Güvenlik duvarı durumu
sudo ufw status verbose

# Geçici kurtarma portunu kapat
sudo ufw delete allow 1022/tcp

Son olarak uygulama katmanını gerçek kullanıcı gözüyle test edin: web sitelerinizi tarayıcıda açın, giriş yapın, form gönderin, e-posta akışını deneyin. Sertifikalarınızın hâlâ geçerli olduğundan emin olun; SSL yapılandırmanızı ve varsa WAF kurallarınızı gözden geçirin. Bir web hosting ortamı yönetiyorsanız, cPanel/WHM tarafındaki servislerin ve WordPress bakım süreçlerinizin yükseltmeden etkilenmediğini de kontrol listenize ekleyin.

Geri Dönüş (Rollback) Planı#

Her iyi operasyonun bir çıkış kapısı vardır. Yükseltme sonrası uygulamalarınız düzgün çalışmıyorsa ve sorunu makul sürede çözemiyorsanız, kahramanlık yapmaya çalışmadan geri dönmek en profesyonel karardır. İşte burada başta aldığınız snapshot ve yedek altın değerinde olur.

do-release-upgrade için yerinde bir "downgrade" komutu yoktur; yani yükseltilmiş bir sistemi tek komutla eski sürüme çeviremezsiniz. Bu yüzden geri dönüş stratejiniz tümüyle önceden aldığınız güvencelere dayanır. En hızlı yol, hipervizör snapshot'ına geri dönmektir: sanal sunucu panelinizden yükseltme öncesi anlık görüntüyü geri yükler, birkaç dakika içinde eski çalışan hâle dönersiniz. Snapshot yoksa, temiz bir kuruluma dönüp aldığınız yedeklerden veriyi geri taşırsınız:

# Yeni/temiz sunucuda: veritabanını geri yükle
mysql < /root/tum-veritabanlari.sql

# Web ve konfig verilerini geri aç
sudo tar xzpf /root/onceki-surum-yedek-2026-07-10.tar.gz -C /

# Elle kurulan paketleri yeniden kur (gerekirse)
sudo apt install $(cat /root/elle-kurulan-paketler.txt)

Aşağıdaki tablo, hangi güvencenin hangi geri dönüş yöntemini mümkün kıldığını özetler:

Tablo tek bir dersi haykırıyor: geri dönüş planınızın gücü, yükseltmeden önce attığınız adımlarla belirlenir. Kritik bir sunucuda ilerlemeden önce, mümkünse yükseltmeyi bir kopya/test ortamında deneyin. Sanal sunucular üzerinde geçici bir test kopyası oluşturmak hem ucuz hem hızlıdır; üretimde ilk kez denemek yerine, aynı topolojiyi bir VDS veya sanal sunucu üzerinde tekrar edip süreci provasını yapmak, gerçek yükseltmeyi rutin bir işleme dönüştürür.

Sıkça Sorulan Sorular#

do-release-upgrade ile apt upgrade arasındaki fark nedir?#

Kısaca özetlersek, apt upgrade aynı Ubuntu sürümü içinde paketleri günceller; sürüm numarası değişmez, yalnızca güvenlik ve hata düzeltmeleri gelir. do-release-upgrade ise bir bütün sürümden diğerine (örneğin 22.04'ten 24.04'e) geçiş yapar; çekirdek, systemd, PHP, veritabanı gibi temel bileşenlerin ana sürümü değişir. Günlük bakım için birincisini, üç yılda bir gelen büyük sürüm atlamaları için ikincisini kullanırsınız ve ikincisi çok daha dikkatli bir hazırlık gerektirir.

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

En büyük risk budur ve sistemi tutarsız bırakabilir. Bu yüzden yükseltmeyi mutlaka tmux veya screen gibi bir terminal çoğaltıcı içinde başlatın; oturumunuz kopsa bile işlem sunucuda çalışmaya devam eder ve yeniden bağlanınca aynı oturuma girersiniz. Ek olarak do-release-upgrade, 1022 portunda bir kurtarma SSH dinleyicisi açar; güvenlik duvarında bu portu geçici açık tutun. Konsol/VNC erişimi de sunucu SSH'a hiç yanıt vermese bile son çare olarak sizi içeri sokar.

İki LTS sürüm birden atlayabilir miyim, örneğin 20.04'ten 24.04'e?#

Hayır, Ubuntu doğrudan iki LTS atlamanıza izin vermez. 20.04'ten 24.04'e geçmek için önce 20.04'ü 22.04'e, ardından 22.04'ü 24.04'e yükseltmeniz gerekir. Her adımda paketleri güncel tutmak, üçüncü parti depoları temizlemek ve yeni sürümde servisleri doğrulamak zorundasınız. İki basamaklı bu geçiş uzun sürebileceğinden, çok eski sürümlerde bazen temiz kurulum ve veri taşıma daha hızlı ve daha temiz bir sonuç verir.

Yükseltme kaç saat sürer ve sunucum bu süre boyunca kapalı mı kalır?#

Süre; disk hızına, kurulu paket sayısına ve internet bağlantısına göre yarım saatten birkaç saate kadar değişir. Paketlerin indirilip kurulduğu aşamanın büyük kısmında servisleriniz kısa süreli yeniden başlatmalar dışında çalışmaya devam eder, ancak asıl kesinti yükseltme sonrası zorunlu yeniden başlatma anında yaşanır. Bu yüzden işlemi trafiğin en düşük olduğu bir bakım penceresine planlayın ve kullanıcılarınıza olası kısa kesintiyi önceden bildirin.

Config dosyası sorusunda "yeni sürümü kur" mu yoksa "mevcut sürümü koru" mu demeliyim?#

Genel kural, elle düzenlediğiniz kritik dosyalarda (SSH, web sunucusu, PHP ayarları) mevcut sürümü korumaktır; böylece özel yapılandırmalarınızı kaybetmezsiniz. Kararı vermeden önce D tuşuyla iki sürüm arasındaki farkı mutlaka inceleyin. Yükseltme bittikten sonra dpkg yeni varsayılanı .dpkg-dist uzantısıyla saklar; bu dosyayı kendi ayarınızla karşılaştırıp yeni sürümün gerekli parametrelerini elle eklersiniz. Hiç dokunmadığınız dosyalarda ise yeni varsayılanı kurmak genellikle güvenlidir.

Yükseltme yarıda kaldı ve sistem açılmıyor, ne yapmalıyım?#

Önce panik yapmadan konsol/VNC üzerinden sisteme erişmeyi deneyin; SSH bozulsa bile konsol çoğu zaman çalışır. Kurulum yarıda kaldıysa sudo dpkg --configure -a ve sudo apt --fix-broken install komutları çoğu tutarsızlığı onarır. Bu adımlar sonuç vermez ve makul sürede toparlayamıyorsanız, en temiz çözüm yükseltme öncesi aldığınız snapshot'a geri dönmek ya da yedekten temiz kuruluma veri taşımaktır. Bu senaryo, en baştaki yedek ve snapshot adımlarının neden pazarlık konusu olmadığını gösterir.

Kapanış#

Ubuntu Server sürüm yükseltmesi, doğru sırayla yapıldığında korkulacak bir işlem değil; disiplinli bir kontrol listesidir. Önce geri dönebileceğiniz bir snapshot ve yedek alın, üçüncü parti depoları temizleyip sistemi tümüyle güncelleyin, do-release-upgrade'i mutlaka tmux içinde ve konsol erişimi hazırken çalıştırın, konfigürasyon çakışmalarını acele etmeden karara bağlayın ve yükseltme sonrası her kritik servisi tek tek doğrulayın. Bu adımların her biri, "umarım olur" belirsizliğini önceden bildiğiniz kontrollü bir operasyona dönüştürür.

Bu operasyonu kendi başınıza üstlenmek istemiyor ya da kritik bir üretim sunucusunda hata payını sıfıra indirmek istiyorsanız, Clou.TR olarak yanınızdayız. Snapshot ve konsol erişimiyle donatılmış sanal sunucu ve VDS çözümlerimiz güvenli yükseltmeler için ideal bir zemin sunar; sunucu yönetimi hizmetimiz ise sürüm geçişlerini, yedekleme düzenini ve güvenlik sıkılaştırmalarını sizin adınıza yürütür. Düzenli yedekleme altyapınızı kurmaktan sunucularınızın taşınmasına kadar her adımda destek almak için ürün sayfalarımızı inceleyebilir, ekibimizle iletişime geçebilirsiniz.