Hosting sağlayıcısı kapanırsa site sahipleri hangi yedeklere ihtiyaç duyar?

Bir web sitesinin erişilemez hale gelmesi yalnızca teknik bir kesinti değildir; siparişlerin durması, müşteri taleplerinin kaçması, marka güveninin zedelenmesi ve arama motoru görünürlüğünün risk altına girmesi anlamına gelir. Özellikle hosting sağlayıcısının kapanması, iflas etmesi, panel erişimini durdurması veya destek kanallarını kapatması durumunda site sahibinin elindeki yedekler, iş sürekliliğini belirleyen en kritik varlık haline gelir.

Bu nedenle yedekleme planı sadece “dosyaları indirdim” yaklaşımıyla ele alınmamalıdır. Web sitesi; dosyalar, veritabanı, e-posta kayıtları, alan adı ayarları, SSL bilgileri, DNS yapılandırması ve uygulama sürümleriyle birlikte değerlendirilmelidir. Eksik alınan tek bir parça, yeni sunucuya geçiş sırasında sitenin açılmamasına veya veri kaybına yol açabilir.

Mutlaka elde bulunması gereken temel yedekler

Web sitesi dosyaları

İlk ihtiyaç, sitenin tüm dosyalarının güncel bir kopyasıdır. WordPress için bu dosyalar genellikle tema, eklenti, yüklenen medya dosyaları ve çekirdek sistem dosyalarından oluşur. Sadece tema klasörünü almak yeterli değildir; özellikle wp-content/uploads klasörü görselleri, PDF dosyalarını ve kullanıcı tarafından yüklenen içerikleri barındırır.

Yedek alınırken gizli dosyalar da kontrol edilmelidir. .htaccess, güvenlik kuralları, yönlendirmeler ve kalıcı bağlantı ayarları açısından önemlidir. Bu dosya eksikse yeni sunucuda site açılabilir ancak bazı sayfalar 404 hatası verebilir.

Veritabanı yedeği

WordPress sitelerde yazılar, sayfalar, kullanıcılar, ürünler, siparişler, yorumlar ve ayarların büyük bölümü veritabanında tutulur. Dosya yedeği olsa bile veritabanı yoksa site içeriksiz veya hatalı açılır. Bu nedenle SQL formatında alınmış güncel bir veritabanı yedeği zorunludur.

Veritabanı yedeğinin yalnızca alınması değil, okunabilir ve içe aktarılabilir durumda olması gerekir. Çok büyük veritabanlarında dışa aktarma yarım kalabilir. Bu durumda sıkıştırılmış SQL dosyası, tablo bazlı dışa aktarma veya profesyonel taşıma aracı kullanmak daha güvenlidir.

E-posta ve alan adı tarafında unutulan kritik bilgiler

E-posta hesapları ve arşivler

Birçok işletme, web sitesiyle birlikte aynı sağlayıcı üzerinden e-posta hizmeti kullanır. Sağlayıcı kapanırsa sadece site değil, kurumsal e-posta geçmişi de kaybolabilir. Bu nedenle IMAP üzerinden posta kutularının yerel arşivi alınmalı, önemli yazışmalar dışa aktarılmalı ve yeni servis için hesap listesi hazırlanmalıdır.

Özellikle teklif, sözleşme, fatura, destek ve müşteri talepleri içeren posta kutuları öncelikli değerlendirilmelidir. Kullanıcı adları, takma adlar, yönlendirme adresleri ve otomatik yanıt ayarları ayrıca not edilmelidir.

DNS kayıtları ve alan adı erişimi

Alan adı farklı bir firmada olsa bile DNS kayıtları kapanan sağlayıcı üzerinde yönetiliyor olabilir. Bu durumda A kaydı, CNAME, MX, TXT, SPF, DKIM ve DMARC kayıtlarının ekran görüntüsü veya metin listesi alınmalıdır. Yeni sunucuya geçişte bu kayıtlar doğru girilmezse site açılmaz, e-postalar çalışmaz veya iletiler spam klasörüne düşer.

Alan adı paneline erişimin kimde olduğu da netleştirilmelidir. Sadece web tasarım ajansında veya eski teknik personelde bulunan erişimler, kriz anında taşıma sürecini uzatır. Alan adı sahibi bilgileri, transfer kilidi durumu ve yetkilendirme kodu kontrol edilmelidir.

Yeni ortama geçiş için teknik hazırlık

PHP, veritabanı ve uygulama sürümleri

Yeni ortama geçerken yalnızca yedeklerin varlığı yeterli değildir. Eski sistemde kullanılan PHP sürümü, MySQL veya MariaDB sürümü, WordPress sürümü ve kritik eklentiler bilinmelidir. Çok eski bir site yeni bir ortamda hatalar verebilir; çok yeni bir ortam da eski eklentilerle uyumsuz çalışabilir.

Taşıma öncesinde geçici bir test alanı oluşturmak iyi bir uygulamadır. Site burada açılır, formlar denenir, ödeme adımları kontrol edilir, görseller ve kalıcı bağlantılar incelenir. Böylece canlı yayına geçmeden önce eksikler görünür hale gelir.

SSL sertifikası ve güvenlik ayarları

SSL sertifikası eski sağlayıcıya bağlıysa yeni ortamda yeniden kurulması gerekir. Sertifika yenilenmeden site tarayıcıda güvenli görünmeyebilir. Ayrıca güvenlik duvarı kuralları, IP kısıtlamaları, yönetici paneli korumaları ve yedekleme eklentisi ayarları yeni sisteme uyarlanmalıdır.

Yedeklerin doğruluğu nasıl kontrol edilmeli?

Yedeklerin güvenilir olması için yalnızca dosya boyutuna bakmak yeterli değildir. Aşağıdaki kontroller pratik bir doğrulama sağlar:

• Dosya yedeğinde tema, eklenti ve yükleme klasörlerinin bulunduğunu kontrol edin.
• Veritabanı dosyasının boş olmadığını ve SQL tablolarını içerdiğini doğrulayın.
• E-posta arşivlerinin açılabildiğini ve önemli klasörlerin dahil olduğunu inceleyin.
• DNS kayıtlarını metin olarak saklayın; yalnızca ekran görüntüsüne güvenmeyin.
• Yedekleri tek bir bilgisayarda değil, en az iki farklı güvenli konumda tutun.

Yedekleme periyodu sitenin türüne göre belirlenmelidir. Kurumsal tanıtım siteleri için haftalık yedek çoğu zaman yeterliyken, e-ticaret ve üyelik sistemlerinde günlük hatta saatlik yedek gerekebilir. Sipariş alan, form toplayan veya kullanıcı verisi işleyen sitelerde eski bir yedeğe dönmek doğrudan veri kaybı anlamına gelebilir.

Kriz yaşanmadan önce hazırlanması gereken liste

Site sahipleri, olası bir hosting kesintisine karşı erişim ve yedek envanteri oluşturmalıdır. Bu listede yönetim paneli bilgileri, alan adı firması, DNS kayıtları, veritabanı adı, FTP veya SFTP erişimi, e-posta hesapları, kullanılan lisanslı tema ve eklentiler yer almalıdır.

Bu listenin güncel tutulması, sağlayıcı kapanmadan önce değil, rutin bakım sürecinin parçası olarak ele alınmalıdır. Yetkili kişilerin değişmesi, ajansla çalışmanın sona ermesi veya ödeme bilgilerinin güncellenmemesi gibi idari detaylar da teknik kesinti kadar risk yaratabilir. Doğru yedek seti ve erişim planı hazır olduğunda, yeni ortama geçiş daha kontrollü, ölçülebilir ve daha az kayıpla yönetilir.