Yedekleme stratejisi: 3-2-1, saklama ve geri dönüş testi

Yedekleme planı, yalnız bir kopya oluşturmayı değil hangi verinin hangi zamanda geri getirilebileceğini tanımlamalıdır. Dosya silinmesi, hatalı güncelleme, hesap ele geçirilmesi ve donanım arızası aynı yedeği farklı biçimlerde etkileyebilir. Küçük bir web sitesi için bile kapsam, zamanlama, erişim ve geri yükleme testi belirlenirse kesinti sırasında karar vermek kolaylaşır.

Önce kayıp toleransını belirleyin

RPO, kabul edilebilir veri kaybının zaman açısından hedefidir; RTO ise hizmeti geri getirmek için hedeflenen süredir. Bunlar otomatik garanti değildir, planlama ölçütleridir. Örneğin günlük yedek alan bir mağaza, son yedekten sonra gelen siparişlerin nasıl korunacağını ayrıca düşünmelidir. Yedeğin indirilmesi saatler sürüyorsa kısa geri dönüş hedefi de ek hazırlık gerektirir.

Veriyi önemine göre ayırın. Yeniden üretilebilen önbellek dosyalarıyla müşteri kayıtlarının korunma önceliği aynı değildir. Uygulama dosyaları, veritabanı, yapılandırma, DNS bilgileri ve erişim kurtarma belgeleri farklı saklama yöntemleri gerektirebilir. Envanter, yedekleme araçlarının kapsamını değerlendirmek için başlangıç noktasıdır.

3-2-1 yaklaşımını doğru yorumlayın

Yaygın 3-2-1 yaklaşımı, asıl veri dahil üç kopya, iki farklı ortam veya bağımsız hata alanı ve bir uzak kopya planlamayı anlatır. Sayılara ulaşmak tek başına yeterli değildir. Aynı yönetici parolasıyla silinebilen üç çevrim içi kopya ortak riske sahip olabilir. Çevrim dışı veya değiştirilemez kopya, ayrı erişim yetkileri ve şifreleme ihtiyaca göre değerlendirilmelidir.

Uygulanabilir plan adımları

1. Kapsamı yazın. Hangi dosya, veritabanı ve yapılandırmaların korunacağını belirleyin.
2. Sıklığı seçin. Veri değişim hızına ve kayıp toleransına göre zamanlayın.
3. Saklama süresini belirleyin. Yanlış değişikliğin geç fark edilmesi olasılığına karşı birden fazla tarih tutun.
4. Erişimleri ayırın. Üretim hesabının bütün yedekleri silebilmesini gerektirmeyen bir yapı düşünün.
5. Başarıyı izleyin. İşin çalıştığını, dosyanın oluştuğunu ve uzak aktarımın tamamlandığını kontrol edin.
6. Geri yüklemeyi deneyin. İzole ortamda ölçülen sonuçları kaydedin ve eksikleri düzeltin.

Snapshot ile yedek aynı şey değildir

Snapshot, belirli bir noktadaki duruma hızlı dönüş için yararlı olabilir. Ancak aynı altyapıya bağımlıysa bağımsız yedek ihtiyacını karşılamayabilir. Çalışan veritabanının tutarlılığı, snapshot yöntemine ve uygulamanın nasıl hazırlandığına bağlıdır. Sağlayıcınızdan kapsamı, saklama süresini ve silinme koşullarını öğrenin; hizmet adından varsayım çıkarmayın.

Bir örnek üzerinden düşünün: dosyalar pazartesi, veritabanı salı gününe aitse, salı yüklenen bir görselin kaydı bulunup dosyası eksik olabilir. Yedek bileşenlerinin aynı mantıksal ana ait olması geri yüklemenin doğruluğunu etkiler. E-ticarette sipariş ve ödeme kayıtları arasındaki tutarlılık daha da kritiktir.

Geri dönüş testini belgeleyin

Testte yalnız arşivi açmayın; uygulamayı başlatın, örnek kayıtları karşılaştırın ve önemli işlevleri deneyin. Gerçek müşterilere e-posta veya ödeme bildirimi gitmesini önlemek için test bağlantılarını izole edin. Toplam süreyi, kullanılan erişimleri ve eksik araçları yazın. Yedek şifreleme anahtarı veya sağlayıcı hesabı erişilemez durumdaysa bunu olay yaşamadan fark etmek değerlidir.

Sık sorulan sorular

RAID yedek yerine geçer mi? Hayır. Disk dayanıklılığı ile yanlış silinmiş veriyi geçmiş tarihten geri getirmek farklı ihtiyaçlardır.

Yedek başarı bildirimi yeterli mi? Geri yükleme testi yapılmadan kullanılabilirlik kesinleşmez.

Eski yedekleri ne zaman silebilirim? Saklama planına ve doğrulanmış yeni kopyalara göre karar verin; tek sağlam kopyayı yanlışlıkla kaldırmayın.

İlgili teknik kaynak

• CISA yedek koruma ve geri yükleme önerileri