Sunucudan buluta geçiş rehberi: planlama, kesintisiz taşıma ve maliyet

Ofisteki ya da sistem odasındaki fiziksel sunucuyu buluta taşımak, tek seferlik bir kopyalama işi değildir. Kesintisiz bir geçiş; neyin taşınacağını bilmeye, DNS değişikliğini önceden hazırlamaya, veriyi birkaç turda eşitlemeye ve bir şey ters giderse eski sunucuya dönebilmeye dayanır. Bu rehberde sunucudan buluta geçişi yedi adımda, her adımın sonunda bir kontrol noktasıyla anlatıyoruz. Son bölümde maliyeti doğru karşılaştırmak için hangi kalemlere bakmanız gerektiğini bulacaksınız.

Sunucudan buluta geçiş neden plan ister

Plansız geçişlerde sorunlar genellikle aynı yerden çıkar: unutulan bir zamanlanmış görev, eski IP adresine sabitlenmiş bir entegrasyon, saatlerce eski sunucuya gitmeye devam eden DNS sorguları ya da geçiş sırasında yazılan ve yeni sunucuya hiç ulaşmayan veriler. Bunların hepsi önceden listelenebilir ve önlenebilir. Plan üç soruyu cevaplamalıdır:

• Neyi taşıyoruz ve neye bağımlı?
• Kesinti penceresi ne kadar olabilir ve kullanıcıyı ne zaman yeni sunucuya yönlendireceğiz?
• Yeni sunucuda sorun çıkarsa hangi koşulda, ne kadar sürede geri döneceğiz?

1. Adım: Envanter çıkarın

Taşınacak sunucuda çalışan her şeyi yazılı hale getirin. Linux sunucuda şu komutlar başlangıç için yeterlidir; hiçbiri sistemde değişiklik yapmaz:

# Dinlenen portlar ve bunları açan süreçler
sudo ss -tlnp

# Çalışan servisler
systemctl list-units --type=service --state=running

# Zamanlanmış görevler (tüm kullanıcılar ve sistem)
for u in $(cut -f1 -d: /etc/passwd); do sudo crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
ls /etc/cron.d /etc/cron.daily
systemctl list-timers --all

# Disk kullanımı ve büyük dizinler
df -h
sudo du -xh --max-depth=1 /var /srv /home 2>/dev/null | sort -h | tail -n 20

Bu çıktılardan bir tablo oluşturun. Her satırda şunlar olsun:

Gözden kaçan kalemlere özellikle bakın: sabit IP'ye izin veren dış servisler (banka, kargo, e-fatura entegratörü gibi), lisansı donanıma ya da makine adına bağlı yazılımlar, sunucudan gönderilen e-postalar ve başka sistemlerin bu sunucuya bağlandığı paylaşımlar.

Kontrol noktası: Envanterdeki her port ve her zamanlanmış görev için "yeni sunucuda karşılığı ne olacak" sorusunun bir cevabı var.

2. Adım: Geçiş yöntemini seçin

Her bileşen için aynı yöntemi kullanmak zorunda değilsiniz. Yaygın seçenekler şunlardır:

• Olduğu gibi taşıma: Uygulama ve yapılandırma aynen yeni sunucuya kopyalanır. En hızlı yoldur, ancak eski işletim sistemini ve eski sorunları da beraberinde getirir.
• Güncel sisteme yeniden kurma: Yeni sunucuya güncel işletim sistemi kurulur, uygulama ve veri buna taşınır. Daha fazla emek ister ama destek süresi dolmuş sistemlerden kurtulmak için doğru zamandır.
• Yönetilen bir bileşene geçiş: Örneğin dosya arşivini nesne depolamaya, e-postayı ayrı bir hizmete taşımak. Sunucunun yükünü ve taşınacak veri miktarını azaltır.
• Kaldırma: Envanterde kimsenin kullanmadığı servisler çıkarsa taşımayın.

Muhasebe ve ERP gibi Windows uygulamalarında genellikle yeni sunucuya temiz kurulum yapılıp veritabanı taşınır; web uygulamalarında ise güncel bir Linux dağıtımına yeniden kurmak çoğu zaman daha sağlıklıdır.

Kontrol noktası: Her bileşenin yanında seçilen yöntem ve sorumlu kişi yazıyor.

3. Adım: Hedef bulut sunucuyu boyutlandırın ve hazırlayın

Kaynakları tahminle değil, mevcut kullanıma bakarak seçin. Birkaç gün boyunca işlemci, bellek ve disk G/Ç değerlerini izleyin; yoğun saatlerdeki tepe değer boyutlandırmanın temelidir. Bulutta kaynak artırmak kolay olduğundan, başlangıçta tepe kullanıma yakın bir boyut seçip gerektiğinde büyütmek, en baştan aşırı büyük bir sunucu almaktan daha ekonomiktir.

Lokasyon seçiminde kullanıcılarınızın nerede olduğuna ve verinin nerede tutulması gerektiğine bakın. Bulut sunucu seçeneklerimiz İstanbul ve Fransa'da (Strasbourg) bulunur; Türkiye'deki kullanıcılar ve kişisel veri içeren iş yazılımları için İstanbul lokasyonu genellikle doğal tercihtir.

Yeni sunucuda yapılacak ilk işler:

1. İşletim sistemini güncelleyin, saat dilimini ve sunucu adını ayarlayın.
2. Uygulamanın ihtiyaç duyduğu paketleri, envanterdeki sürümlerle uyumlu olacak şekilde kurun.
3. Güvenlik duvarında yalnız gereken portları açın. Eski sunucudan veri çekmek için gerekiyorsa SSH erişimini yalnız eski sunucunun IP adresine izin verecek şekilde tanımlayın.

Kendini kilitleme uyarısı: Aşağıdaki kuralları uygulamadan ve güvenlik duvarını etkinleştirmeden önce, şu anda bağlandığınız IP adresine SSH (Windows sunucularda RDP, 3389) izni veren kuralı mutlaka ilk sırada ekleyin. Bu izin olmadan ufw enable çalıştırırsanız mevcut oturumunuz kesilir ve sunucuya uzaktan erişimi tamamen kaybedersiniz. Kendi IP adresinizi doğrulamak için bağlantıyı açtığınız makineden çıkış IP'nizi kontrol edin, SSH portunu değiştirdiyseniz kuralda o portu yazın ve sağlayıcı panelindeki konsol erişimini önceden test ederek bir yedek giriş yolu hazır tutun.

# 1) ÖNCE kendi yönetim erişiminiz: bu satır olmadan devam etmeyin
sudo ufw allow from YONETIM_IP to any port 22 proto tcp

# 2) Veri çekmek için eski sunucu
sudo ufw allow from ESKI_SUNUCU_IP to any port 22 proto tcp

# 3) Web trafiği
sudo ufw allow 80,443/tcp

# 4) Kuralları etkinleştirmeden önce listeyi gözden geçirin
sudo ufw show added

# 5) Ancak yönetim kuralı listede görünüyorsa etkinleştirin
sudo ufw enable
sudo ufw status numbered

Etkinleştirdikten sonra mevcut oturumu kapatmadan, ikinci bir terminalden yeni bir SSH bağlantısı açarak erişimin sürdüğünü doğrulayın. Yeni bağlantı kurulamıyorsa açık kalan ilk oturumdan kuralı düzeltin.

Kontrol noktası: Yeni sunucuda uygulama boş ya da test verisiyle açılıyor, ikinci bir oturumdan SSH ile bağlanabiliyorsunuz, gereken portlar dışarıdan erişilebilir, gerekmeyenler kapalı.

4. Adım: DNS TTL değerini önceden düşürün

Kullanıcıları yeni sunucuya yönlendirmenin en yaygın yolu, alan adının A kaydını yeni IP adresine çevirmektir. Ancak DNS çözümleyicileri kaydı TTL süresi boyunca önbellekte tutar. TTL bir gün ise, değişiklikten sonra bazı kullanıcılar bir gün boyunca eski sunucuya gitmeye devam edebilir.

Cloudflare'in DNS en iyi uygulamaları belgesi, geçiş penceresinden en az 24 ila 48 saat önce kritik kayıtların TTL değerlerinin düşürülmesini öneriyor. Mevcut kayıtlardan birinin TTL'i bu süreden uzunsa, bekleme süresini o değere göre uzatmanız gerekir; çünkü eski uzun TTL'li kayıt önbelleklerden ancak o süre dolunca düşer. Aynı belgede geçişler için sık kullanılan kısa değer olarak 300 saniye (5 dakika) veriliyor ve SOA kaydındaki MINIMUM alanının da düşürülmesinin değerlendirilmesi öneriliyor; bu alan, "kayıt bulunamadı" yanıtlarının ne kadar süre önbellekte tutulacağını belirler. Ayrıntılar için Cloudflare DNS geçiş aşaması belgesine bakabilirsiniz.

Mevcut TTL değerlerini şöyle kontrol edin:

# Yetkili sunucudan A ve SOA kayıtlarını sorgulama
dig +noall +answer ornek.com A
dig +noall +answer www.ornek.com A
dig +noall +answer ornek.com SOA

# Belirli bir genel çözümleyicideki kalan süreyi görme
dig @1.1.1.1 +noall +answer ornek.com A

Uygulama sırası:

1. Geçişten en az 24 ila 48 saat önce (ya da mevcut en uzun TTL kadar önce) web, API ve e-posta ile ilgili kritik kayıtların TTL'ini 300 saniyeye düşürün.
2. Bekleme süresi dolduktan sonra dig çıktısında yeni TTL'in görüldüğünü doğrulayın.
3. Geçiş anında A kayıtlarını yeni IP'ye çevirin.
4. Geçiş kalıcı hale geldikten birkaç gün sonra TTL'i tekrar normal değerine yükseltin.

Kontrol noktası: Geçiş günü sabahı tüm kritik kayıtlar kısa TTL ile dönüyor.

5. Adım: Veriyi eşitleyin

Kesintiyi kısa tutmanın yolu, verinin büyük kısmını geçiş gününden önce taşımaktır. Kesme anında yalnız son değişiklikler aktarılır.

Dosyalar için rsync ile çok turlu eşitleme

İlk tur birkaç saat sürebilir ve sistem çalışırken yapılabilir. Sonraki turlar yalnız değişen dosyaları aktardığı için kısalır.

# Önce deneme turu: neyin aktarılacağını gösterir, bir şey kopyalamaz
rsync -aHAX --numeric-ids --dry-run --stats \
  root@ESKI_SUNUCU_IP:/var/www/ /var/www/

# Gerçek ilk tur
rsync -aHAX --numeric-ids --info=progress2 \
  root@ESKI_SUNUCU_IP:/var/www/ /var/www/

Kaynak yolun sonundaki / işaretine dikkat edin: dizinin içeriğini mi, dizinin kendisini mi kopyaladığınızı belirler. Hedefte fazladan dosya silen seçenekleri, ne yaptığını deneme turunda görmeden kullanmayın.

Veritabanları için tutarlı kopya

Veritabanı dosyalarını servis çalışırken rsync ile kopyalamak tutarsız bir kopya üretebilir. Bunun yerine veritabanının kendi aracını kullanın. MySQL ve MariaDB için InnoDB tablolarında tutarlı bir döküm şöyle alınır:

mysqldump --single-transaction --routines --triggers --events \
  -u yedek_kullanici -p uygulama_db | gzip > uygulama_db.sql.gz

Büyük veritabanlarında kesinti süresini kısaltmak için yeni sunucuyu eski sunucunun kopyası (replika) olarak kurup geçiş anında rolleri değiştirmek de bir seçenektir; bu yöntem daha fazla hazırlık ister ama kesme anındaki aktarımı neredeyse sıfıra indirir. SQL Server kullanan iş yazılımlarında tam yedek alıp yeni sunucuda geri yüklemek yaygın yoldur.

Kontrol noktası: Deneme amaçlı bir geri yüklemeyle yeni sunucuda uygulama gerçek veriyle açılıyor; kayıt sayıları ve dosya boyutları eski sunucuyla karşılaştırıldı.

6. Adım: Kesme anı kontrol listesi

Geçiş penceresini kullanımın en düşük olduğu saatlere koyun ve kullanıcıları önceden bilgilendirin. Kesme anında sıra şöyle olmalıdır:

1. Eski sunucuda uygulamayı bakım moduna alın ya da yazma işlemlerini durdurun.
2. Son rsync turunu ve son veritabanı aktarımını yapın.
3. Yeni sunucuda uygulamayı başlatın; giriş, kayıt ekleme, rapor alma ve e-posta gönderme gibi kritik işlemleri test edin.
4. Hosts dosyası üzerinden ya da doğrudan IP ile test ederek, DNS değişmeden önce yeni sunucunun doğru çalıştığından emin olun.
5. DNS kayıtlarını yeni IP'ye çevirin, sabit IP izni isteyen dış servislere yeni adresi bildirin.
6. Zamanlanmış görevleri yeni sunucuda etkinleştirin, eski sunucuda devre dışı bırakın; aynı görevin iki yerde birden çalışması çift fatura, çift e-posta gibi sorunlar doğurur.
7. Yeni sunucuya izleme ve yedekleme tanımlayın.

Kontrol noktası: Eski sunucunun erişim günlüklerinde gelen istekler azalıyor, yeni sunucuda artıyor.

7. Adım: Geri dönüş planı

Geri dönüş planı, geçişten önce yazılır ve şu üç maddeyi içerir:

• Geri dönüş tetikleyicisi: Hangi durumda geri döneceğinize önceden karar verin. Örneğin kritik bir işlem belirli bir süre içinde düzeltilemiyorsa.
• Geri dönüş adımları: DNS kayıtlarını eski IP'ye çevirmek, eski sunucuda bakım modunu kapatmak. TTL kısa olduğu için bu yönlendirme de hızlı yayılır.
• Veri farkı: Yeni sunucuda geçen sürede oluşan veriler eski sunucuya nasıl aktarılacak? Kısa bir pencerede bu farkı elle aktarmak mümkün olabilir; uzun sürede ise geri dönüş karmaşıklaşır. Bu yüzden geri dönüş kararını ilk saatlerde vermek önemlidir.

Eski sunucuyu geçişten hemen sonra kapatmayın. Birkaç hafta, bütün ay sonu ve dönem işlemleri yeni sunucuda sorunsuz tamamlanana kadar dokunmadan bekletin. Geçişten önce eski sunucunun tam bir yedeğini ayrı bir yerde saklamak da son güvencenizdir; düzenli ve sunucudan bağımsız yedek için Cloud Backup hizmetini değerlendirebilirsiniz.

Maliyet: hangi kalemleri karşılaştırmalı

Sunucudan buluta geçişin maliyetini yalnız aylık sunucu ücretiyle karşılaştırmak yanıltıcıdır. Fiziksel sunucunun gerçek maliyeti şunları içerir:

• Donanım alımı ve birkaç yılda bir yenileme,
• Arıza durumunda yedek parça ve servis süresi,
• Elektrik, soğutma ve sistem odası alanı,
• Sabit IP'li kurumsal internet hattı,
• Yedekleme donanımı ya da harici depolama,
• Bakım ve izleme için harcanan personel zamanı.

Bulut tarafında ise sunucu kaynağı, varsa lisanslar (örneğin Windows Server ve uzak masaüstü lisansları), yedekleme ve trafik kalemlerine bakın. Hesabı en az üç yıllık bir dönem için yapmak, donanım yenileme maliyetini de görünür kılar. Ayrıntılı bir karşılaştırma yöntemi için colocation, kiralık fiziksel sunucu ve bulut için 3 yıllık TL maliyet hesabı yazımıza bakabilirsiniz.

Taşımanın kendisi de bir maliyettir: teknik ekibinizin harcayacağı saatler ve olası kesinti. Bu işi kendiniz yapmak istemiyorsanız taşıma kampanyası kapsamında envanterden kesme anına kadar süreci bizim yürütmemizi isteyebilir, kampanya koşullarını sayfada görebilirsiniz.

Sık yapılan hatalar

• Güvenlik duvarını yönetim izni olmadan açmak: SSH ya da RDP izni eklenmeden etkinleştirilen kural seti sizi sunucunun dışında bırakır; yönetim kuralını her zaman ilk ekleyin ve ikinci bir oturumla doğrulayın.
• TTL'i geçiş günü düşürmek: Yeni TTL ancak eski TTL süresi dolunca geçerli olur; düşürme işi günler önce yapılmalıdır.
• Zamanlanmış görevleri unutmak: Yedek, rapor ve e-posta betikleri envantere girmezse yeni sunucuda sessizce çalışmaz.
• Çalışan veritabanını dosya olarak kopyalamak: Tutarsız kopya, geri yüklemede bozuk tablolarla sonuçlanabilir.
• Eski sunucuyu hemen kapatmak: Geri dönüş yolunu ortadan kaldırır.
• Dış entegrasyonlara IP değişikliğini bildirmemek: Banka, e-fatura ya da kargo bağlantıları geçişten sonra hata vermeye başlar.
• Geri yükleme testi yapmamak: Yedeğin varlığı, geri dönebileceğiniz anlamına gelmez; deneme geri yüklemesiyle doğrulayın.

Sık sorulan sorular

Sunucudan buluta geçiş kesintisiz yapılabilir mi?

Çoğu uygulamada kesinti birkaç dakikaya indirilebilir. Bunun için veri önceden çok turlu eşitlenir, DNS TTL'i günler önce kısaltılır ve kesme anında yalnız son değişiklikler aktarılır. Tamamen sıfır kesinti, veritabanı replikasyonu gibi ek hazırlık ister.

DNS TTL değerini ne zaman ve ne kadara düşürmeliyim?

Cloudflare'in önerisine göre geçişten en az 24 ila 48 saat önce; mevcut TTL daha uzunsa en az o süre kadar önce. Geçişlerde sık kullanılan değer 300 saniyedir. Geçiş tamamlandıktan sonra TTL'i normal değerine geri yükseltebilirsiniz.

Eski fiziksel sunucuyu ne zaman kapatabilirim?

Yeni sunucuda tüm kritik işlemler, ay sonu ve dönem işlemleri dahil sorunsuz tamamlandıktan ve eski sunucunun tam yedeği ayrı bir yerde saklandıktan sonra. Bu süre boyunca eski sunucu geri dönüş seçeneği olarak bekler.

Muhasebe ve ERP programları da aynı yöntemle taşınır mı?

Genel adımlar aynıdır: envanter, yeni sunucu hazırlığı, veritabanı yedeği ve geri yükleme, test ve kesme anı. Bu tür yazılımlarda lisans aktarımı ve kullanıcıların uzak masaüstü ile bağlanması ek planlama gerektirir; lisans sağlayıcınızın taşıma koşullarını önceden kontrol edin.

Taşımayı kendim mi yapmalıyım, sağlayıcıya mı bırakmalıyım?

Envanteri iyi biliyor ve bir geçiş penceresi ayırabiliyorsanız bu rehberdeki adımlarla kendiniz yapabilirsiniz. Ekip zamanı kısıtlıysa ya da kesinti riski yüksek bir iş yazılımı söz konusuysa taşımayı sağlayıcıya bırakmak, riski ve harcanan iç zamanı azaltır.