Hosting Taşırken Yedek ve Geri Dönüş Planı

Hosting taşırken asıl risk çoğu zaman sunucuyu değiştirmek değil, geri dönüş planı olmadan değişiklik yapmak olur. Sağlam bir yedek ve net bir geri dönüş sırası kurarsanız, kesinti ve veri kaybı ihtimalini belirgin biçimde azaltırsınız.

Bu yazı, taşıma öncesinde hangi yedeğin alınacağını, geri dönüşün nasıl doğrulanacağını ve eski sunucunun ne zaman güvenle kapatılacağını adım adım toparlar; DNS gecikmesini de planın parçası olarak ele alır.

Hosting Taşırken Yedek ve Geri Dönüş Planı​

Taşıma öncesi tam yedek neden gerekir?​

Bir hosting değişiminde yalnızca dosyaları kopyalamak çoğu zaman yeterli olmaz. Veritabanı, yapılandırma dosyaları, yüklenmiş medya, özel izinler ve varsa e-posta verisi birlikte düşünülmelidir. Geri dönüş planı, "bir sorun çıkarsa eski duruma nasıl dönerim?" sorusuna tek cümlelik bir cevap vermeyi değil, bu dönüşün gerçekten uygulanabilir olmasını gerektirir.

Bu yüzden yedek iki ayrı amaç taşır: yeni ortama veri taşımak ve sorun çıkarsa eski duruma dönebilmek. Aynı yedeğin bu iki işi de karşılaması bekleniyorsa, geri yükleme denemesi yapılmadan güvenli sayılmaz. Özellikle veritabanı içeren sitelerde sadece dosya yedeği almak, sitenin çalışır halde geri gelmesini garanti etmez.

Hangi parçalar birlikte yedeklenmeli?​

• Site dosyaları: Tema, eklenti, yüklemeler ve elle eklenmiş içerik.
• Veritabanı: Yazı, kullanıcı, ayar ve sipariş gibi dinamik veriler.
• Yapılandırma:.htaccess, özel kurallar, cron ayarları ve uygulama yapılandırması.
• E-posta varsa: Posta kutuları, yönlendirmeler ve DNS kayıtları.

Dosyaları tek başına saklamak, sitenin görünür tarafını geri getirir ama veritabanı bozulmuşsa site yine eksik açılır. Bu nedenle yedek sırasını, sitenin teknik yapısına göre değil, geri dönüşte ihtiyaç duyacağı bütün bileşenlere göre kurmak gerekir.

Geri dönüş planı nasıl yazılır?​

Geri dönüş planı, "olursa bakarız" düzeyinde bırakılmamalıdır. Hangi durumda geri dönüleceği, kim tarafından onaylanacağı, hangi yedeğin kullanılacağı ve dönüşten sonra hangi kontrolün yapılacağı açık olmalıdır. Bu liste kısa ama net olursa, taşıma sırasında karar vermek kolaylaşır.

Örneğin bir geçişte uygulama açılmıyor, yönetim paneli veri göstermiyor ya da ödeme işlemleri bozuluyorsa, geri dönüş eşiği önceden belirlenmiş olmalıdır. Böylece sorun uzadıkça veri farkı büyümeden eski ortama dönmek mümkün olur.

DNS ve TTL neden yedek planının parçasıdır?​

DNS geçişi, taşımanın teknik olarak en hassas kısmıdır; çünkü kullanıcıların bir bölümü eski, bir bölümü yeni sunucuya gitmeye devam edebilir. TTL değerini önceden düşürmek, kayıtların daha hızlı yenilenmesini sağlar ve kesim anında beklenmedik gecikmeleri azaltır.

Bu noktada amaç DNS'i "hızlandırmak" değil, değişiklik sonrası eski kayıtlara takılı kalan istemci sayısını azaltmaktır. Yedek ve geri dönüş planı, DNS yayılımı boyunca iki ortamın bir süre birlikte yaşayacağını kabul etmelidir.

Kesim anında hangi sırayı izlemelisiniz?​

Önce yeni ortamı, sonra DNS'i değiştirin​

Yeni sunucuya içerik kopyalanmadan DNS değiştirmek, kullanıcıların yarım kurulmuş bir sisteme gitmesine yol açar. Doğru sıra önce içeriği ve yapılandırmayı hazırlamak, sonra kontrollü biçimde DNS güncellemesi yapmaktır. Google'ın barındırma değişimi kılavuzu da yeni altyapıyı önce hazırlamayı, sonra DNS'i güncellemeyi ve son olarak eski altyapıyı kapatmayı önerir.

Buradaki pratik sonuç şudur: "yedek aldım" demek yeterli değildir; yeni ortamın aynı içeriği doğru çalıştırdığını görmeden trafiği ona çevirmemelisiniz. Aksi halde sorun çıktığında neyin yanlış olduğunu ayırt etmek zorlaşır.

Eski sunucuyu ne zaman kapatmalısınız?​

Eski sunucuyu, sadece DNS değiştiği için kapatmak doğru değildir. Trafiğin eski altyapıda sıfıra yaklaştığını, yeni ortamın hatasız çalıştığını ve geri dönüşe gerek kalmadığını görmeden kapanış yapmayın. Google, eski sunucudaki trafik sıfıra yaklaşmadan altyapıyı kapatmamanızı açıkça söyler.

Bu yaklaşım, sessiz kayıp riskini azaltır. Çünkü bazı kullanıcılar veya ağlar eski DNS kaydını bir süre daha kullanabilir; erken kapatma, o kullanıcılar için doğrudan erişim kaybı üretir.

Taşıma sonrası hangi kontrol yeterli sayılır?​

Kontrol, yalnızca ana sayfanın açılması değildir. Günlüklerde eski ve yeni sunucuya düşen istekleri karşılaştırmalı, yönetim paneli, oturum açma, form gönderimi ve veritabanı okuma-yazma akışını da doğrulamalısınız. Google'ın önerdiği gibi, eski ve yeni sunucudaki trafik değişimini birlikte izlemek taşımayı güvenle bitirmenin parçasıdır.

Eğer bu kontroller sırasında yalnızca belirli bir alt bölüm çalışmıyorsa, sorun çoğu zaman yedek değil, eksik taşınmış yapılandırmadır. Bu yüzden kontrol listesi ile yedek listesi aynı şey değildir; ikisi ayrı tutulmalıdır.

Kısa uygulama sırası​

• Tam yedek al.
• Yedeği ayrı bir yerde geri yükleyerek dene.
• TTL'i önceden düşür.
• Yeni ortamı tam çalışır hale getir.
• DNS'i yeni ortama çevir.
• Eski ve yeni günlükleri izleyerek trafiğin dağılımını kontrol et.
• Trafik eski sunucuda sıfıra yaklaşınca eski sistemi kapat.

Bu sıra, taşımayı tek bir "anahtar çevirme" işlemi olmaktan çıkarıp kontrollü bir geçişe dönüştürür. Asıl güvenlik de burada oluşur: geri dönüş seçeneği, sorun çıkmadan önce hâlâ elinizdeyken karar verebilmek.