Kısa cevap: WordPress yedeği, yalnız wp-content klasörünü indirmek veya hosting panelinde “Yedek alındı” yazısını görmek değildir. İşlevsel bir kurtarma planında site dosyaları, veritabanı, gerekli yapılandırma bilgileri, erişim yetkileri ve geri yükleme testi birlikte düşünülür. Yedeğin gerçekten işe yaradığını anlamanın en güvenilir yolu, orijinal siteye zarar vermeden kontrollü bir ortamda geri yükleyip temel işlevleri doğrulamaktır.
1. WordPress yedeğinde hangi parçalar bulunmalıdır?
WordPress çekirdek dosyaları ve eklentiler çoğu zaman yeniden indirilebilir. Ancak yüklenmiş medya, temadaki özel değişiklikler, eklentiye ait özel dosyalar ve özellikle veritabanındaki içerik ile ayarlar sitenize özgüdür. Yedek stratejisi bunları birlikte ele almalıdır. Veritabanında yazılar, sayfalar, kullanıcı kayıtları, menüler ve eklenti ayarları gibi bilgiler bulunabilir. Sadece dosyaları geri koyarsanız içerikler eksik kalabilir; yalnız veritabanını döndürürseniz medya veya özelleştirmeler kaybolabilir.
| Bileşen | Tipik içerik | Risk |
|---|---|---|
| Veritabanı | Yazılar, ayarlar, kullanıcılar | Son değişikliklerin kaybı |
| Site dosyaları | Tema, eklenti, medya | Eksik görsel veya işlev |
| Yapılandırma | Bağlantı ve sunucu ayarları | Yanlış ortamda açılma |
| Harici hizmetler | SMTP, DNS, ödeme ayarları | Geri dönüşte bağlantı kopması |
Her sırrı düz metin bir belgeye toplamayın. Erişim bilgilerini yetki kontrollü güvenli bir parola yöneticisinde tutun. Yedek dosyasının kendisi de hassas kişisel bilgiler içerebilir.
2. Yedekleme sıklığı nasıl belirlenir?
Her siteye uyan tek bir takvim yoktur. Nadiren güncellenen bir tanıtım sitesinin ihtiyacı, gün içinde sipariş alan mağazadan farklıdır. Sıklığı şu soruyla seçin: “Bir sorun olduğunda en fazla ne kadar yeni veriyi kaybetmeyi kabul ederim?” Bu, kurtarma noktası hedefi (RPO) olarak düşünülebilir. “Siteyi ne kadar sürede tekrar kullanılabilir hale getirebilmeliyim?” sorusu ise kurtarma süresi hedefi (RTO) ile ilgilidir.
Örneğin gün içinde onlarca sipariş alan bir işletmede yalnız haftalık yedek ciddi kayıp yaratabilir. Öte yandan sadece aylık güncellenen bir içerik sitesinde her beş dakikada bir tam dosya yedeği kaynak israfı olabilir. Güncellemelerden ve büyük düzenlemelerden hemen önce ayrıca bir kurtarma noktası oluşturmak yararlıdır.
3. Yedekleri neden aynı sunucuda bırakmamalısınız?
Tek kopya aynı sunucudaysa disk arızası, yanlışlıkla silme, hesap ele geçirilmesi veya sağlayıcı sorunu yedeğe de zarar verebilir. Farklı bir depolama ortamında, ayrı erişim yetkileriyle tutulan ek kopya bu riski azaltır. Sık kullanılan “3-2-1” yaklaşımı üç kopya, iki farklı ortam ve bir site dışı kopya düşüncesine dayanır; ancak önemli olan sayı ezberlemekten çok kopyaların birbirinden bağımsız, erişilebilir ve korunmuş olmasıdır.
Yedekleme otomatikse başarısız işler için bildirim kurun. “Zamanlandı” ile “son dosya sağlam biçimde tamamlandı” aynı durum değildir. Depolama alanı dolduğunda sessizce başarısız olan bir yedek planı, felaket anında fark edilen bir soruna dönüşebilir.
4. Hosting paneli, eklenti veya manuel yöntem mi?
Hosting panelleri tam hesap ve veritabanı yedeği sunabilir; WordPress eklentileri seçili dosyaları ve veritabanını zamanlayabilir; teknik ekipler komut satırı veya veritabanı araçları kullanabilir. Seçim, hangi parçalara eriştiğinize, geri yükleme yetkinize ve servis sağlayıcı sınırlarına bağlıdır. Bir aracın “tek tık yedek” sunması, geri yükleme için gerekli tüm adımları kapsadığını tek başına kanıtlamaz.
- Yedek kapsamını ve tamamlanma tarihini görün.
- Dosya ve veritabanı parçalarını doğrulayın.
- İkinci bir korumalı konuma kopyalandığını kontrol edin.
- Geri yükleme için gereken yönetici/sunucu erişimini belgeleyin.
- Belirli aralıklarla gerçek geri yükleme testi yapın.
5. Geri yükleme testi canlı siteyi bozmadan nasıl yapılır?
Mümkünse ayrı bir test alanı veya yerel geliştirme ortamı hazırlayın. Yedeği bu ortama yükleyin; veritabanı bağlantılarını ve gerekiyorsa test adresine ilişkin URL ayarlarını dikkatle uyarlayın. Test kopyasının arama motorları tarafından indekslenmesini engelleyin ve gerçek e-posta, ödeme veya müşteri bildirimlerini yanlışlıkla tetiklememesini sağlayın. Canlıdaki müşteri verilerini test ortamına taşırken erişim ve kişisel veri güvenliğini ayrıca değerlendirin.
İşlem bitince ana sayfa, örnek içerik, görseller, yönetici girişi, form ve sitenizin kritik işlevlerini test edin. Yalnızca “site açılıyor” demek yeterli değildir. Hataları ve geçen süreyi not ederek kurtarma planınızı iyileştirin.
6. Geri yükleme sırasında en sık ne ters gider?
Eksik veritabanı, uyumsuz PHP sürümü, yanlış dosya izinleri, farklı URL, kaybolan görseller ve eski eklenti sürümü sık görülen sorunlardır. Örneğin medya klasörü tam ancak veritabanındaki görsel bağlantıları eski alan adına işaret ediyorsa sayfalar kısmen bozuk görünebilir. Doğrudan veritabanında kontrolsüz metin değiştirme, serileştirilmiş WordPress verilerini bozabilir; uygun WordPress araçları ve güvenli prosedür kullanılmalıdır.
| Belirti | Olası kontrol | Kaçınılacak yaklaşım |
|---|---|---|
| Veritabanı bağlantı hatası | Sunucu ve bağlantı ayarı | Parolayı herkese açık paylaşmak |
| Medya görünmüyor | Dosya kapsamı ve URL’ler | Rastgele dosya silmek |
| Giriş çalışmıyor | Oturum, HTTPS, eklenti uyumu | Bütün güvenliği kalıcı kapatmak |
7. Yedek dosyasının güvenliğini nasıl korursunuz?
Yedek arşivini web kökünde doğrudan indirilebilir bırakmayın. Yalnız yetkili kişilere erişim verin; mümkün olduğunda depolama ve aktarım şifrelemesi kullanın. Erişim anahtarlarını düzenli gözden geçirin, eski personelin haklarını kaldırın. Yedekleri süresiz saklamak da gereksiz kişisel veri birikimine yol açabilir; iş gereksiniminiz ve ilgili kurallarla uyumlu bir saklama/silme politikası belirleyin. Web sitesi güvenlik kontrol listesindeki hesap ve erişim önlemleri burada da geçerlidir.
8. Kurtarma planının sahibi kim olmalı?
Yedekleme eklentisini kuran kişiyle acil durumda geri dönüşü yapacak kişi aynı olmayabilir. Kimin depolama hesabına erişebileceğini, kimin DNS değiştirebileceğini, nerede destek talebi açılacağını ve kimin kurtarmayı onaylayacağını belirleyin. İşletme açısından kritikse süreli tatbikat yapın. Bir testin başarılı olması sonsuza kadar geçerli değildir; tema, hosting veya eklenti değişikliklerinde planı tekrar gözden geçirin.
9. Uygulanabilir yedekleme kontrol listesi
- Dosyalarla veritabanı aynı kurtarma noktasını mı temsil ediyor?
- İşlem sıklığı kabul edilebilir veri kaybıyla uyumlu mu?
- En az bir bağımsız site dışı kopya mevcut mu?
- Başarısız yedekleme için bildirim var mı?
- Geri yükleme ayrı ortamda gerçek sayfalarla test edildi mi?
- Yedeklere yalnız yetkili kişiler erişebiliyor mu?
- Son testin tarihi, süresi ve sorunları kaydedildi mi?
Sık sorulan sorular
Hosting firmam yedek alıyorsa başka hiçbir şey yapmam gerekir mi?
Yedek kapsamını, saklama süresini ve geri yükleme hakkını doğrulayın. Ayrı bir kopya ve test planı riskleri azaltabilir.
Yedek dosyasının bulunması geri yüklenebileceğini kanıtlar mı?
Hayır. Arşiv eksik, hasarlı veya ortamla uyumsuz olabilir. Kontrollü geri yükleme testi gerekir.
Yalnız veritabanı yedeği yeterli midir?
Genellikle hayır. Medya dosyaları, özel tema ve eklenti dosyaları da kurtarma planının parçasıdır.