Dedicated Server Migration: Zero-Downtime Nasıl Sağlanır?

Server Migration: Neden Gerekli?

Mevcut fiziksel sunucu yetersiz, yeni donanım gerekli. Veya hosting sağlayıcı değiştiriyorsunuz. Migration sırasında 1 saat downtime → %20 müşteri kaybı.

Zero-downtime migration mümkün mü? Evet, doğru strateji ile.

Migration Stratejileri

1. Big Bang (Cold Migration): Eski sunucu kapat, data kopyala, yeni sunucu aç. Downtime: 2-8 saat. Basit ama riskli.

2. Phased (Hot Migration): Paralel çalıştır, kademeli geçiş. Downtime: 0-10 dakika. Karmaşık ama güvenli.

3. DNS Cutover: DNS TTL düşür, yeni sunucuya yönlendir. Downtime: 0-5 dakika (DNS propagation).

Zero-Downtime Migration Adımları

Gün -7: Hazırlık

1. Yeni dedicated server al (aynı veya üst config)
2. OS kur (aynı versiyon: Ubuntu 22.04 → 22.04)
3. DNS TTL'yi 300 saniyeye düşür (24 saat önceden)

Gün -3: İlk Sync

rsync -avz --progress /var/www/ root@new-server:/var/www/

İlk sync 2-6 saat sürer (data boyutuna göre).

Gün -1: Test Sync

1. Database export: mysqldump --single-transaction db > db.sql
2. New server import: mysql db < db.sql
3. Config dosyaları kopyala (/etc/nginx, /etc/php)
4. SSL sertifikası kur (Let's Encrypt veya transfer)

Gün 0: Cutover (Low Traffic Hour)

Gece 03:00 (en düşük trafik saati):

1. Old server read-only mode (maintenance page)
2. Final rsync (delta sync, 2-5 dakika):

   rsync -avz --delete /var/www/ root@new-server:/var/www/

3. Database final export + import
4. New server test (curl, smoke test)
5. DNS A record güncelle (old IP → new IP)
6. 5 dakika bekle (DNS propagation)
7. Old server maintenance kaldır

Toplam downtime: 5-10 dakika.

Database Sync Stratejisi

Option 1: Master-Slave Replication

Old server master, new server slave. Real-time sync, cutover anında slave'i master yap.

Option 2: Application-Level Dual-Write

Uygulama hem eski hem yeni DB'ye yazar. Migration sonrası eski DB kapat.

Rollback Planı

Yeni sunucuda sorun çıkarsa:

1. DNS A record eski IP'ye geri çevir
2. 5 dakika bekle
3. Old server açık kalmalı (24 saat)

Email Server Migration

Kurumsal e-posta sunucusu migrate ediliyorsa:

1. MX record TTL düşür (48 saat önceden)
2. Mailbox sync (IMAP → IMAP, imapsync tool)
3. MX record güncelle
4. Test email gönder/al

File Storage: Rsync vs SCP

rsync: Incremental, delta transfer, resume destekli. 100GB data için ideal.

SCP: Tek seferlik transfer, resume yok. Küçük dosyalar (<10GB) için OK.

Load Balancer ile Zero-Downtime

Cloudflare/HAProxy arkasındaysanız:

1. New server load balancer pool'a ekle
2. Health check geç → trafik yeni sunucuya akar
3. Old server pool'dan çıkar

Gerçek zero-downtime (0 saniye).

Yaygın Hatalar

❌ DNS TTL unutmak: 86400 saniye (24 saat) TTL varsa, 24 saat beklemeniz gerekir.

❌ SSL sertifikası unutmak: New server'da SSL eksikse, HTTPS çalışmaz.

❌ Session data kaybı: Redis/Memcached session'ları migrate et.

Post-Migration Checklist

1. SSL Labs test (A+ rating)
2. Google Search Console fetch
3. Uptime monitor güncelle (new IP)
4. Analytics spike kontrol (traffic düştü mü?)
5. Old server 7 gün açık tut (rollback için)

Maliyet

Migration sırasında 2 sunucu paralel çalışır. Maliyet: €120 × 2 × 1 ay = €240. Ama zero-downtime → %0 revenue loss.

Managed Migration Servisi

Teknik ekibiniz yoksa, EuroVDC destek ekibi migration yapar. Cloud server + domain + SSL + e-posta tek panelden yönetilir.

Migration support: €200-500 (1 seferlik), zero-downtime garantisi.

Sonuç

Server migration sırasında downtime %90 azaltılabilir. DNS TTL + rsync + phased cutover = zero-downtime. Planlama kritik, rollback planı şart.