Sunucu yanabilir, veri merkezi erişilemez olabilir, fidye yazılımı tüm dosyaları şifreleyebilir ya da bir çalışan yanlışlıkla bir tabloyu silebilir. Felaket kurtarma (Disaster Recovery, DR) planı, bu durumlarda ne kadar veri kaybını ve ne kadar kesintiyi göze alabileceğinizi önceden belirleyip ona göre hazırlanmaktır.
İki temel ölçü: RPO ve RTO
- RPO (Recovery Point Objective): En fazla ne kadar veri kaybını kabul edebilirsiniz? RPO 24 saat ise, dünün yedeğine dönmek kabul edilebilir demektir.
- RTO (Recovery Time Objective): Sistem en geç ne kadar sürede tekrar çalışmalı? RTO 4 saat ise, felaketten 4 saat sonra işlerin devam etmesi gerekir.
| Sistem | Örnek RPO | Örnek RTO |
|---|---|---|
| Kurumsal tanıtım sitesi | 1 hafta | 1 gün |
| Stok ve satış programı | 1 saat | 4 saat |
| E-ticaret ödeme altyapısı | Dakikalar | Dakikalar |
Daha kısa RPO ve RTO, daha yüksek maliyet demektir. Bu yüzden değerleri teknik ekip değil, işletme yönetimi iş etkisine bakarak belirlemelidir.
Yedek almak, kurtarabilmek değildir
Birçok işletme yedek aldığını düşünür; ama yedekten geri dönmeyi hiç denememiştir. Felaket günü şu sorular sorulur:
- Yedekler gerçekten çalışıyor mu, eksiksiz mi?
- Geri yükleme kaç saat sürüyor?
- Uygulamanın ayarları, sertifikaları ve gizli bilgileri nerede?
- Kurulumu kim, hangi belgeye bakarak yapacak?
3-2-1 kuralı ve geri yükleme testi için bkz. veritabanı yedekleme stratejisi.
Fidye yazılımı senaryosu
Fidye yazılımları artık yedekleri de hedefliyor. Ağa bağlı ve aynı yetkilerle erişilen yedekler, ana verilerle birlikte şifrelenebilir. Önlemler:
- En az bir yedek kopyasının çevrimdışı veya değiştirilemez (immutable) olması
- Yedek sistemine ayrı kimlik bilgileriyle erişim
- Düzenli kurtarma tatbikatı
Ayrıntılar: fidye yazılımına karşı korunma.
Basit bir plan şablonu
- Envanter: Hangi sistemler var, hangileri kritik?
- Hedefler: Her sistem için RPO ve RTO.
- Yedekler: Ne, ne sıklıkla, nereye, ne kadar süre saklanıyor?
- Kurtarma adımları: Sistemi sıfırdan ayağa kaldırma talimatı (sunucu, yazılım, ayarlar, veri).
- Sorumlular ve iletişim: Kim karar verir, kim uygular, müşterilere kim bilgi verir?
- Tatbikat takvimi: En az yılda bir, kritik sistemler için daha sık.
Kurtarma adımlarının yazılı olması, işi bilen tek kişiye bağımlılığı ortadan kaldırır. Bu belgeler yazılım dokümantasyonunun en değerli parçalarındandır.
Altyapıyı kod olarak tutmak
Sunucu kurulumlarının betiklerle veya Docker Compose gibi tanımlarla yapılması, kurtarmayı "hatırlamaya çalışarak kurulum" olmaktan çıkarır ve RTO'yu ciddi şekilde kısaltır.
Sık sorulan sorular
Bulut kullanıyorum, yine de plan gerekir mi?
Evet. Bulut sağlayıcısı altyapıyı korur; ama yanlışlıkla silinen veri, ele geçirilen hesap veya bölgesel kesinti senaryoları sizin sorumluluğunuzdadır.
Tatbikat nasıl yapılır?
Yedekten ayrı bir ortama geri yükleme yapılır, uygulamanın çalıştığı ve verilerin eksiksiz olduğu doğrulanır, süre ölçülür ve plan güncellenir.
Sonuç
Felaket kurtarma planı, kötü günün iyi geçmesini sağlar. Hedefleri belirlemek, yedekleri test etmek ve adımları yazmak; kriz anında panik yerine bir kontrol listesiyle hareket etmenizi sağlar.
