WordPress Yedekleme: UpdraftPlus mı Sunucu Yedeği mi?

WordPress’te yedekleme konusu “dosyaları kopyalamak” gibi görünse de pratikte üç şey kritik rol oynar: geri dönüş (restore) hızı, yedeğin doğruluğu ve yedeğin bağımsızlığı. Bu rehberde UpdraftPlus (yedek eklentisi) ile sunucu tarafı yedeğini (storage/snapshot veya kontrol paneli yedeği) teknik olarak karşılaştıracağız. Hangi durumda hangisini tercih edeceğinizi, iki katmanlı yaklaşımda nelere dikkat edeceğinizi ve yedekleri nasıl test edeceğinizi net şekilde öğreneceksiniz.

UpdraftPlus ile sunucu yedeği aslında neyi yedekler?

UpdraftPlus, WordPress’in iç bileşenlerini hedefleyerek çalışır. Sunucu yedeği ise dosya sistemi + gerektiğinde veritabanını kapsar; yöntem servis sağlayıcıya göre değişir.

UpdraftPlus (plugin) ile tipik kapsam

UpdraftPlus çoğunlukla şu bileşenleri paketler: - wp-content (tema, eklenti, yüklenen medya) - WordPress veritabanı (MySQL/MariaDB) - Opsiyonel olarak çekirdek dosyaları/konfigürasyonlar (kuruluma göre) - Dosyaları harici hedeflere aktarabilir: S3 uyumlu depolama, Google Drive, Dropbox vb.

UpdraftPlus tarafında önemli nokta şudur: Yedeğin kalitesi, WordPress’in “çalışır durumda”yken üretilmesine bağlıdır. Site kilitlenmiş, veritabanı bozulmuş ya da kötü amaçlı değişiklikler yapılmışsa plugin yedeği de “bozuk durumu” taşıyabilir.

Sunucu yedeği (hosting sağlayıcı) ile tipik kapsam

Sunucu yedeğinde yöntemler şunlardan biri veya birkaçıdır: - Dosya sistemi snapshot’u (LVM/ZFS snapshot gibi) - Kontrol paneli yedeği (Plesk/cPanel/DirectAdmin otomasyonları) - Depolama tabanlı otomatik yedek (rsync benzeri transfer)

Sunucu yedeği çoğu zaman şu kazanımları sağlar: - Hosting altyapısı seviyesinde tutarlılık (dosya + DB aynı zaman penceresinde olabilir) - Sunucu tarafında log/konfigürasyon dosyalarına erişim - UpdraftPlus eklentisine bağımlılığın azalması

Ancak sunucu yedeğinin “kapsam” detayı sağlayıcıya göre değişir. Bazı paketlerde sadece dosyalar yedeklenir, bazı paketlerde veritabanı da dahil edilir, bazı durumlarda da yedekler sadece panel üzerinden restore edilebilir.

En kritik fark: bağımsızlık ve restore tutarlılığı

Yedekleme stratejisi belirlerken tek soru şudur: “Yedeklediğim şey, restore ettiğimde gerçek sayfayı ayağa kaldırır mı?” Bunun için yedeklerin birbirinden bağımsız olması önemlidir.

Aşağıdaki tabloda iki yaklaşımın güçlü-zayıf yönleri özetlenmiştir.

Net kural: Sadece tek bir kaynağa güvenmek yerine iki yedek katmanı kurmak daha sağlamdır. UpdraftPlus’u “uygulama katmanı”, sunucu yedeğini “altyapı katmanı” gibi düşünün.

Hangisini seçmelisiniz? Senaryolara göre net karar

Tek bir doğru yok; koşullara göre en risksiz kombinasyon değişir.

Senaryo 1: Managed WordPress değil, standart WordPress/VPS kullanıyorsunuz

Bu senaryoda en iyi pratik iki katmanlıdır: - UpdraftPlus: DB + wp-content için düzenli yedek - Sunucu yedeği: en azından günlük veya daha sık snapshot/backup

Buradaki mantık şudur: UpdraftPlus yedeğini alırken yanlış eklenti ayarı, eklenti çakışması veya yanlış dosya dahil etme gibi hatalar olabilir. Sunucu yedeği ise alternatif bir geri dönüş kaynağı sağlar.

Senaryo 2: Site hacklendi, defacement oldu veya zararlı kod eklendi

Hack sonrası davranış kritik hale gelir. Şu yaklaşım net çalışır: 1. Sunucu yedeğinden (varsa snapshot) restore dene. 2. UpdraftPlus yedeğini de alternatif olarak hazır tut. 3. Restore sonrası mutlaka dosya hash/FTP karşılaştırması veya en azından tema/eklenti dosyalarını doğrula.

Burada hedef şudur: Eğer saldırı WordPress admin paneli üzerinden gerçekleştiyse, saldırı sonrası UpdraftPlus da bozuk durumu içerebilir. Aynı zaman penceresinden alınmış sunucu snapshot’u bazı durumlarda daha temiz çıkar.

Senaryo 3: “Restore edip çalıştığını” hemen görmek istiyorsunuz

Restore test senaryosunda en pratik yaklaşım genelde şudur: - UpdraftPlus’ı devreye alıp “tam WordPress restore” akışını hızlandırın. - Sunucu yedeğini ise “büyük kurtarma” planı olarak düşünün.

Örneğin 15 dakikalık restore hedefiniz varsa UpdraftPlus çoğu durumda panel içinde daha hızlı ilerler. Ancak sağlayıcınız sunucu restore’u için otomasyon sunmuyorsa süre uzayabilir.

İdeal kurulum: iki katmanlı yedekleme (UpdraftPlus + sunucu)

Aşağıdaki madde listesi, iki yaklaşımı birlikte kullanırken operasyonel hataları azaltır.

1) UpdraftPlus’ta yedek zamanlaması ve saklama (retention)

Net hedef belirleyin: - Günlük yedek: son 7 gün - Haftalık yedek: son 4-8 hafta - Aylık yedek: son 6-12 ay

Ayrıca dosya boyutu büyüyorsa “tam site” yerine wp-content ağırlığını koruyan ayarlar seçmek planlama açısından kolaylık sağlar.

2) Harici hedefe gönderim

UpdraftPlus’ta yedeği aynı sunucuda tutmak, fiziksel/altyapı probleminde avantajı azaltır. Harici hedef seçimi net bir fark yaratır: - Aynı sunucu bozulursa iç yedek de etkilenir - Harici depolama (S3 uyumlu bulut, Google Drive vb.) bağımsızlık sağlar

3) Sunucu yedeğinin “geri dönüşü” test ediliyor mu?

Sunucu yedeği tanımlı olsa bile restore erişimi kritik sorudur. Şunları kontrol edin: - Yedekten restore panel üzerinden mi yapılıyor, yoksa destek bileti mi gerekiyor? - Restore için zaman/IO limiti var mı? - Restore sonrası DB’nin aynı sürüm/parametrelerle çalıştığı garanti mi?

4) Restore doğrulama adımı (restore doğrulama şart)

Yedek “alındı” demek tek başına yetmez. En net test: - Yedeği farklı bir staging ortamına restore et (mümkünse aynı sunucuda geçici dizin/alt domain) - Sonra şu kontrolleri çalıştır: - Ana sayfa açılıyor mu? - En az 1 form/checkout akışı veya kritik sayfa davranışı çalışıyor mu? - Eklenti sayfası ve medya yükleme bağlantıları doğru mu? - Yönetim paneli girişleri çalışıyor mu?

Net bir metrik belirleyin: Örneğin “restore + doğrulama toplam 30 dakika içinde tamamlanmalı”.

Yedekleme sırasında sık yapılan hatalar ve net düzeltmeler

Hata 1: Sadece eklenti yedeği, sunucu yedeği yok

Düzeltme: - Sağlayıcınızın sunduğu snapshot/kontrol paneli yedeğini etkinleştirin. - UpdraftPlus’ta harici depoya aktarımı açın.

Hata 2: Yedekler var ama restore yok

Düzeltme: - Ayda en az 1 kez restore test yapın. - Restore süresini ve olası sorunları bir kontrol listesine kaydedin.

Hata 3: Yedek sıklığı yüksek ama saklama süresi yok

Düzeltme: - “Sıklık” kadar “saklama” da belirleyicidir. Sadece son 1 gün yedek tutmak, hatalı bir güncelleme senaryosunda sizi geride bırakır.

Hata 4: Eklentiler/tema güncellemesi sonrası yedek geri dönüş sağlamıyor

Düzeltme: - UpdraftPlus yedeğini aldıktan sonra staging restore doğrulaması yapın. - Büyük güncellemelerden önce (tema/eklenti çekirdeği) yedek penceresini manuel tetikleyin.

Net kontrol listesi: seçim yapmadan önce 10 soruluk karar paketi

Sunucu sağlayıcınızdan ve kendi kurulumunuzdan şu sorulara yanıt alın:

1. Sunucu yedeği DB’yi içeriyor mu, yoksa sadece dosyalar mı?
2. Sunucu yedeği snapshot mı yoksa kopyalama mı?
3. Yedekten restore panel ile mi, yoksa destek talebiyle mi yapılıyor?
4. Restore için bekleme süresi ve minimum/maksimum restore penceresi nedir?
5. Yedeğe erişim için ayrı bir arayüz veya API var mı?
6. UpdraftPlus yedeklerini aynı sunucuda mı tutuyoruz, harici hedef var mı?
7. UpdraftPlus saklama (retention) süresi net olarak tanımlı mı?
8. Planlı yedekleme job’ları çalışıyor mu (loglardan kontrol)?
9. Ayda kaç kez restore doğrulama yapıyorsunuz?
10. Son güncellemeden sonra “kritik sayfalar” restore ile açılıyor mu?

Sonuç: Tek kaynak değil, doğrulanmış iki katman

En güvenli ve pratik yaklaşım UpdraftPlus + sunucu yedeğini birlikte kurmaktır. UpdraftPlus, WordPress içeriğini düzenli ve yönetilebilir biçimde yedekler; sunucu yedeği ise eklentiye bağımlılığı azaltan altyapı geri dönüş planı sunar. Aksiyon önerisi olarak bugün şu adımı atın: Önce UpdraftPlus’ta yedek planını ve harici hedefi netleştirin, ardından sağlayıcınızdan sunucu yedeğinin DB dahil olup olmadığını sorun ve ayda en az 1 kez restore doğrulaması uygulayın. Böylece yedek alındı değil, yedek gerçekten işe yarıyor olur.