Site taşıma öncesi eksiksiz hosting yedek planı nasıl hazırlanır?

Site taşıma süreci yalnızca dosyaları yeni bir sunucuya aktarmaktan ibaret değildir. Yanlış ya da eksik alınmış bir yedek; sipariş kayıtlarının kaybolmasına, e-posta erişiminin kesilmesine, SEO performansının düşmesine ve geri dönüşü zor veri kayıplarına yol açabilir. Bu nedenle taşıma işleminden önce yazılı, kontrol edilebilir ve gerektiğinde tekrar uygulanabilir bir hosting yedek planı hazırlanmalıdır.

Yedek planının kapsamını doğru belirleyin

İlk adım, hangi varlıkların taşınacağını netleştirmektir. Sadece web sitesi dosyalarını indirmek çoğu zaman yeterli olmaz. WordPress kurulumlarında tema, eklenti, medya dosyaları ve veritabanı birlikte değerlendirilmelidir. Kurumsal yapılarda buna e-posta kutuları, DNS kayıtları, SSL sertifikaları, cron görevleri, özel yapılandırmalar ve alt alan adları da eklenir.

Taşıma öncesinde mevcut panelde yer alan tüm alan adlarını, subdomainleri, veritabanlarını ve kullanıcı hesaplarını listeleyin. Listeyi dosya yolu, veritabanı adı, kullanıcı yetkisi ve kullanım amacıyla birlikte tutmak, yeni ortamda eksik yapılandırma riskini azaltır.

Dosya ve veritabanı yedeklerini ayrı yönetin

Web sitesi dosyaları ile veritabanı farklı risklere sahiptir. Dosyalar genellikle FTP, SFTP veya kontrol paneli dosya yöneticisi üzerinden alınabilir. Veritabanı ise phpMyAdmin, komut satırı ya da panel yedek aracıyla dışa aktarılmalıdır. Büyük veritabanlarında zaman aşımı yaşanabileceği için mümkünse sıkıştırılmış dışa aktarma tercih edilmelidir.

WordPress için özellikle wp-content klasörü kritik öneme sahiptir. Tema ve eklentiler yeniden kurulabilir gibi görünse de özel düzenlemeler, yüklenen görseller ve lisanslı bileşenler bu dizinde yer alır. Veritabanı tarafında ise yazılar, ürünler, kullanıcılar, siparişler, ayarlar ve eklenti verileri saklanır.

Yedek dosyalarını adlandırma standardı oluşturun

Karışıklığı önlemek için yedekleri tarih, site adı ve içerik türüyle adlandırın. Örneğin siteadi-dosyalar-2026-06-30.zip ve siteadi-veritabani-2026-06-30.sql gibi açık isimler kullanın. Aynı gün içinde birden fazla işlem yapılacaksa saat bilgisini de eklemek faydalıdır.

E-posta, DNS ve SSL ayrıntılarını atlamayın

Site taşındığında en sık gözden kaçan alanlardan biri e-postadır. Mevcut posta kutularının IMAP yedekleri alınmalı, yönlendirmeler ve otomatik yanıtlar kaydedilmelidir. Kurumsal iletişimin kesilmemesi için MX, SPF, DKIM ve DMARC kayıtları ayrıca not edilmelidir.

DNS tarafında A, CNAME, TXT ve MX kayıtlarının ekran görüntüsünü almak pratik bir güvenlik adımıdır. Yeni sunucuya geçişte TTL değerlerinin önceden düşürülmesi, DNS yayılım süresinde daha kontrollü hareket etmenizi sağlar. SSL sertifikası otomatik kurulacaksa bile geçiş sonrası HTTPS yönlendirmeleri ve karma içerik uyarıları kontrol edilmelidir.

Yedeklerin çalıştığını mutlaka test edin

Yedek almak tek başına güvence değildir; geri yüklenebilir olduğundan emin olunmalıdır. Bunun için mümkünse geçici bir test alanında dosyalar ve veritabanı geri yüklenir. Ana sayfa, yönetim paneli, formlar, ödeme adımları ve kullanıcı girişi gibi kritik işlevler kontrol edilir.

Test sırasında PHP sürümü, veritabanı karakter seti, dosya izinleri ve eklenti uyumluluğu gibi teknik farklar sorun çıkarabilir. Yeni ortamın mevcut siteyle uyumlu olması, taşıma günü beklenmeyen kesintileri azaltır. Özellikle e-ticaret sitelerinde sipariş akışı devam ediyorsa taşıma zamanlaması düşük trafik saatlerine planlanmalıdır.

Taşıma öncesi kontrol listesi hazırlayın

• Tüm site dosyalarının sıkıştırılmış yedeğini alın.
• Veritabanını ayrı olarak dışa aktarın ve dosya boyutunu kontrol edin.
• E-posta kutuları, yönlendirmeler ve DNS kayıtlarını belgeleyin.
• SSL, cron görevleri, özel PHP ayarları ve alt alan adlarını listeleyin.
• Yedekleri yerel bilgisayar dışında güvenli ikinci bir konuma kopyalayın.
• Test geri yüklemesi yaparak kritik sayfaları ve formları deneyin.
• Taşıma sırasında içerik girişini geçici olarak sınırlandırın.

Riskleri azaltan pratik kararlar

Yedeklerin yalnızca mevcut sunucuda saklanması ciddi bir hatadır. Sunucu erişimi kaybedilirse bu yedeklere de ulaşılamaz. En sağlıklı yöntem, en az iki farklı konumda saklama yapmaktır: biri yerel, diğeri güvenli bulut depolama olabilir. Hassas veriler içeren arşivlerde parola koruması ve erişim yetkisi sınırlaması uygulanmalıdır.

Taşıma takvimi belirlenirken mevcut hosting hizmetinin bitiş tarihine dikkat edilmelidir. Eski hizmeti hemen kapatmak yerine birkaç gün aktif tutmak, eksik dosya veya unutulan yapılandırma durumunda geri dönüş imkanı sağlar. Ayrıca son yedek ile taşıma anı arasında oluşan yeni sipariş, yorum veya form kayıtları için kısa bir fark yedeği alınması veri tutarlılığını korur.

Plan tamamlandığında ekip içinde kimin yedek alacağı, kimin geri yükleme yapacağı ve kimin son kontrolleri onaylayacağı net olmalıdır. Böylece site taşıma süreci kişisel hafızaya değil, izlenebilir bir iş akışına dayanır ve yeni sunucu ortamına geçiş daha kontrollü ilerler.