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

WordPress sitelerinde “yedek var mı?” sorusunun tek başına bir anlamı yoktur. Asıl soru, yedeğin hangi bileşenleri içerdiği (dosyalar + veritabanı), ne kadar sık alındığı, geri yüklemenin ne kadar hızlı ve doğrulanabilir olduğu ve olası bir hatada nasıl kanıt üretildiğidir. Bu yazıda UpdraftPlus (WordPress eklentisi) ile sunucu yedeğini (VPS/VDS altyapı snapshot/backup) karşılaştırıp, hangi senaryoda hangisinin daha net sonuç verdiğini açıklıyorum.

UpdraftPlus ve sunucu yedeği aynı şeyi mi yapar?

UpdraftPlus, WordPress ekosisteminin içinde çalışır. Temel amacı, WordPress dosyalarını ve veritabanını belirli aralıklarla yedekleyip harici bir depoya göndermektir (ör. S3 benzeri nesne depolama, Google Drive, benzeri).

Sunucu yedeği ise hosting sağlayıcısının altyapısında oluşur. Tipik olarak iki biçimde karşımıza çıkar: - Dosya tabanlı yedek: Hesabın dizinlerini ve veritabanını birlikte arşivleyebilir. - Snapshot / görüntüleme (snapshot): VM (VPS/VDS) seviyesinde diski andıran nokta atışı kopya.

Net fark: UpdraftPlus, WordPress’in kendi ürettiği mantıksal içeriği hedefler; sunucu yedeği ise çoğu zaman WordPress farkındalığı olmadan sistem seviyesinde çalışır. Bu nedenle geri yükleme kalitesi ve geri yükleme kontrol adımları farklılık gösterir.

Hangi bileşenler yedeklenmeli?

WordPress için hedef, şu iki bileşeni kapsamaktır: 1. WordPress dosyaları: wp-content (tema/eklenti/yüklemeler), wp-config.php, özel ayarlar. 2. Veritabanı (MySQL/MariaDB): site ayarları, gönderi/ sayfa verileri, kullanıcılar, WooCommerce siparişleri (varsa).

Eğer bu iki bileşenden biri eksikse “yedek aldık” cümlesi pratikte başarısız olur.

Karşılaştırma: UpdraftPlus mı sunucu yedeği mi?

Aşağıdaki tablo, karar verirken ihtiyacınız olan kriterleri doğrudan karşılaştırır.

Kriter	UpdraftPlus (WordPress eklentisi)	Sunucu yedeği (VPS/VDS/hosting altyapısı)
Kapsam odağı	WordPress dosyaları + veritabanı odaklı	Sağlayıcıya göre değişir: dosya+DB veya snapshot
Yedekleme sıklığı	Dakikadan günlüğe kadar ayarlanabilir	Paket/altyapıya bağlı; genelde saatlik/günlük
Geri yükleme hızı	Doğru ayarla hızlı olabilir; dosya/DB boyutuna bağlı	Snapshot hızlı olabilir; ancak işletim düzeyi/uyumluluk etken olur
Geri yükleme doğrulama	Eklenti üzerinden test akışı kurulabilir	Snapshot sonrası WordPress’te erişim ve DB tutarlılığı kontrol edilmelidir
Dosya izin/konfig etkisi	WordPress seviyesinde tekrar düzenlenir	VM seviyesinde tüm sistem kopyalanır; sürüm/konfig uyuşmazlığı riski
Güvenlik (yedek içeriği)	Depoyu siz yönetirsiniz; şifreleme/anahtar planı şart	Sağlayıcı yönetir; erişim ve şifreleme politikaları değişir
Arıza senaryosu	WordPress erişimi varsa eklenti çalışır	VM/hosting seviyesinde bağımsız çalışır; ama WordPress çökmesiyle aynı anlamda değil
Operasyon kontrolü	Eklenti ayarlarıyla net kontrol	Sağlayıcı SLA ve araçlarına bağlı kontrol
“Geri dönüp çalışıyor mu?” kanıtı	Yedekten test edip doğrulama adımı kolay	Snapshot sonrası otomatik değil; manuel doğrulama şart

Net sonuç hangi yöne kayıyor?

Sadece sunucu yedeği ile yedek almak çoğu WordPress kullanıcısında “eksik kalma” riskini artırır. Çünkü sağlayıcının yedek kapsamı, yedek formatı ve geri yükleme akışı belirsiz olabilir.
Sadece UpdraftPlus da yetmeyebilir. WordPress dosya sistemi ciddi bozulduğunda (yanlış izinler, disk doluluğu, servis çökmesi) eklenti mantıksal olarak çalışamayabilir.

Bu yüzden en net yaklaşım: katmanlı plan.

En net pratik yaklaşım: 2 katmanlı yedek stratejisi

Tek bir yedek türüne güvenmek yerine iki katman kurun: 1. WordPress katmanı (UpdraftPlus): Veritabanı ve wp-content mantığını WordPress düzeyinde yakalar. 2. Sunucu katmanı (sağlayıcı yedeği / snapshot): Sunucu seviyesinde “en azından sistemi geri getirme” opsiyonu sağlar.

Katman 1: UpdraftPlus’i hangi şekilde kurmalısınız?

Aşağıdaki kurallar, “yedek aldım” hissini gerçek kurtarma senaryosuna çevirir.

1) Yedek zamanlamasını veri riskine göre belirleyin

İçerik güncellemeleri günlükse: günlük yedek minimumdur.
E-ticaret, WooCommerce siparişi ve form kayıtları aktifse: gün içinde birden fazla yedek planlayın.

Net kural: En son geri yükleme noktasında kaybetmeyi kabul edeceğiniz en büyük veri aralığını belirleyin (ör. “en fazla 24 saat”). Yedek aralığını bununla birebir eşleştirin.

2) Depolamayı sunucu dışına alın

UpdraftPlus’in yedeği, aynı sunucuda kalırsa diskin bozulmasıyla eş zamanlı kaybolur. Harici depoya gönderin.

3) Dosya ve veritabanı kapsamını kontrol edin

UpdraftPlus ayarlarında “hangi bileşenler” yedekleniyor kısmını net doğrulayın. Özellikle wp-content dışında bir şey kaçıyorsa geri yükleme eksik olur.

4) Şifreleme (en azından yedeklerin taşınması sırasında) uygulayın

“Yedek dosyası güvenli mi?” sorusunu yanıtlayın: - Yedeklerin depoda şifreli olması - Şifreleme anahtarının nasıl saklandığı - Şifreleme/anahtar erişiminin kimde olduğu

Bu adım, bir yedek sızıntısı durumunda veri korur.

Katman 2: Sunucu yedeğinde beklenen davranış nedir?

Sunucu yedeğinde hedef “WordPress bileşenlerinin tam haliyle geri gelmesi” olmalıdır. Bu yüzden sağlayıcıdan netleştirmeniz gerekenler vardır: - Yedekler dosya + veritabanını birlikte mi alır? - Geri yükleme gerçek geri yükleme mi, yoksa sadece arşivi indirip manuel geri koymanız mı gerekir? - Snapshot sonrası işletim sistemi sürüm/konfig uyuşmazlığı çıkar mı? - Yedek saklama süresi kaç gün?

Bu soruların yanıtı yoksa, sunucu yedeğine “tam kurtarma” gözüyle bakmayın.

Geri yükleme testi: En sık yapılan hata “yedek var, test yok”

Yedek stratejisindeki en büyük farkı, test oluşturur.

Testi nasıl netleştireceksiniz?

Aşağıdaki minimum kontrol setini her ay veya büyük değişiklikten sonra yapın: - Test ortamında (staging benzeri) yedeği geri yükleyin. - Ana sayfa, yönetici girişi ve en az bir kritik eklentinin çalıştığını doğrulayın. - Veritabanı tutarlılığını kontrol edin: menüler, kullanıcılar, WooCommerce siparişleri gibi. - Medya yüklemeleri (wp-content/uploads) eksik mi inceleyin.

Net hedef: Yedekten geri geldiğinizde “hata mesajı çıkmadı” değil, “site gerçek iş akışını yapıyor” olmalıdır.

Senaryolara göre net seçim rehberi

Aşağıdaki karar çerçevesi, hangi durumda hangi katmanın daha kritik olduğunu söyler.

1) WordPress paneli erişilebilir ama site bozuldu

Örnek: Eklenti çakışması, tema güncellemesi sonrası hata. - UpdraftPlus en hızlı kurtarma yoludur. - Sunucu yedeği ikinci katman olarak “tam sistem dön” seçeneği verir.

2) WordPress paneli açılmıyor (DB hatası, servis çökmesi)

Sunucu yedeği daha anlamlı olabilir; çünkü WordPress eklentisi çalışamayabilir.
Yine de kritik WordPress geri yükleme adımlarını test etmeden varsayım yapmayın.

3) Dosya sistemi bozuldu (yanlış izinler, yanlış chmod, disk doluluğu)

UpdraftPlus dosya/DB mantığıyla geri koyabilir; fakat dosya izinleri veya sistem kaynakları engel oluşturabilir.
Sunucu snapshot, sistem seviyesinde “o anı” geri alır.

Net sonuç: Bu senaryoda iki katman arasındaki rol farkı çok belirgindir; sadece birini seçmek kurtarma süresini uzatır.

4) Güvenlik olayı (malware, yetkisiz değişiklik)

Yedeğin alınmış olması yetmez; yedek tarihinin olaydan önceki bir noktayı kapsadığından emin olun.
Yedekten geri yükledikten sonra dosya bütünlüğü doğrulaması yapın.

UpdraftPlus burada önemli bir avantaj sağlayabilir: hangi tarihte hangi içerik bulunduğu daha görünür olur.

Net operasyon planı (kısa kontrol listesi)

Aşağıdaki listeyi doğrudan uygulayın: - UpdraftPlus ile yedek: dosya + veritabanı kapsayan ayarları doğrula. - Yedekleri sunucu dışına gönder (harici depo). - Yedek şifreleme/koruma planını netleştir (yedek erişimini kontrol et). - Sunucu yedeği/snapshot kapsamını sağlayıcıdan yazılı netleştir (dosya+DB mi?). - Ayda en az bir kez yedekten staging ortamında geri yükleme testi yap. - Test çıktısını kaydet: “tarih / yedek türü / geri yükleme sonucu / doğrulanan sayfalar”.

Sonuç: En doğru cevap “ya/ya” değil, “katman + test”

UpdraftPlus ile sunucu yedeği aynı ihtiyacı farklı seviyede çözer. Net ve sürdürülebilir çözüm; WordPress tarafında UpdraftPlus ile mantıksal içerik yakalamak, sunucu tarafında ise sağlayıcının yedeği/snapshot’iyle sistem seviyesinde geri dönüş imkânı kurmaktır. Son adım olarak da en az ayda bir kez yedekten geri yükleme testi yapın; böylece arızada “yedek var” değil “yedek çalışıyor” dersiniz. Bugün mevcut yedek planınızı kontrol edin: kapsam (dosya+DB), saklama, harici depoya gidiş ve en az bir doğrulanmış geri yükleme tarihi var mı?