Bir fidye yazılımı saldırısı, donanım arızası veya basit bir insan hatası — kritik sistemleriniz birden durduğunda asıl soru "veri kaybettik mi?" değil, "ne kadar veri ve ne kadar zaman kaybetmeyi göze alabiliriz?" olur. Bu iki sorunun cevabı, felaket kurtarma stratejinizin temelini oluşturur.
Felaket kurtarma (Disaster Recovery, DR) ve yedekleme çoğu kurumda "bir gün lazım olur" diye ertelenir. Oysa kriz anında doğaçlama yapacak zaman yoktur. Bu yazıda, sağlam bir DR stratejisinin iki temel metriği olan RPO ve RTO'yu nasıl belirleyeceğinizi ve yedekleme yaklaşımınızı bunlara göre nasıl tasarlayacağınızı ele alıyoruz.
Kısaca: RPO (Recovery Point Objective), bir felakette göze alabileceğiniz maksimum veri kaybını süre cinsinden ifade eder — yani yedekleme sıklığını belirler. RTO (Recovery Time Objective) ise sistemin ne kadar sürede yeniden çalışır hale gelmesi gerektiğidir — yani kurtarma altyapısını belirler. Doğru DR stratejisi, her sistem için bu iki hedefi iş etkisine göre tanımlamak ve yedekleme mimarisini buna uydurmakla başlar.
RPO Nedir?
RPO, "ne kadar veri kaybını kabul edebiliriz?" sorusunun cevabıdır. Örneğin RPO'nuz 1 saat ise, yedeklerinizin en fazla 1 saat önceki duruma dönebilecek sıklıkta alınması gerekir; felaket anında son 1 saatin verisini kaybetmeyi göze almışsınız demektir.
RPO doğrudan yedekleme sıklığını belirler. Günde bir yedek alıyorsanız RPO'nuz fiilen 24 saattir. Saatlik anlık görüntüler (snapshot) veya sürekli veri koruması (CDP) ile bu süre dakikalara indirilebilir. Kritik bir veritabanı için RPO dakikalar olmalıyken, nadiren değişen bir arşiv için günler kabul edilebilir.
RTO Nedir?
RTO, "sistem ne kadar sürede tekrar ayağa kalkmalı?" sorusunun cevabıdır. Bir e-ticaret platformu için RTO dakikalarla ölçülürken, iç bir raporlama aracı için saatler tolere edilebilir. RTO ne kadar kısaysa, kurtarma altyapısı o kadar gelişmiş (ve maliyetli) olmalıdır.
RTO'yu karşılamak için yedeklerin yalnızca var olması yetmez; hızlı geri yüklenebilir olması gerekir. Soğuk bir yedek bandından geri dönüş saatler alırken, sıcak bir yedek site veya replikasyon dakikalar içinde devreye girer.
RPO ve RTO Nasıl Belirlenir?
Bu iki metrik teknik değil, iş kararıdır. Doğru belirlemek için iş etki analizi (BIA) yapılır:
- Sistemleri kritiklik düzeyine göre sınıflandırın: Her uygulamanın durması iş için ne kadar maliyetlidir?
- Veri değişim hızını ölçün: Sistem ne sıklıkla ve ne kadar veri üretiyor? Bu, makul RPO'yu belirler.
- Kesinti maliyetini hesaplayın: Bir saatlik kesinti ciroda, itibarda veya cezada ne kaybettirir? Bu, RTO'ya yapılacak yatırımı haklı çıkarır.
- Maliyet-risk dengesini kurun: Sıfıra yakın RPO/RTO teknik olarak mümkündür ama pahalıdır. Hedef, iş riskini kabul edilebilir maliyetle dengelemektir.
3-2-1 Yedekleme Kuralı
Sağlam bir yedekleme stratejisinin altın standardı 3-2-1 kuralıdır:
- 3 kopya: Verinizin en az üç kopyası olsun (bir asıl, iki yedek).
- 2 farklı ortam: Kopyalar en az iki farklı ortam türünde tutulsun (ör. disk + bulut).
- 1 kopya site dışında: En az bir kopya fiziksel olarak farklı bir lokasyonda bulunsun — yangın, sel veya fidye yazılımı tüm yerel kopyaları aynı anda vurmasın.
Fidye yazılımlarına karşı buna bir de değişmez (immutable) yedek eklemek kritik önemdedir; saldırgan bağlantı kursa bile bu kopyayı silemez veya şifreleyemez.
İzleme Olmadan DR Eksiktir
En iyi yedekleme planı bile, yedeklerin başarısız olduğunu fark etmiyorsanız değersizdir. Yedek işlerinin durumunu, depolama kapasitesini ve replikasyon sağlığını sürekli izlemek gerekir. ManageEngine OpManager gibi izleme araçları, yedekleme sunucularının ve depolama altyapısının sağlığını proaktif takip ederek, bir sorun krize dönüşmeden uyarı verir.
Ayrıca DR planı düzenli olarak test edilmelidir. Hiç denenmemiş bir kurtarma planı, plan değil temennidir. Yılda en az bir kez gerçek bir geri yükleme tatbikatı yapmak, RTO hedefinizin kâğıt üzerinde değil sahada da geçerli olduğunu kanıtlar.
İş Sürekliliği ile İlişkisi
DR, daha geniş bir iş sürekliliği (Business Continuity) planının teknik bileşenidir. İş sürekliliği "iş nasıl devam eder?" sorusuna bütünsel cevap verirken; felaket kurtarma, bunun BT altyapısı ayağını oluşturur. Olgun bir kurum, felaket kurtarma ve yedekleme stratejisini kurumsal sürekliliğin ayrılmaz bir parçası olarak ele alır.
Sıkça Sorulan Sorular
RPO ile RTO arasındaki fark nedir?
RPO göze alınabilecek maksimum veri kaybını (geçmişe dönük) ifade eder ve yedekleme sıklığını belirler. RTO ise sistemin ne kadar sürede ayağa kalkması gerektiğini (ileriye dönük) ifade eder ve kurtarma altyapısını belirler.
Düşük RPO her zaman iyi midir?
Düşük RPO daha az veri kaybı demektir ama daha sık yedekleme ve daha gelişmiş altyapı gerektirir, dolayısıyla maliyetlidir. Doğru RPO, sistemin iş kritikliğine göre belirlenir.
3-2-1 kuralı neden önemli?
Tek bir yedek kopya, o kopyanın bulunduğu ortam zarar görürse işe yaramaz. 3-2-1 kuralı, kopyaları farklı ortamlara ve lokasyonlara dağıtarak tek noktadan çöküş riskini ortadan kaldırır.
Yedekleme ile felaket kurtarma aynı şey mi?
Hayır. Yedekleme, verinin kopyasını almaktır; felaket kurtarma ise o kopyayı kullanarak sistemleri hedeflenen sürede yeniden çalışır hale getiren süreçtir. Yedekleme, DR'ın bir parçasıdır ama tek başına yeterli değildir.
Sonuç
Sağlam bir felaket kurtarma stratejisi, doğru sorularla başlar: Ne kadar veri kaybını göze alabiliriz (RPO)? Ne kadar sürede ayağa kalkmalıyız (RTO)? Bu hedefleri iş etkisine göre belirleyip yedekleme mimarisini, 3-2-1 kuralını ve düzenli testleri bunların üzerine inşa etmek, kriz anında doğaçlamayı ortadan kaldırır.
Technodus, kurumların felaket kurtarma ve yedekleme stratejisini tasarlamasında, izleme altyapısını kurmasında ve iş sürekliliği hedeflerini sahaya taşımasında destek verir. İhtiyaçlarınızı değerlendirmek için bizimle iletişime geçebilirsiniz.