VPS'ten Dedicated Sunucuya Geçiş Rehberi

Sunucu geçişi, yanlış planlandığında saatler süren kesintiye ve veri kaybına yol açabilir. Dedicated sunucu geçişi doğru yapıldığında ise kullanıcıların fark etmeyeceği kadar kısa bir kesinti ile tamamlanabilir. Bu rehberde envanter çıkarma, rsync ile artımlı senkronizasyon, veritabanı taşıma, DNS cutover ve rollback planını adım adım ele alıyoruz.

Geçiş Öncesi Hazırlık

Geçişin başarısı, hazırlık aşamasının kalitesine bağlıdır. Aşağıdaki kontrol listesini geçiş planınızın temeli olarak kullanın:

• Envanter Çıkarma Çalışan servisleri, cron job'ları, veritabanlarını, SSL sertifikalarını, özel yapılandırma dosyalarını ve dış entegrasyonları listeleyin. systemctl list-units --type=service --state=running ve crontab -l ile başlayın.
• Yeni Sunucuyu Hazırlama Aynı OS sürümü, aynı yazılım versiyonları (PHP, Node.js, MySQL/PostgreSQL, Nginx). Sürüm uyumsuzluğu geçiş sonrası en yaygın sorun kaynağıdır.
• DNS TTL'i Düşürme Geçişten en az 48 saat önce DNS TTL değerini 300 saniyeye (5 dakika) düşürün. Bu, cutover sırasında DNS değişikliğinin hızla yayılmasını sağlar.
• Tam Yedekleme Geçiş öncesi eski sunucunun tam yedeğini alın. Snapshot veya tam disk yedekleme ile geri dönüş garantisi oluşturun.

rsync ile Dosya Senkronizasyonu

rsync, artımlı (incremental) dosya transferi yaparak yalnızca değişen verileri kopyalar. Bu sayede ilk tam kopyalama sonrası, cutover anında yalnızca son değişiklikler aktarılır ve kesinti süresi minimuma iner.

# 1. İlk tam senkronizasyon (geçişten 1-2 gün önce)
rsync -avzP --delete \
  -e "ssh -p 22" \
  /var/www/ \
  root@YENI_SUNUCU_IP:/var/www/

# 2. Yapılandırma dosyalarını kopyala
rsync -avzP \
  /etc/nginx/ \
  root@YENI_SUNUCU_IP:/etc/nginx/

rsync -avzP \
  /etc/letsencrypt/ \
  root@YENI_SUNUCU_IP:/etc/letsencrypt/

# 3. Cutover anında son delta senkronizasyonu
# (eski sunucuda servisleri durdurduktan sonra)
rsync -avzP --delete \
  /var/www/ \
  root@YENI_SUNUCU_IP:/var/www/

Veritabanı Taşıma Stratejileri

Veritabanı taşıma, geçişin en kritik adımıdır. Veri tutarsızlığı veya kayıp kabul edilemez. İş yükünüze göre iki strateji vardır:

Yöntem 1: Dump & Restore (Basit, Kısa Kesinti)

# Eski sunucuda: tüm veritabanlarını dışa aktar
mysqldump --all-databases --single-transaction \
  --routines --triggers --events \
  -u root -p | gzip > /tmp/all-databases.sql.gz

# Yeni sunucuya aktar
scp /tmp/all-databases.sql.gz root@YENI_SUNUCU_IP:/tmp/

# Yeni sunucuda: içe aktar
gunzip -c /tmp/all-databases.sql.gz | mysql -u root -p

# PostgreSQL için:
pg_dumpall -U postgres | gzip > /tmp/all-pg.sql.gz

Yöntem 2: Replikasyon (Sıfıra Yakın Kesinti)

Büyük veritabanlarında (10 GB+) dump/restore uzun sürer. MySQL replikasyon ile eski sunucuyu master, yeni sunucuyu slave olarak yapılandırın. Cutover anında slave'i master'a promote edin - kesinti saniyeler seviyesine iner. Detaylı replikasyon kurulumu için MySQL resmi replikasyon dokümantasyonuna bakabilirsiniz.

DNS Cutover ve TTL Stratejisi

DNS cutover, trafiği eski sunucudan yeni sunucuya yönlendiren son adımdır. Doğru TTL stratejisi ile kullanıcılar geçişi fark etmez.

Geçiş Sonrası Doğrulama

# DNS'in yeni IP'ye yönlendiğini doğrula
dig +short example.com A

# SSL sertifikasının çalıştığını kontrol et
curl -vI https://example.com 2>&1 | grep -E "subject|expire"

# Tüm servislerin çalıştığını doğrula
systemctl list-units --type=service --state=running

# Cron job'ların aktarıldığını kontrol et
crontab -l

# Veritabanı bağlantısını test et
mysql -u root -p -e "SHOW DATABASES; SELECT COUNT(*) FROM onemli_tablo;"

# HTTP yanıt kodlarını kontrol et
curl -o /dev/null -s -w "%{http_code}" https://example.com

Rollback Planı

Her geçişte bir şeylerin ters gidebileceğini kabul edin ve geri dönüş planı hazırlayın:

Rollback tetikleme kriterleri: HTTP 5xx hata oranı %5'i aşarsa, veritabanı bağlantı hataları oluşursa veya kritik iş akışları (ödeme, kayıt) çalışmıyorsa - hemen rollback yapın, sorunu sonra araştırın.

Sıkça Sorulan Sorular

Sonuç

Dedicated sunucu geçişi, doğru planlama ile kullanıcıların fark etmeyeceği kadar sorunsuz tamamlanabilir. Envanter çıkarma, rsync ile artımlı senkronizasyon, DNS TTL stratejisi ve rollback planı - bu dört adım geçişin temelini oluşturur. Geçişi düşük trafik saatlerinde yapın, her adımı doğrulayın ve eski sunucuyu en az 72 saat yedek olarak tutun.