Sunucu Taşıma Nedir ve Neden Veri Kaybı Riski Oluşur?
Sunucu taşıma, bir web sitesinin, uygulamanın veya veri tabanının mevcut altyapısından başka bir sunucuya (örneğin VDS sunucu paketleri ya da fiziksel sunucu (dedicated server)) aktarılması sürecidir. Bu işlem genellikle performans artırma, maliyet optimizasyonu veya coğrafi konum değişikliği gibi sebeplerle yapılır. Ancak taşıma sırasında veri kaybı riski kaçınılmaz bir tehdit olarak karşımıza çıkar.
Veri kaybı, yalnızca iş sürekliliğini bozmakla kalmaz, aynı zamanda müşteri güvenini sarsar ve yasal sorumluluklar doğurabilir. Örneğin, bir e‑ticaret sitesinin sipariş veritabanı eksik taşınırsa, %30‑40 oranında satış kaybı yaşanabilir. Bu yüzden taşıma öncesi ve süreci boyunca sistematik bir yaklaşım benimsemek hayati önem taşır.
Adım 1: Detaylı Envanter ve Risk Analizi Nasıl Yapılır?
Taşıma işlemine başlamadan önce mevcut ortamın tam bir envanteri çıkarılmalıdır. Sunucu üzerindeki tüm hizmetler (web server, veri tabanı, cache, e‑posta vb.) ve bunların bağımlılıkları listelenmelidir. Bu aşamada risk analizi yaparak hangi bileşenlerin taşıma sırasında en yüksek kayıp riskine sahip olduğu belirlenir.
Risk analizi sırasında şu sorulara cevap verilmelidir:
- Veri tabanı büyüklüğü ve güncelliği nedir?
- Hangi dosyalar gerçek zamanlı olarak güncelleniyor?
- Servisler arasında kritik bir sıra var mı?
- Taşıma sırasında kesinti kabul edilebilir mi?
Bu sorulara verilen yanıtlar, yedekleme sıklığı ve test planının kapsamını belirleyecektir. Örneğin, yüksek trafikli bir WordPress hosting sitesinde veritabanı ve medya dosyaları aynı anda değişiyorsa, anlık yedekleme (incremental backup) stratejisi tercih edilmelidir.
Adım 2: Yedekleme Stratejileri ve Doğrulama Süreci
Veri kaybını önlemenin en etkili yolu, güvenilir bir yedekleme planı oluşturmaktır. Yedekleme üç temel seviyede yapılmalıdır:
- Tam Yedekleme (Full Backup): Tüm sistemin bir kopyasını alır. En az haftada bir kez yapılmalıdır.
- Artımlı Yedekleme (Incremental Backup): Son tam yedeklemeden itibaren değişen dosyaları kaydeder. Bu, depolama maliyetini %70’e kadar azaltabilir.
- Anlık Yedekleme (Snapshot):** Veritabanı ve dosya sisteminin belirli bir anda anlık görüntüsünü alır. Kritik bir güncellemeden önce mutlaka alınmalıdır.
Yedeklemeler sadece depolama ortamına değil, farklı bir coğrafi konuma da (örneğin veri merkezimiz) kopyalanmalıdır. Bu, doğal afet ya da bölgesel ağ kesintilerine karşı ek bir koruma sağlar.
Yedekleme sonrası doğrulama aşaması kaçınılmazdır. Yedek dosyalarının bütünlüğü md5sum ya da sha256sum komutlarıyla kontrol edilmeli, geri yükleme (restore) testi bir test ortamında yapılmalıdır. Bu test, “restore” işleminin sorunsuz çalıştığını kanıtlar ve gerçek taşıma sırasında sürprizleri önler.
Adım 3: Test Ortamı Oluşturma ve Ön Taşıma Testleri
Canlı ortamda doğrudan değişiklik yapmak yerine, aynı konfigürasyona sahip bir test ortamı kurmak en güvenli yaklaşımdır. Bu ortamda aşağıdaki testler yapılmalıdır:
- Veri tabanı replikasyonu ve senkronizasyonu.
- Uygulama bağımlılıklarının (PHP sürümü, Node.js paketleri, Python kütüphaneleri) yeni sunucuda aynı şekilde çalışıp çalışmadığı.
- SSL sertifikalarının ve DNS ayarlarının geçerli olup olmadığı.
- Performans karşılaştırması:
ab -n 1000 -c 100 http://test.example.com/gibi araçlarla yanıt süreleri ölçülmelidir.
Bu testler sırasında WAF güvenlik duvarı gibi güvenlik katmanlarının da yeni ortamda aktif olduğundan emin olun. Test sonuçları, taşıma planının eksiklerini ortaya çıkarır ve düzeltme adımlarını belirler.
Adım 4: Kesintisiz Veri Aktarımı İçin Senkronizasyon Araçları
Canlı bir siteyi taşıma sırasında kesintisiz tutmak istiyorsanız, rsync veya Rclone gibi senkronizasyon araçları kullanılabilir. Bu araçlar, sadece değişen dosyaları aktararak taşıma süresini %60’a kadar kısaltır. Örnek rsync komutu:
rsync -avz --delete --progress /var/www/html/ user@newserver:/var/www/html/
Veri tabanı için ise MySQL Replication veya Percona XtraBackup gibi çözümler tercih edilmelidir. Replication sayesinde, yeni sunucuya sürekli veri akışı sağlanır ve son geçiş anında sadece bir cut‑over (kesişme) işlemi yapılır.
Bu aşamada IPv4 adres kiralama gibi ağ konfigürasyonlarının da yeni sunucuda aynı şekilde tanımlandığından emin olun. Aksi takdirde DNS propagasyonu sırasında erişim sorunları ortaya çıkabilir.
Adım 5: DNS ve Trafik Yönlendirme Yönetimi
Sunucu taşıma sürecinde DNS değişikliği kaçınılmazdır. DNS değişikliği yapmadan önce TTL (Time To Live) değerini 300 saniyeye (5 dk) düşürmek, yeni IP’ye yönlendirme süresini hızlandırır. TTL düşürülmüşse, eski IP’nin önbellekte kalma süresi azalır ve kullanıcılar yeni sunucuya daha hızlı geçiş yapar.
Taşıma sırasında çift yönlü proxy (örneğin Nginx reverse proxy) kullanarak hem eski hem yeni sunucuya aynı anda trafik yönlendirebilirsiniz. Bu yöntem, blue‑green deployment olarak da bilinir ve olası bir sorun durumunda anında geri dönüş (rollback) imkanı tanır.
DNS ayarları güncellendikten sonra SLA hizmeti kapsamında izleme yapılmalı, yanıt süresi ve hata oranları kontrol edilmelidir. İzleme araçları (Prometheus, Grafana) ile anormallikler anında tespit edilip müdahale edilebilir.
Adım 6: Kesintisiz Geçiş (Cut‑Over) ve İzleme
Kesintisiz geçiş, tüm verilerin yeni sunucuya tamamen senkronize olduğu an gerçekleşir. Bu aşamada şu adımlar izlenmelidir:
- Son bir incremental backup alın.
- Veri tabanını durdurun (örneğin
systemctl stop mysql). - Yeni sunucuda veri tabanını başlatın ve bütünlüğü kontrol edin.
- DNS kaydını yeni IP’ye yönlendirin.
- İzleme araçlarıyla anlık performans ve hata raporlarını kontrol edin.
Geçiş sonrası ilk 24 saat içinde log analizi (access log, error log) yapılmalı, olası 404 hataları ve veri tutarsızlıkları tespit edilmelidir. Ayrıca kurumsal e-posta hizmetlerinin de yeni sunucuya yönlendirildiğinden emin olun.
Adım 7: Taşıma Sonrası Yedekleme ve Sürekli İyileştirme
Taşıma tamamlandıktan sonra yeni ortamda da aynı yedekleme politikaları uygulanmalıdır. İlk hafta içinde günlük tam yedekleme, ardından haftalık tam ve günlük incremental yedeklemeler devam etmelidir. Yedekleme planı, 3‑2‑1 kuralı (3 kopya, 2 farklı medya, 1 off‑site) ile güçlendirilmelidir.
Son olarak, taşıma sürecinde edinilen deneyimler bir post‑mortem raporu ile belgelendirilmeli ve gelecek taşımalar için İyileştirme Listesi (Improvement List) hazırlanmalıdır. Bu rapor, hangi adımların sorunsuz, hangilerinin sorunlu olduğunu gösterir ve gelecekte aynı hataların tekrarlanmasını önler.
Avantaj‑Dezavantaj Karşılaştırma Tablosu
| Yöntem | Avantaj | Dezavantaj |
|---|---|---|
| Tam Yedekleme + Restore | Basit, her durumda çalışır | Zaman alıcı, uzun kesinti süresi |
| Artımlı Yedekleme + rsync | Depolama tasarrufu, hızlı senkronizasyon | Doğru yapılandırma gerekir, hatalı senkronizasyon riski |
| MySQL Replication + Cut‑Over | Kesintisiz geçiş, veri kaybı riski %0 | Ek konfigürasyon, replikasyon gecikmesi |
| Blue‑Green Deployment | Anında geri dönüş, düşük risk | İki ortam maliyeti, karmaşık yönlendirme |
Sıkça Sorulan Sorular
Sunucu taşıma sırasında veri kaybı riskini %100 nasıl ortadan kaldırabilirim?
Risk tamamen ortadan kaldırmak mümkün değildir, ancak riskin %0’a yaklaşması için tam yedekleme, artımlı senkronizasyon ve replikasyon kombinasyonu kullanılmalıdır. Ayrıca taşıma sonrası 24 saat içinde detaylı log analizi ve geri yükleme testleri yapılmalıdır.
Taşıma sırasında DNS TTL değerini ne kadar düşürmeliyim?
TTL değerini 300 saniye (5 dk) seviyesine indirmek genellikle yeterlidir. Bu, yeni IP’ye yönlendirme süresini kısaltır ve eski IP’nin önbellekte kalma süresini azaltır.
Rsync ile veri aktarımı yaparken hangi parametreleri kullanmalıyım?
En yaygın kullanılan parametreler -avz --delete --progress şeklindedir. -a arşiv modu, -v detaylı çıktı, -z sıkıştırma ve --delete hedefteki eski dosyaları siler.
Taşıma sonrası yedekleme planı nasıl olmalı?
3‑2‑1 kuralına uygun bir plan izlenmelidir: Günlük incremental, haftalık tam yedekleme ve aylık off‑site yedekleme. Ayrıca kritik veritabanları için anlık snapshot alınması önerilir.
Sonuç: Kesintisiz ve Güvenli Sunucu Taşıma İçin İzlenecek Yol Haritası
Sunucu taşıma sürecinde veri kaybını önlemek, planlama, yedekleme, test ve izleme aşamalarının bütüncül bir yaklaşımla yürütülmesini gerektirir. Yukarıda detaylandırılan 7 adım, hem teknik riskleri azaltır hem de iş sürekliliğini korur. Taşıma sonrası düzenli yedekleme ve iyileştirme döngüsü oluşturmak, gelecekteki olası geçişlerde aynı hataları tekrarlamamanızı sağlar.
Eğer profesyonel bir destek arıyorsanız, colocation hizmeti ve veri merkezimiz size özel altyapı ve yedekleme çözümleri sunabilir. Taşıma planınızı oluşturduktan sonra bir uzmana danışarak süreci sorunsuz bir şekilde tamamlayabilirsiniz.
