Sunucu taşımanın riski taşımanın kendisinde değil, geri dönüş planı olmadan başlanmasında. Doğru planlanmış bir geçişte kesinti dakikalarla ölçülür; plansız bir geçişte ise sorun çıktığında geri dönecek yer olmadığı için saatlerle.
Kısa cevap: Sunucu taşıma kesintisiz yapılabilir mi?
Evet — kesinti, DNS yönlendirmesinin yayılma süresiyle sınırlı tutulabilir ve doğru hazırlıkla bu süre dakikalara indirilebilir. Bunun iki koşulu vardır: geçişten 24–48 saat önce DNS TTL değerinin düşürülmesi ve yeni sunucunun canlı trafiğe açılmadan önce tam olarak test edilmiş olması. Eski sunucu, geçişten sonra en az bir hafta ayakta bırakılırsa geri dönüş de her an mümkün kalır.
Taşıma öncesi envanter: neyi taşıyorsunuz?
Geçişlerde yaşanan aksaklıkların çoğu, "site" sanılan şeyin aslında birbirine bağlı birkaç sistem olmasından kaynaklanır. Taşımadan önce şunların listesi çıkarılmalıdır:
- Web dosyaları: uygulama kodu, tema, eklentiler ve kullanıcı tarafından yüklenmiş dosyalar (en sık atlanan kalem budur).
- Veritabanı: sürüm numarası, karakter seti ve karşılaştırma (collation) ayarları dahil.
- E-posta: posta kutuları, iletme kuralları, otomatik yanıtlar. Alan adı taşınıyorsa MX kayıtları kritiktir.
- DNS kayıtları: A, MX, TXT (SPF/DKIM/DMARC), CNAME. Doğrulama kayıtlarının unutulması sık görülür.
- SSL sertifikaları: yeni sunucuda yeniden kurulmalı veya yeniden üretilmelidir.
- Zamanlanmış görevler (cron): yeni sunucuda kendiliğinden oluşmazlar.
- Yapılandırma: PHP sürümü ve ayarları, .htaccess kuralları, dizin izinleri.
- Dış entegrasyonlar: ödeme sistemleri, kargo, muhasebe veya e-fatura servisleri — bazıları IP tabanlı izin listesi kullanır ve yeni IP'nin tanıtılması gerekir.
Bu son madde özellikle önemlidir: sunucu değişince IP adresi de değişir. IP kısıtlaması olan bir entegrasyon, taşıma sonrası sessizce çalışmayı bırakır ve bu genellikle ilk siparişte fark edilir.
DNS ve TTL: kesinti süresini belirleyen tek ayar
Alan adınızın hangi sunucuya işaret ettiği bilgisi, dünya genelindeki DNS sunucularında bir süre önbelleklenir. Bu sürenin adı TTL'dir (Time To Live). TTL 14400 saniye (4 saat) ise, yönlendirmeyi değiştirdiğinizde bazı ziyaretçiler 4 saate kadar eski sunucuya gitmeye devam eder.
Çözüm basittir ama zamanlaması kritiktir: geçişten 24–48 saat önce TTL değerini 300 saniyeye (5 dakika) düşürün. Böylece geçiş anında yayılma dakikalar içinde tamamlanır. Geçiş tamamlanıp her şey doğrulandıktan sonra TTL'i eski değerine geri çıkarabilirsiniz.
Bu adım atlanırsa ne olur? Geçiş sırasında ziyaretçilerin bir kısmı eski, bir kısmı yeni sunucuya gider. Sipariş alan bir sitede bu, iki farklı veritabanına yazılan siparişler anlamına gelir — ve bu, taşımanın en pahalı hatasıdır.
12 adımlık geçiş planı
| # | Adım | Ne zaman | Kritik nokta |
|---|---|---|---|
| 1 | Envanter çıkar | T-7 gün | Dış entegrasyonları ve IP kısıtlamalarını listele |
| 2 | Yeni ortamı hazırla | T-5 gün | PHP/veritabanı sürümleri eskiyle uyumlu olmalı |
| 3 | Tam yedek al | T-3 gün | Yedeğin geri yüklenebildiğini doğrula |
| 4 | Dosya ve veritabanını kopyala | T-2 gün | İlk kopya; canlı trafik hâlâ eskide |
| 5 | TTL'i 300 sn'ye düşür | T-2 gün | Atlanırsa kesinti saatlere çıkar |
| 6 | Yeni sunucuda test et | T-1 gün | hosts dosyasıyla gerçek alan adı üzerinden test |
| 7 | SSL, cron, e-posta kur | T-1 gün | Sertifika ve zamanlı görevler taşınmaz, kurulur |
| 8 | Yazma işlemlerini dondur | T-0 | Sipariş/form alan sistemlerde zorunlu |
| 9 | Son senkronizasyon | T-0 | Yalnızca değişen veriyi aktar |
| 10 | DNS'i yeni sunucuya çevir | T-0 | Asıl geçiş anı |
| 11 | Doğrulama yap | T+0–2 saat | Aşağıdaki kontrol listesi |
| 12 | Eski sunucuyu 1 hafta tut | T+7 gün | Geri dönüş imkânı ve kaçan veri kontrolü |
Yazma dondurma penceresi neden gerekli?
Dosya ve veritabanı kopyalandıktan sonra DNS geçişi tamamlanana kadar geçen sürede, eski sunucuya gelen ziyaretçiler orada işlem yapmaya devam eder. O işlemler yeni sunucuya aktarılmadıysa kaybolur.
Statik bir tanıtım sitesinde bu sorun değildir. Ancak sipariş, form, üyelik veya stok hareketi olan bir sistemde dondurma penceresi zorunludur. Pratik uygulama: geçişi düşük trafikli bir saate (örneğin gece) planlamak, o aralıkta sitede bir bakım bildirimi göstermek ve pencereyi mümkün olduğunca kısa tutmak.
Geri dönüş (rollback) planı
İyi bir geçiş planının en önemli parçası, geçişin başarısız olması ihtimaline verilen cevaptır. Geri dönüş planı üç şeyi içermelidir:
- Karar kriteri: Hangi durumda geri dönülecek? ("Ödeme akışı 30 dakika içinde çalışmazsa" gibi net bir eşik.)
- Geri dönüş yöntemi: DNS'i eski IP'ye çevirmek. TTL düşük tutulduğu için bu da dakikalar sürer.
- Veri uzlaştırma: Yeni sunucuda geçen sürede oluşan kayıtlar varsa nasıl aktarılacak.
Eski sunucunun bir hafta ayakta tutulmasının nedeni budur. Maliyeti bir haftalık hizmet bedelidir; karşılığı ise geçişin krize dönüşmemesidir.
Taşıma sonrası doğrulama listesi
- Ana sayfa ve iç sayfalar açılıyor mu, sayfa boyutları normal mi?
- Formlar çalışıyor ve e-posta gönderiyor mu? (En sık bozulan işlev budur.)
- Ödeme akışı uçtan uca test edildi mi?
- SSL sertifikası geçerli mi, karma içerik (mixed content) uyarısı var mı?
- Yönlendirmeler (www/non-www, http→https) doğru çalışıyor mu?
- E-posta gönderimi ve alımı test edildi mi? SPF/DKIM kayıtları yeni IP'yi kapsıyor mu?
- Zamanlanmış görevler çalışıyor mu?
- Dış entegrasyonlar yeni IP'yi kabul ediyor mu?
- Arama motoru erişimi açık mı — test ortamından kalan bir engelleme kuralı taşınmış olabilir.
- Yedekleme yeni sunucuda kuruldu mu?
Bu listenin sondan üçüncü maddesi özellikle önemlidir: test ortamlarında arama motorlarını engellemek yaygın bir uygulamadır ve bu ayar yanlışlıkla canlıya taşındığında site aramalardan sessizce düşer. Etkisi haftalar sonra fark edilir.
Netişlem uzman görüşü: geçişlerde en sık gördüğümüz üç hata
Birincisi, TTL'in düşürülmemesi. Teknik olarak her şey doğru yapılmış olabilir; ama TTL yüksek kaldığı için geçiş saatlere yayılır ve o saatlerde iki sunucu birden canlı olur. Sipariş alan sitelerde bu, kaybolan veri demektir.
İkincisi, e-postanın unutulması. Site taşınır, çalışır, herkes rahatlar — ancak MX veya SPF kayıtları güncellenmediği için giden e-postalar spam'e düşmeye başlar. Bu, taşımadan günler sonra ve genellikle bir müşteri şikâyetiyle fark edilir.
Üçüncüsü, eski sunucunun hemen kapatılması. Maliyetten tasarruf etmek için eski hizmet iptal edilir; sonra fark edilen küçük bir eksik (yedeklenmemiş bir klasör, bir yapılandırma dosyası) geri alınamaz hale gelir.
Bu üçünün ortak yanı, hiçbirinin taşıma anında görünmemesi. Bu yüzden doğrulama listesini taşımadan sonraki ilk saatte değil, ilk hafta boyunca tekrar tekrar uygulamayı öneriyoruz.
Sık sorulan sorular
Taşıma sırasında sitem ne kadar kapalı kalır?
TTL önceden düşürülmüşse ve yeni sunucu hazır test edilmişse kesinti dakikalarla sınırlıdır; statik sitelerde hiç kesinti olmayabilir. Uzun kesintilerin neredeyse tek nedeni, DNS hazırlığının atlanmasıdır.
SEO sıralamam etkilenir mi?
URL yapısı ve içerik değişmiyorsa doğru yapılmış bir taşımanın olumsuz etkisi beklenmez. Risk üç yerden gelir: uzun kesinti, yönlendirme hataları ve test ortamından taşınan arama motoru engelleme kuralı. Üçü de doğrulama listesiyle önlenebilir.
E-postalarım taşınır mı?
Otomatik değil. Posta kutularının içeriği ayrıca aktarılmalı, MX ve doğrulama kayıtları güncellenmelidir. Aktarım sırasında gelen e-postaların kaybolmaması için eski posta sunucusunun bir süre daha çalışır durumda kalması önerilir.
Taşımayı hafta içi mi hafta sonu mu yapmalı?
Belirleyici olan gün değil, sizin trafik ve işlem yoğunluğunuzun en düşük olduğu zaman dilimidir. Ayrıca sorun çıkarsa müdahale edecek kişilerin ulaşılabilir olduğu bir zaman seçilmelidir — gece yarısı düşük trafiklidir ama destek de o saatte zayıftır.
Kendim mi taşımalıyım, hizmet mi almalıyım?
Basit, statik bir site için taşıma yönetilebilir bir iştir. Ancak veritabanı, e-posta, ödeme entegrasyonu ve zamanlanmış görevler devredeyse, hata maliyeti hizmet bedelinin çok üzerine çıkabilir. Ölçüt teknik zorluk değil, bir aksaklığın işinize maliyetidir.
Sonuç
Kesintisiz taşımanın sırrı hızlı çalışmak değil, geri dönülebilir bir plan kurmaktır. TTL'i önceden düşürün, yeni sunucuyu canlıya almadan test edin, yazma penceresini dondurun ve eski sunucuyu bir hafta ayakta tutun. Bu dördü uygulandığında taşıma bir risk değil, rutin bir bakım işlemi haline gelir.
Taşımanızı sizin adınıza planlamamızı ve yürütmemizi isterseniz bize ulaşın. Ücretsiz geçiş desteğimizi, kurumsal barındırma ve yönetilen sunucu çözümlerimizi inceleyebilirsiniz.