Yalnızca dünkü WordPress yedeğini tutmak, ele geçirilen hesap veya yavaş ilerleyen veritabanı bozulması iki hafta sonra fark edilene kadar verimli görünür. Bütün paketleri süresiz saklamak ise başka bir soruna yol açar: Depolama dolar, yeni işler başarısız olur ve son sağlam kopyayı bulmak zorlaşır.
Saklama politikası işe yarayan kurtarma geçmişini korurken silme işlemlerini öngörülebilir hâle getirir. Sorunların ne kadar süre fark edilmeyebileceği, yedek sıklığı, paketlerin birbirine bağımlılığı ve sonraki iş için gereken alan birlikte değerlendirilmelidir. Gizlilik, sözleşme ve yasal silme yükümlülükleri de politikanın parçasıdır.
Bu konu ne anlama gelir?
Saklama politikası, hangi kurtarma noktalarının nerede tutulacağını ve ne zaman silinebileceğini belirler. Yedekleme sıklığı yeni noktalar üretir; saklama kuralı geçmişin ne kadarının korunacağına karar verir. Yaygın yaklaşım, yakın tarihte çok sayıda kopya tutup haftalık ve aylık eski kopyaları daha seyrek saklamaktır.
Saklama süresi ile değiştirilemezlik aynı şey değildir. Bir paket bir yıl saklanacak şekilde ayarlanmış olsa da ele geçirilen yönetici tarafından silinebilir. Buna karşılık yedi gün kilitli bir dosya, politika aylık geçmiş istese bile sekizinci gün silinebilir. İki süre ayrı tanımlanmalıdır.
Gerçekçi bir WordPress örneği
Bir mağaza her gece tam yedek alıyor ve yalnızca son yedi kopyayı tutuyor. On iki gün önce başlayan katalog bozulması fark edildiğinde bütün temiz noktalar silinmiş oluyor. Yeni politikada on dört günlük, sekiz haftalık ve on iki aylık kurtarma noktası saklanıyor; sonraki tam paket için de alan ayrılıyor.
Ekip, kısa süre önce başarıyla geri yüklenen bir paketi doğrulanmış temel kopya olarak işaretleyip politika değişikliklerinden koruyor. Ardından iki yönü de test ediyor: Süresi dolan ve korunmayan dosya silinirken haftalık ve aylık noktalar yerinde kalıyor. Paket boyutu veya sorunu fark etme süresi değiştiğinde kural yeniden değerlendiriliyor.
Neden önemlidir ve ne zaman kullanılır?
Düzenli çalışan her yedek planının saklama kuralı olmalıdır. Güvenlik olayı, işlem hacmindeki değişim, yeni gizlilik yükümlülüğü, artımlı yedeklere geçiş veya medya alanındaki belirgin büyüme sonrasında politikayı gözden geçirin. En az bir kurtarma noktası, sorunun fark edilmesi için öngörülen en uzun süreden eski olmalıdır.
Silme işlemleri de yeni yedekler kadar izlenebilir olmalıdır. Depolama sağlayıcısı farklı lifecycle kuralı uyguluyorsa, temizlik hataları görünmüyorsa veya elle silme bütün sürümleri kaldırabiliyorsa belgelenmiş politika tek başına işe yaramaz. Kapasiteyi, yasal bekletmeleri ve istisnaları yönetecek sorumluları belirleyin.
Yeni başlayanlar için anlaşılır yol
- Bozulma, saldırı veya editoryal hatanın ne kadar süre fark edilmeden kalabileceğini tahmin edin.
- Yedek türlerini, sıklığı, güncel boyutu, büyüme beklentisini ve tam-artımlı bağımlılıklarını listeleyin.
- Bu süreyi kapsayacak sık yakın tarihli noktalar ve seyrek geçmiş kopyalar seçin.
- En az bir sonraki yedek işi ve geçici verileri için depolama alanı ayırın.
- Son doğrulanmış kurtarma noktasını koruyun; bir katmandaki son kullanılabilir kopya silinmeden onay isteyin.
- Yakın ve eski tarihli birer paketi geri yükleyin; ardından normal süresi dolan bir kopyanın gerçekten silindiğini doğrulayın.
İleri teknik yol
Gerçek paket boyutları ve sağlayıcı maliyetleriyle saklama politikasının baştan sona nasıl işleyeceğini modelleyin. Artımlı yedeklerde, sunulan her kurtarma noktasını oluşturmak için gereken temel paketleri koruyun; tam temel yedeğin silinmesi sonraki birçok paketi kullanılamaz hâle getirebilir. Silme kuyruklarını, çöp kutusu sürelerini, bölgesel kopyaları, object lock bitişini, yasal bekletmeleri ve kullanımdan kaldırılan anahtarların imhasını hesaba katın.
Yedek verilerini, ayrı yasal saklama yükümlülüğü bulunan kayıtlardan ayırın. Gizlilik talepleri ve sözleşmedeki silme süreleri, arşivlerdeki kişisel verileri de kapsayabilir. Her silmeyi gerçekte hangi sistemin – WordPress, yedek uygulaması veya depolama sağlayıcısı – yaptığını belgeleyin.
Riskler, sık hatalar, yedek ve geri dönüş
Otomatik temizlik son doğrulanmış noktayı silecekse, bağımlılık zincirleri bilinmiyorsa veya sağlayıcının lifecycle kuralı belgelenen politikayla uyuşmuyorsa işlemi durdurun. Yeni yedeğin tamamlanacağı kanıtlanmadan sağlam geçmişi silerek dolu hedefi boşaltmaya çalışmayın.
Yalnız dosya adına güvenmek, senkronizasyon geçmişini yedek saklama politikası sanmak, geniş elle silme yetkileri vermek ve anahtarı kayıp şifreli paketleri tutmak da önemli risklerdir. Yeni kural beklenmedik davranırsa mevcut kopyaları koruyun, silme adımını kapatın ve kritik olmayan verilerle yeniden sınayın.
AIOWS nasıl yardımcı olur?
AIOWS Yedekleme Yöneticisi
AIOWS Yedekleme Yöneticisi, desteklediği saklama seçeneklerini ilgili WordPress yedek ayarlarıyla birlikte gösterir. Bu seçenekleri belirlemeden önce sitenin ihtiyaç duyduğu geçmişi, mevcut kapasiteyi ve tam ya da artımlı paketler arasındaki bağımlılıkları netleştirin.
Saklama süresini kısaltmadan önce son doğrulanmış kurtarma noktasını koruyun. Yapılandırılan kuralın hangi sürümleri tutacağını inceleyin ve sonraki iş için yeterli alan bırakın. Saklama kuralı tam bir dönem uygulandıktan sonra elde kalan paketleri planlanan günlük, haftalık veya aylık katmanlarla karşılaştırın; beklenmedik silme ya da birikmeyi araştırın.
AIOWS depolama sağlayıcısının lifecycle kurallarını geçersiz kılamaz, kurum adına yasal politika belirleyemez ve değiştirilemezlik garantisi veremez. Kişisel verilerin ne kadar saklanabileceği de modül dışında değerlendirilmelidir. Eski paketin kullanılabilirliği ancak geri yüklemeyle kanıtlanır. Sağlayıcı ayarları, hukuki inceleme, kapasite tahmini ve geri yükleme testleri ayrı sorumluluklardır; Yedekleme Yöneticisi desteklenen WordPress ayarını görünür kılar.
AIOWS Yedekleme Yöneticisi özelliğini inceleyinAIOWS planlarını karşılaştırın
İlgili AIOWS yazıları
- WordPress Sitesi Ne Sıklıkla Yedeklenmeli?
- Site Dışı WordPress Yedeği Nasıl Güvenle Oluşturulur?
- WordPress Felaket Kurtarma Planı: Tam Kontrol Listesi
Sonuç ve önerilen yol
Yakın tarihli çok sayıda kurtarma noktası, daha seyrek haftalık ve aylık eski kopyalar ve en az bir doğrulanmış temel yedek tutun. Bütün bağımlılıkları koruyun ve sonraki iş için alan ayırın. Otomasyona güvenmeden önce hangi kopyaların korunduğunu ve hangilerinin silindiğini test edin.
