WordPress yedekleme: UpdraftPlus mı sunucu yedeği mi?

WordPress’te yedek, sadece “kayıt var mı” sorusu değildir. Asıl mesele, hangi yedek türünün hangi senaryoda geri dönüşü hızlandırdığı ve geri yüklemenin (restore) gerçekten çalıştığıdır. Bu yazıda UpdraftPlus ile sunucu (hosting sağlayıcısı) tarafındaki yedeklerin farklarını; veri kapsamı, geri yükleme süresi, yedek doğrulama ve maliyet gibi somut başlıklarda karşılaştıracaksınız. En sonunda da NetKıyas mantığıyla “hangi durumda hangisi, ne zaman ikisi birden” şeklinde net bir seçim planı çıkaracağız.

UpdraftPlus vs sunucu yedeği: Temel fark nerede?

İki yaklaşım da “yedek almak” hedefinde birleşir; ancak kapsam ve geri dönüş davranışı farklıdır.

UpdraftPlus (eklenti) neyi kapsar?

UpdraftPlus (ve benzeri WordPress yedek eklentileri) genellikle şu bileşenleri hedefler: - WordPress dosyaları (wp-content dahil) - Veritabanı (MySQL/MariaDB) - Çoğu kurulumda ayarlanabilen yedek saklama: sağlayıcının diskinde veya harici bulutta (S3, Google Drive vb.)

UpdraftPlus’in kritik avantajı şudur: Yedek planını doğrudan WordPress seviyesinde kurgular. Örneğin “veritabanını her gece al, dosyaları haftada bir al” gibi ayrımlar yapılabilir.

Sunucu yedeği neyi kapsar?

Hosting sağlayıcısının sunduğu sunucu yedekleri genelde: - Dosyalar + veritabanını kapsayacak şekilde tasarlanır - “Kontrol paneli seviyesinde” (örn. Plesk/cPanel) ya da “altyapı seviyesinde” alınır - Çoğu zaman kullanıcıya tekil dosya indirme/restore garantisi yerine “sağlayıcı restore eder” modeliyle ilerler

Bu tür yedeklerin en büyük avantajı, WordPress hatalarına rağmen altyapıdan geri dönüş imkanıdır. Ancak her sağlayıcı aynı şeffaflıkta rapor sunmaz: yedeklerin içeriği, saklama süresi ve restore RTO’su (kurtarma süresi) netleşmeden karar vermek hatalı olur.

Veri kapsamı ve restore kalitesi: Hangisi daha güvenilir?

Yedek seçiminde en önemli soru şudur: “İhtiyaç anında uygulamayı geri başlatabilecek miyim?” Bunu belirleyen iki parametre vardır: kapsam ve restore edilebilirlik.

Senaryo 1: Eklenti/tema hatası veya yanlış güncelleme

• UpdraftPlus: WordPress seviyesinde alınan dosya + veritabanı yedekleri sayesinde, aynı eklentiyle restore daha doğrudan olur.
• Sunucu yedeği: Sağlayıcının aldığı anlık snapshot veya periyodik yedek; restore işleminin teslimat formatı (tam site mi, dosya bazında mı) değişkenlik gösterebilir.

Bu senaryoda tipik olarak UpdraftPlus daha hızlı deneyim sağlar; çünkü restore prosedürü WordPress kontrol paneli içinden yönetilebilir.

Senaryo 2: WordPress ele geçirilmesi (compromise) veya kötü amaçlı dosya

Burada yedek seçimi kadar, yedeğin “temiz” olup olmadığı belirleyicidir. - UpdraftPlus: Daha çok “alıntılandığı tarihte site nasılsa öyle” mantığıyla geri döner. Eğer güvenlik ihlali o tarihten sonra başladıysa temiz bir noktaya dönmeniz gerekir. - Sunucu yedeği: Benzer şekilde zamanlama kritik. Ancak altyapı snapshot’ları, WordPress dışında kalan bir katmanı (bazı cache/panel durumlarını) daha tutarlı geri getirebilir.

Önemli net kural: Ele geçirilme sonrası yalnızca “yedek var” demek yetmez. Restore ettiğinizde yönetim paneline giriş, admin kullanıcı kontrolü ve dosya bütünlüğü (özellikle wp-content) test edilmelidir.

Senaryo 3: Veritabanı bozulması

• UpdraftPlus: Veritabanı yedekleri net biçimde restore edilir. Bu, sık görülen “tablo bozuldu” veya “yanlış migration” durumlarında pratik bir avantajdır.
• Sunucu yedeği: Veritabanı yedeğinin formatı ve restore yöntemi şeffaf değilse kurtarma süresi uzayabilir.

RPO/RTO yaklaşımı: Planınızı net rakamlarla kurun

Karar verirken “ne kadar veri kaybı kabul edilebilir (RPO)” ve “ne kadar sürede geri dönmek gerekir (RTO)” sorularını yazın.

• RPO (Recovery Point Objective): Son yedek ile arıza anı arasındaki maksimum veri kaybı.
• RTO (Recovery Time Objective): Restore tamamlanıp sitenin tekrar çalışması için hedeflenen süre.

Örnek net hedefler (tipik WordPress siteleri için): - Gün içinde sık güncellenen blog/kurumsal site: RPO 6-12 saat, RTO 1-3 saat - WooCommerce veya kampanya dönemleri: RPO 1-6 saat, RTO 30-120 dakika

Bu hedeflere göre seçim şu şekilde netleşir: - Yalnızca sunucu yedeği kullanıyorsanız, sağlayıcının restore süresi ve yedek erişim modeli RTO’yu belirler. - Yalnızca UpdraftPlus kullanıyorsanız, sağlayıcının altyapı düzeyinde snapshot alıp almadığı kritik olur (özellikle disk bozulması veya yanlışlıkla silme gibi durumlarda). - En güvenli strateji çoğu zaman: UpdraftPlus + sunucu yedeği kombinasyonudur.

Yedek nerede saklanmalı? (Aynı sunucu mu, farklı lokasyon mu?)

Birçok kullanıcı “yedek aldım” der; ancak yedek aynı hatayı tekrar yaşar: sunucu çökerse yedek de çöker.

Net kural

• Yedeklerinizin en az bir kopyası sunucudan bağımsız bir yerde saklanmalıdır.

Bu bağımsızlık için pratik seçenekler: - UpdraftPlus ile harici depolama (S3, Google Drive, uzak bir depolama) - Sağlayıcının altyapısındaki yedeklerin farklı lokasyonda tutulması (sağlayıcı dokümanıyla doğrulanmalı)

NetKıyas açısından değerlendirme kriteri: Sağlayıcının yedek politikası “disk üstünde” ise bağımsızlık zayıftır. “Ayrı lokasyon/snapshot/immutable saklama” gibi ifadeler varsa şans artar.

UpdraftPlus’ı sunucu yedeğiyle birlikte kullanma: En mantıklı kurulum

Bu başlıkta hedefimiz “en güvenli” değil; “en az risk + net geri dönüş” kombinasyonudur.

Önerilen kurgu (pratik)

1. UpdraftPlus: Siteyi düzenli aralıklarla (ör. 6-12 saatte bir veritabanı, haftada bir dosya) yedekle.
2. Harici depolama: Yedekleri sunucudan bağımsız sakla.
3. Sunucu yedeği: Sağlayıcının periyodik yedeğini “ikinci kopya” gibi tut.
4. Aylık restore testi: En az ayda bir, yedeğinizi gerçekten geri yükleyin.

Yedek zamanlamasını netleştirin

WordPress için yedek zamanlaması performansı da etkiler.

• Yüksek trafik dönemlerinde dosya taraması ve büyük DB dump’ları gecikme yaratabilir.
• Bu nedenle:
• DB yedeği daha sık
• Dosya yedeği daha seyrek
• Trafiğin en düşük olduğu saatleri tercih edin

NetKıyas kontrol listesi: Karar vermeden önce 10 soru

Aşağıdaki soruların yanıtı net değilse “tek bir yöntem” seçmek risklidir.

1. UpdraftPlus yedeği hangi dosyaları kapsıyor? (özellikle wp-content)
2. UpdraftPlus veritabanı yedeği sağlam mı? (restore sonrası kontrol)
3. Sunucu yedeği restore edilebilir mi, yoksa sadece iade süreçleri mi var?
4. Sunucu yedeği saklama süresi kaç gün? (7 mi 30 mu 90 mı)
5. Yedekler aynı sunucuda mı tutuluyor, yoksa farklı lokasyon var mı?
6. Restore işlemi için ortalama süre nedir? (RTO ölçümü)
7. Yedeklerden geri dönüşte dosya izinleri (permissions) sorun çıkarıyor mu?
8. Eklentiler (UpdraftPlus dahil) log üretimi ve hata bildirimi yapıyor mu?
9. Yedek başarısız olursa bildirim geliyor mu? (e-posta/uyarı)
10. Yedeklerinizi aylık restore testi ile doğruluyor musunuz?

Yedek başarısızlığını önlemek: En sık hatalar ve net çözümler

Hata 1: Yedek alınıyor ama restore edilmiyor

Net çözüm: Restore testini “bir kere” değil, düzenli yapın. En az ayda bir küçük bir staging ortamında deneyin.

Hata 2: Yedek boyutu büyüdü, süre uzadı

Net çözüm: - UpdraftPlus’ta gereksiz klasörleri hariç tutun (ör. transient yoğunluğu, büyük loglar) - Yedek sıklığını trafik ve değişim hızına göre ayarlayın

Hata 3: Sadece bir lokasyona bağlı kalmak

Net çözüm: Sunucu yedeğine ek olarak harici depolama veya farklı lokasyon kopyası ekleyin.

UpdraftPlus mı sunucu yedeği mi? “Hızlı karar” tablosu

Aşağıdaki tablo, durumunuza göre net öneri verir.

Sonuç: Aksiyon planı (bugün yapabileceğiniz 5 adım)

Net bir yedek stratejisi için tek doğru yok; doğru olan, kapsam + bağımsız saklama + düzenli restore testi üçlüsünü kurmaktır. Bu nedenle çoğu WordPress ortamında en güvenilir kurgu UpdraftPlus ile WordPress seviyesinde yedek + harici depolama ve buna ek olarak sağlayıcının sunucu yedeği olarak ikinci kopyayı korumaktır.

Bugün yapmanız gerekenler: - UpdraftPlus yedek aralığını RPO hedefinize göre ayarlayın. - Yedekleri sunucudan bağımsız saklayacak şekilde yapılandırın. - Sağlayıcınızın sunucu yedek saklama süresini ve restore modelini netleştirin. - Bu ay içinde en az bir kez yedekten restore testi yapın. - Yedek başarısız olursa bildirim aldığınızdan emin olun.

Bu adımları tamamladığınızda “yedek var mı?” yerine “yedek çalışıyor mu?” sorusunun cevabı somut biçimde netleşir.