WordPress yedekleme, arşiv dosyasını bir klasöre bırakmak değildir. Güvenilir yedek; gerekli dosyaları ve veritabanını kapsar, üretimden bağımsız yerde saklanır, bütünlüğü kontrol edilir ve gerçek geri yükleme senaryosuyla denenir. Bunlardan biri yoksa “yedek var” ile “siteyi geri döndürebilirim” aynı değildir.
Virüs olayında temiz noktaya dönmek için müdahale rehberini okuyun; burada süreklilik ve restore tasarımını ele alıyoruz.
Dosya ve veritabanını birlikte planlayın
Dosyada çekirdek, wp-content, tema, eklenti, uploads, mu-plugins ve özel yapılandırmaların kapsamını belirleyin. Veritabanında yazı, sayfa, kullanıcı, ayar, sipariş, form ve eklenti tabloları bulunabilir. Yalnız wp-content veya yalnız SQL, işletme sitesini bütünüyle geri getirmeyebilir.
PHP, cron, web sunucusu, DNS, SSL, CDN ve environment kayıtlarını da geri dönüş planına ekleyin. Gizli bilgileri yedekliyorsanız şifreleme ve erişim politikanızı ayrıca belirleyin.
Kopya rollerini ayırın
- Yakın tarihli üretim snapshot’ı hızlı rollback içindir.
- Bağımsız arşiv olay ve silinme riskine karşıdır.
- Staging restore okunabilirlik ve çalışırlığı test eder.
Aynı sunucudaki üç klasör üç bağımsız kopya değildir. Konum, tarih, kapsam ve kimlikleri kaydedin; bir kopyanın başarısı diğerini kanıtlamaz.
Sıklığı riske göre seçin
Blog, sipariş veya form alan sitenin backup ihtiyacı sabit aylık arşivden farklıdır. Sıklığı kabul edilebilir veri kaybı ve geri yükleme süresi belirlemelidir. Güncelleme, tema değişikliği ve veri aktarımı öncesinde ayrıca dönüş noktası oluşturun. Eski kopyayı otomatik silmeden önce olay fark edilme süresini karşılayıp karşılamadığınızı kontrol edin.
Bütünlük ve restore testi
WordPress hardening dokümanı şifreleme, bağımsız hash ve salt okunur medya ile güveni artırmayı açıklar. Hash eşleşmesi kopyanın değişmediğini gösterir; kopyanın temiz veya çalışır olduğunu kanıtlamaz. Arşivi açın, SQL’i okuyun, beklenen boyut ve dosya kapsamını doğrulayın; ardından staging’e geri yükleyin.
Restore kabul kriterleri
- Hedef ortamı üretimden ayırın.
- Dosya ve veritabanını snapshot kimliğiyle yükleyin.
- Alan adı, medya, login, form, ödeme ve kritik içerikleri test edin.
- HTTP, PHP logu, canonical, sitemap ve görselleri kontrol edin.
- Restore süresini, eksik veriyi ve manuel adımı kaydedin.
Test ortamı üretimden farklıysa sonucu sınırlı kabul edin. Yedek hesabına erişimi sınırlayın; eski backup’ı bağımsız restore kanıtı ve onay olmadan silmeyin.
Saklama ve erişim politikasını yazın
Kaç günlük restore noktası gerektiğini veri kaybı toleransı ve olayın geç fark edilme süresiyle belirleyin. Backup hesabına erişen kişileri sınırlayın; yedek arşivindeki kişisel veri ve sipariş bilgisi için şifreleme ve saklama politikasını değerlendirin.
Restore testi yalnız dosyaların açılması olmamalı; site URL’si, medya, kullanıcı girişi, form, e-posta, cron ve varsa ödeme akışı doğrulanmalıdır. Eksik bir adım varsa bunu açıkça “restore sonrasında manuel işlem” olarak yazın. Farklı snapshot’ları aynı isimle karıştırmayın; kaynak ve staging kimliklerini ayrı tutun.
Eski yedekleri otomatik silmek depolama maliyetini azaltabilir; ancak bağımsız restore kanıtı ve onay olmadan silme, güvenlik olayında geri dönüş seçeneklerini azaltır.
Örnek restore testi: form alan işletme sitesi
Varsayımsal bir sitede 2026-10-01 tarihli dosya ve veritabanı snapshot’ı seçilir ve üretim DNS’inden ayrılmış staging’e yüklenir. Beklenen kanıt; kaynak snapshot kimlikleri, arşiv hash kaydı, dosya/veritabanı kapsamı, restore başlangıç-bitiş zamanı ve eksik manuel adımlardır. Testte bir yazı, bir medya dosyası, bir yönetici hesabı, form başarı/hata yanıtı ve e-posta teslimi kontrol edilir.
Restore sonrası medya yoksa yalnız veritabanı veya uploads kapsamı eksik olabilir; bütün siteyi başarısız ilan etmeden kapsamı düzeltip yeni test yapın. Form çalışıyor fakat cron veya e-posta yoksa staging ile üretim arasındaki yapılandırma farkını kaydedin. Arşiv açılamıyor, hash eşleşmiyor veya SQL eksikse bu kopyayı güvenilir restore noktası saymayın. Bağımsız bir kopya doğrulanmadan eski yedekleri silmeyin; sürekli bakım ve iyileştirme kaydına snapshot kimliğini ekleyin.
Restore raporunda yalnız “başarılı” yazmayın. Eksik medya, manuel DNS, cron, e-posta veya lisans adımı varsa bunları açıkça listeleyin. Bir sonraki testin amacı bu eksiklerden hangisini kapatmak olduğunu göstermeli; aksi halde her test aynı belirsizliği tekrar eder.
Test ortamını yalnız alan adıyla değil dış etkileriyle de üretimden ayırın: arama motoru erişimini sınırlandırın, müşteri e-postaları ve webhook gönderimlerini test alıcılarına yönlendirin, ödeme entegrasyonunu deneme modunda kullanın. Geri yüklenen kişisel veriye erişimi kısıtlayın. Test sırasında gerçek müşterilere bildirim veya mükerrer işlem gitmediğini doğrulayın.
