RPO ve RTO neyi ifade eder?
RPO, geri dönülen veri noktasının olaydan ne kadar geride kalabileceğini ifade eden hedeftir. Örneğin bir saatlik RPO hedefi olan süreçte veri koruma yöntemi, son bir saatlik değişimin kaybolması ihtimalini dikkate alacak şekilde tasarlanmalıdır. Bu hedef tek başına belirli bir ürün veya yedekleme sıklığını zorunlu kılmaz.
RTO, olaydan sonra hizmetin yeniden çalışmasına kadar kabul edilen süredir. İki saatlik bir RTO hedefi için yalnızca yedek dosyasının mevcut olması yetmez; sunucu hazırlığı, veri aktarımı, uygulama kontrolleri ve erişimin yeniden açılması da bu zaman planına dahil edilir.
Yedeklenecek kapsamı ve saklama süresini belirleyin
Veritabanları, dosyalar, uygulama ayarları, erişim yapılandırmaları ve gerekli kurulum bilgileri envantere alınmalıdır. Bir sanal makine görüntüsüyle uygulamaya uygun veritabanı yedeği aynı korumayı sağlamayabilir. Kullanılan yöntemin uygulama tutarlılığı için uygunluğu kontrol edilmelidir.
Saklama süresi, günlük değişim miktarı ve geçmiş sürümlere dönüş ihtiyacıyla ilişkilidir. Yedek kapasitesini yalnızca mevcut veri boyutuna göre hesaplamak yeterli olmayabilir. Erişim yetkileri, şifreleme ve yedek ortamının üretim sisteminden ayrılması da tasarımın parçalarıdır.
RAID ve snapshot neden tek başına yeterli değildir?
RAID bazı donanım arızalarında sürekliliği destekleyebilir, ancak yanlışlıkla silinen dosyayı veya uygulamanın bozduğu kaydı geçmiş haline döndürmez. Snapshot hızlı geri dönüşte yararlı olabilir; aynı altyapıya bağlıysa o altyapının kaybından da etkilenebilir.
Farklı ortamlarda kopyalar tutulması ortak arıza riskini azaltır. Bunun nasıl uygulanacağı veri hacmi, bağlantı kapasitesi ve güvenlik ihtiyaçlarına bağlıdır. İkinci lokasyonda kopya bulunması da uygulamanın otomatik olarak çalışacağı anlamına gelmez; açılış ve erişim adımları tanımlanmalıdır.
Geri yükleme testiyle planı doğrulayın
Yedek işinin başarılı görünmesi, verinin kullanılabilir olduğunu tek başına kanıtlamaz. Kontrollü bir ortamda geri yükleme yaparak uygulamanın açıldığını, kullanıcıların erişebildiğini ve gerekli kayıtların mevcut olduğunu doğrulayın.
Testte ölçülen süreyi RTO hedefiyle karşılaştırın. Yedek alma, alarm takibi, geri yükleme ve son kabul görevlerinin sahiplerini belirleyin. Değişen uygulamalar ve büyüyen veriler kurtarma planını etkileyebilir; önemli değişikliklerden sonra planı tekrar değerlendirin.
Örnek senaryo: sipariş kaybı ile rapor kaybının etkisi farklıdır
Bir uygulama gün boyunca sipariş alıyor, başka bir uygulama ise haftalık rapor üretiyor olsun. İki sistem için de gecelik yedek bulunması aynı korumayı sağlıyormuş gibi görünebilir. Ancak sipariş uygulamasında gün içindeki kayıtların kaybı müşterilere ve muhasebeye yansıyabilir. Rapor uygulamasında bazı sonuçlar yeniden üretilebiliyorsa veri kaybının iş etkisi farklı olur.
Bu örnek, her sisteme aynı RPO ve RTO hedefi verilmemesi gerektiğini gösterir. Hedefi IT ekibi tek başına değil, verinin sahibi olan iş birimiyle belirlemelidir. Yeniden girilebilecek kayıtlar, yeniden üretilemeyen belgeler ve hizmetin kapalı kalmasına bağlı iş kaybı konuşulur.
Bir kurtarma sırasında geçen süre nerelere harcanır?
Geri dönüş süresi yalnızca yedek dosyasının diske kopyalanması değildir. Olayın fark edilmesi, doğru yedeğin seçilmesi, erişim izinlerinin hazırlanması ve hedef ortamın açılması da zaman alır. Ardından veritabanı veya dosyalar geri yüklenir, uygulama başlatılır ve kullanıcıların erişimi kontrol edilir. Dış sistem bağlantıları ve alan adı kayıtları da geçiş gerektirebilir.
Bu nedenle “yedek birkaç dakikada açılır” ifadesiyle bütün hizmetin kurtarma süresini aynı kabul etmeyin. Test sırasında her adımın süresini kaydedin. En uzun süren aşamanın veri aktarımı mı, ortam hazırlığı mı, yoksa iş biriminin doğrulaması mı olduğu görülür. Yedek kapasitesi ve bağlantı hızının yanı sıra insanlara bağlı onay adımlarını da planlamak gerekir.
Yedeklerin erişimi ve üretim sistemiyle ilişkisi
Yedeklere aynı kullanıcı ve aynı izinlerle erişilmesi, üretim sistemindeki bir sorunun kopyaları da etkilemesine yol açabilir. Yetki kapsamını, yedek ortamının üretimden ayrılığını ve silme işlemlerinin kontrolünü değerlendirin. Farklı ortamda tutulma, kopyanın kimler tarafından değiştirilebildiği ve erişim bilgilerinin nasıl saklandığı ayrı güvenlik konularıdır.
Şifreleme kullanılıyorsa geri yükleme için gereken anahtarların da erişilebilir olması gerekir. Yedek dosyasının bulunması ama anahtarın veya uygulama kurulum bilgisinin kaybolması kurtarmayı engelleyebilir. Kurtarma sırasında kullanılacak belgeler, yetkili kişiler ve gerekli erişim yöntemleri planın içinde tutulmalıdır. Teknik bir yedek işiyle işletmenin kullanılabilir kurtarma planı arasındaki fark burada ortaya çıkar.
Saklama politikası ve kapasite hesabı
Günlük kopyaların ne kadar süre tutulacağı ve aylık veya dönemsel kopyalara ihtiyaç olup olmadığı belirlenmelidir. Bir hatanın geç fark edilmesi, yalnızca son günün kopyasını tutmanın yetersiz kalmasına neden olabilir. Bununla birlikte bütün kopyaları sınırsız saklamak da depolama ve yönetim ihtiyacını artırır. İşin geçmişe dönük erişim ihtiyacıyla veri büyümesi birlikte ele alınır.
Kapasite hesabında canlı veri boyutu, değişim miktarı, kopya sayısı ve kullanılan yöntemin özellikleri dikkate alınır. Sıkıştırma veya tekilleştirme kullanılabiliyorsa gerçek kazanç veri türüne bağlıdır; tahmini bir oranı kesin sonuç saymayın. Yedek işlerinin başarısız olması veya depolamanın dolması için alarm sorumlusu belirleyin. Politikanın yalnızca belgede kalmaması, günlük işletimle ilişkilendirilmesi gerekir.
Kurtarma testinin teslimi bir tutanak olabilir
Kontrollü bir testte kullanılan yedeğin tarihi, hedef ortam, başlangıç ve bitiş saatleri kaydedilir. Uygulama açıldıktan sonra veri sahibi birkaç anlamlı kaydı doğrular. Oturum açma, dosya görüntüleme ve kritik işlemleri yapma gibi adımlar gözlenir. Eksik erişimler veya kurulum adımları bir sonraki test için düzeltilir.
Testin sonunda sadece “başarılı” demek yerine neyin kurtarıldığı, hangi verilerin kontrol edildiği ve toplam sürenin hedefe uyup uymadığı yazılabilir. Büyük bir sürüm geçişi veya veri hacmindeki önemli artıştan sonra eski testin hâlâ geçerli olup olmadığı değerlendirilir. Disket’ten yedekleme kapsamı isterken hedeflerinizi, kritik uygulamalarınızı ve geri yükleme testinde kimlerin görev alacağını belirtmeniz, kopya alma hizmetiyle kurtarma ihtiyacını birlikte tarif eder.
Örnek kurtarma testi kaydı
| Kayıt alanı | Kaydedilecek bilgi | Neden gerekli? |
|---|---|---|
| Kullanılan yedek | Tarih, uygulama ve veri kapsamı | Geri dönülen veri noktasını bilmek |
| Ortam hazırlığı | Gerekli erişim ve kurulum adımları | Eksik bağımlılıkları görmek |
| Geri yükleme | Başlangıç ve bitiş zamanı | Gerçek aktarım süresini ölçmek |
| İş doğrulaması | Kontrol edilen kayıt ve işlemler | Uygulamanın kullanılabildiğini görmek |
| Sonuç | Toplam süre ve eksik işler | RTO hedefiyle karşılaştırmak |
Teklif öncesi kontrol listesi
- Kritik uygulamalar ve veri sahipleri
- Her süreç için veri kaybı ve kesinti hedefleri
- Yedek sıklığı, saklama süresi ve ayrı kopyalar
- Geri yükleme yetkileri ve görev sahipleri
- Test sonuçları ve ölçülen kurtarma süresi
Sık sorulan sorular
Yedekleme ile felaket kurtarma aynı şey midir?
Yedekleme veri kopyalarını korur. Felaket kurtarma, bu verilerle hizmetin hangi ortamda, kim tarafından ve ne kadar sürede yeniden çalıştırılacağını da kapsar.
RPO ve RTO garantisi her sunucu hizmetinde bulunur mu?
Hayır. Bunlar planlama hedefleridir; sağlanacak kapsam, koşullar ve varsa taahhütler ayrıca teklifte veya hizmet sözleşmesinde belirlenmelidir.
Geri yükleme süresi RTO ile aynı süre midir?
Geri yükleme, kurtarmanın bir aşamasıdır. Olayın fark edilmesi, hedef ortamın hazırlanması, uygulamanın açılması, bağlantıların kurulması ve iş biriminin doğrulaması da toplam süreye dahil olabilir. Testte bu aşamalar ayrı ölçülmelidir.
Teknik kaynaklar
Disket Teknoloji’nin sektör faaliyetleri 2014 yılında şahıs şirketi olarak başladı. Bugün hizmetlerimiz Disket Teknoloji Ltd. Şti. bünyesinde sürüyor. Şirket geçmişimiz.