WordPress yedekleme: gerçekten geri yüklenen yedekler

Sıradan bir WordPress yedekleme düzeni, tam ihtiyaç duyduğunuz anda çöker. Bir eklenti wp-content içine zip dosyası yazar, üstelik site ile aynı hosting hesabında. Saldırgan, fidye yazılımı ya da hesabın askıya alınması siteyi götürdüğünde, o kopya da onunla birlikte gider.

Geri yükleyemediğiniz yedeğin değeri yoktur. Bu rehber nelerin yedeğe dahil edilmesi gerektiğini, kopyaların nerede tutulacağını, ne sıklıkla alınacağını, geri yüklemenin nasıl test edileceğini ve bir saldırıdan sonra temiz geri yükleme noktasının nasıl seçileceğini anlatır.

WordPress yedeği neleri içermeli: dosyalar ve veritabanı

Bir WordPress sitesinin iki yarısı vardır ve ikisine de ihtiyacınız var. Veritabanı yazıları, sayfaları, kullanıcıları ve parola özetlerini (hash), ayarları, WooCommerce siparişlerini ve form kayıtlarını tutar. Girişleri veritabanında saklayan bir iletişim formu eklentisini düşünün. Yalnızca dosyaları içeren yedek tüm başvuruları kaybeder; yalnızca veritabanı içeren yedek ise kayıtları geri getirir ama onları okuyacak eklenti yoktur.

Gerekli dosyalar wp-content (yüklemeler, eklentiler, temalar), wp-config.php ile .htaccess ya da sunucu yapılandırmanızdır. WordPress çekirdeği yeniden indirilebilir, ancak yalnızca hangi sürümü kullandığınızı biliyorsanız.

WordPress kök dizininden, WP-CLI ile:

# Veritabanı dışa aktarımı, web kök dizininin dışına yazılır
mkdir -p ~/backups
wp db export ~/backups/db-$(date +%F).sql

# Dosyalar: wp-content, wp-config.php ve .htaccess (önbellekleri ve eski yedek klasörlerini atlayın)
tar --exclude='wp-content/cache' \
    --exclude='wp-content/backups' \
    -czf ~/backups/files-$(date +%F).tar.gz \
    wp-content wp-config.php .htaccess

# Sürümleri kaydedin; çekirdek, eklentiler ve temalar resmi kaynaklardan yeniden kurulabilsin
wp core version > ~/backups/versions-$(date +%F).txt
wp plugin list --fields=name,version,status >> ~/backups/versions-$(date +%F).txt
wp theme list --fields=name,version,status >> ~/backups/versions-$(date +%F).txt

wp-content/backups yolunu yedekleme eklentinizin kullandığı klasörle değiştirin. nginx'te .htaccess yoktur; komuttan çıkarın, yerine sunucu yapılandırmanızı yedekleyin. Yedeğin içindeki yedekler her arşivi şişirir. WP-CLI db komutları WordPress.org'da belgelenmiştir.

3-2-1 kuralı ve hosting hesabındaki yedeğin neden sayılmadığı

Kural şudur: verinizin üç kopyası, iki farklı depolama türünde ve bir kopya harici bir konumda. Canlı siteniz bir kopya sayılır. Aynı hosting hesabındaki yedek ikinci kopyadır, ancak siteyle aynı oturum açma bilgisini, aynı sunucuyu ve aynı sağlayıcıyı paylaşır.

Siteye yazabilen biri çoğu zaman bu kopyayı da silebilir. Web kök dizinini şifreleyen fidye yazılımı, yanındaki zip dosyasını da şifreler. Askıya alınan bir hesap ya da bir hosting arızası ikisini birden alıp götürür. Hosting sağlayıcısının anlık görüntüleri (snapshot) faydalıdır ve hızlı geri yüklenir, ama yine de kontrol etmediğiniz tek bir kopyadır.

Asıl önemli olan üçüncü kopyadır. Farklı bir sağlayıcıdaki depolamaya, ayrı kimlik bilgileriyle gitmeli; bu bilgiler web sunucusunda silmeye izin verecek biçimde tutulmamalıdır. İki ayar büyük fark yaratır:

• Sürümleme veya değiştirilemezlik. Birçok nesne depolama hizmeti sürümleme, nesne kilidi (object lock) ya da sağlayıcı tarafında saklama kilidi sunar. Sürümleme eski kopyaları tutar, ancak silme yetkisi olan biri yine de bunları kaldırabilir. En katı (compliance) modda bir kilit ise süre dolana kadar yedeğin silinmesini ya da üzerine yazılmasını, sizin tarafınızdan bile olsa, engeller.
• Yedekleme görevi için yalnızca yazma yetkili kimlik bilgileri. Sunucudaki anahtar yalnızca yükleyebiliyorsa ve sürümleme ya da kilit eski kopyaları koruyorsa, anahtarı çalan bir saldırgan geçmişinizi silemez veya üzerine yazamaz.

Ne sıklıkla yedek alınmalı, kopyalar ne kadar saklanmalı

Sıklığı verinizin ne kadar hızlı değiştiğine göre belirleyin. Ayda bir güncellenen bir tanıtım sitesi için haftalık yedek yeterlidir. Her gün sipariş alan bir mağazanın veritabanını en az günlük, çoğu zaman daha sık yedeklemesi gerekir. Dosyalar genellikle veritabanından daha seyrek değiştiği için ayrı bir takvimle çalıştırılabilir.

Saklama süresi bir dengedir. Ele geçirilmeler çoğu zaman başladıktan haftalar sonra fark edilir. Yalnızca yedi günlük kopya tutarsanız, hepsi çoktan arka kapıyı içeriyor olabilir. Öte yandan eski yedekler, kullanıcıların silmenizi istediği hesaplar dahil, kişisel verileri hayatta tutar.

Sabit bir saklama süresi ve döngü belirleyin; örneğin birkaç hafta boyunca günlük kopyalar, ayrıca sınırlı bir süre için aylık kopyalar. Bu süreyi yazılı hale getirin. Yazılı takvim silme taleplerinde de işinize yarar: kopyaların süresi dolunca veri yedeklerden de kaybolur, o zamana kadar da geri yüklenmediğinden ve kullanılmadığından emin olursunuz. Her talep için arşivleri yeniden yazmak nadiren pratiktir; yedeklerle ilgili denetim otoritenizin rehberliğine bakın.

Yedekler de kişisel veridir: şifreleme, erişim, sözleşmeler

WordPress yedeği kullanıcı hesaplarını, parola özetlerini, müşteri ve sipariş verilerini ve form kayıtlarını içerir. Onu kaybetmek, canlı veritabanını kaybetmek kadar ciddidir.

• Şifreleyin: hem aktarım sırasında hem de depolamada. Şifreleme, GDPR (AB Genel Veri Koruma Tüzüğü) md. 32(1)(a) kapsamında sayılan önlemlerden biridir. Anahtarı, koruduğu depolamadan farklı bir yerde saklayın.
• Erişimi sınırlayın. Yedekleri yalnızca siteleri geri yükleyen kişiler indirebilmelidir. Depolamadaki eski paylaşım bağlantılarını ve süresi dolmuş kullanıcı hesaplarını kaldırın.
• Sözleşme yapın. Yedek depolama sağlayıcısı ya da kopyaları tutan bir ajans md. 28 anlamında veri işleyendir ve veri işleme sözleşmesi gerektirir.

Kaybolan ya da herkese açık biçimde erişilebilen şifresiz bir yedek, başlı başına bir kişisel veri ihlali olabilir. Böyle bir durumda 72 saatlik bildirim rehberine bakın.

İhtiyaç duymadan önce geri yükleme testi yapın

Geri yüklemeyi bir hazırlık (staging) sitesine ya da yerel bir kopyaya yapın; canlı sitenin üzerine asla. Kullanışlı yerel kopyayı değil, harici kopyayı kullanın; çünkü gerçek bir olaydan sonra elinizde olacak olan odur.

# Staging ortamında boş bir web kök dizininde; WP_VERSION, sürüm dosyanızdan gelir
wp core download --version="$WP_VERSION" --skip-content
tar -xzf files-2026-10-23.tar.gz
# wp-config.php dosyasını düzenleyin: staging veritabanı bilgileri, ardından:
wp db import db-2026-10-23.sql
wp search-replace 'https://www.example.com' 'https://staging.example.com' --skip-columns=guid
wp option update blog_public 0

blog_public 0 arama motorlarından yalnızca uzak durmalarını rica eder. Staging'i ayrıca HTTP kimlik doğrulamasının arkasına alın. Gerçek müşterilere e-posta göndermesini ya da ödeme webhook'larını çağırmasını engelleyin; test süresince define( 'DISABLE_WP_CRON', true ); kullanmayı da düşünebilirsiniz.

Ardından şunları kontrol edin:

• Yönetici girişi çalışıyor
• Bir form gönderimi iletiliyor
• En son sipariş veya yazı mevcut
• Görseller ve indirmeler yükleniyor
• Eklenti listesi ve sürümler kaydınızla uyuşuyor
• Başlangıçtan çalışan siteye kadar geçen toplam süre not edildi

Bu süre gerçek kurtarma sürenizdir ve çoğu zaman sanıldığından uzundur. Tarihi, kullandığınız yedeği, sonucu ve karşılaştığınız sorunları kaydedin. Hiç geri yüklenmemiş bir yedek size hiçbir şey kanıtlamaz; md. 32(1)(c) ve (d) ile md. 5(2)'deki hesap verebilirlik yükümlülüğünü nasıl yerine getirdiğinizi soran birine de.

Saldırıdan sonra geri yükleme: son temiz noktayı bulun

En yeni yedeği körlemesine geri yüklemeyin. Büyük olasılıkla arka kapıyı içerir. En eski yedek temiz olabilir ama haftalarca siparişten yoksundur. Herhangi bir şeyi değiştirmeden önce, ileride inceleyebilmek için enfekte durumun bir kopyasını alın.

Sonra ele geçirmenin ne zaman başladığını tahmin edin. Sunucu ve erişim günlüklerine, dosya değişiklik tarihlerine, tanımadığınız yönetici kullanıcılara ve eski bir yedekten farklı olan dosyalara bakın. Ardından bu tarihten önceki bir yedeği seçin. Burada dosya bütünlüğü referansı (baseline) yardımcı olur. Security Audit & Compliance eklentisi bunu kaydeder, değişen dosyaları ve ele geçirme göstergelerini işaretler; böylece değişimin zamanı daralır. Yedek almaz ve geri yüklemez.

Tam geri yüklemeden daha temiz bir yaklaşım:

1. Çekirdeği, eklentileri ve temaları bilinen sürümlerle resmi kaynaklardan yeniden kurun.
2. Temiz noktadan yalnızca yüklemeleri ve veritabanını alın. Yüklemelerde PHP dosyası olup olmadığına bakın (yüklemelerde web shell nasıl bulunur).
3. Veritabanında sızdırılmış yönetici hesaplarını (wp user list --role=administrator) ve spam içeriği kontrol edin.
4. O noktadan sonra oluşan siparişleri ve verileri yeniden girin veya taşıyın.

Geri yükleme açığı kapatmaz. Site yeniden yayına girmeden önce savunmasız bileşeni güncelleyin ya da kaldırın; tüm parolaları, anahtarları ve salt değerlerini değiştirin. Aksi halde aynı yoldan yeniden hacklenirsiniz. Tüm prosedür kötü amaçlı yazılım temizleme planımızda var; çekirdeğin temiz olduğunu ise çekirdek sağlama toplamlarını doğrulayarak teyit edebilirsiniz.

GDPR ve NIS2 yedeklerinizden ne bekler

GDPR md. 5(1)(f), bütünlük ve gizlilik dahil uygun güvenlik gerektirir. Md. 32(1)(c), bir olaydan sonra kişisel verilere erişimin ve verilerin kullanılabilirliğinin zamanında yeniden sağlanabilmesini; (d) bendi ise önlemlerin düzenli olarak test edilmesini ister. Geri yükleme imkânı olmadan müşteri verisini kaybetmek, bir erişilebilirlik ihlali sayılabilir.

Ulusal mevzuat kapsamındaki kuruluşlar için NIS2 Direktifi md. 21(2)(c), yedek yönetimi ve felaket kurtarma dahil iş sürekliliğini sayar. NIS2 size uygulanmasa bile, NIS2 kapsamındaki müşterileriniz tedarikçi ya da ajans olarak sizden kanıt isteyebilir. Daha geniş tablo için GDPR md. 32 özetimize bakın.

Tek sayfalık bir yedekleme kaydı tutun: neyin yedeklendiği, nerede, ne sıklıkla, saklama süresi, şifreleme, kimlerin erişimi olduğu ve son geri yükleme testinin tarihi ile sonucu. Bir sonraki adımınız, bu hafta harici kopyayı kullanarak ilk geri yükleme testini takvime almak.

SSS

Hosting sağlayıcımın günlük yedeği yeterli mi?

Genellikle tek başına değil. Aynı sağlayıcıda tutulan tek bir kopyadır ve çoğunlukla kısa süre saklanır. Ne kadar süre saklandığını kontrol edin ve kendi kontrolünüzde harici bir kopya ekleyin.

WordPress çekirdeğini de yedeklemeli miyim?

Çekirdek, eklenti ve tema sürümlerini kaydediyorsanız şart değil. WordPress.org'dan yeniden kurmak size bilinen temiz çekirdek dosyalarını da verir.

Verisi yedeklerde duran birinin silme talebini nasıl ele alırım?

Veriyi canlı siteden silin, yedekler için belgelenmiş saklama sürenize dayanın. Bir geri yükleme yapmanız gerekirse, kişinin verisinin canlı siteye geri konmadığından emin olun.

Geri yüklemeyi ne sıklıkla test etmeliyim?

Düzenli olarak ve hosting, site ya da yedekleme aracınızda büyük bir değişiklikten sonra her zaman. Gerçekten uyabileceğiniz bir aralık seçin ve her testi kaydedin.

Bu makale genel bilgilendirme amaçlıdır, hukuki danışmanlık değildir.