Sayfa yükleniyor
Yedekleme yazılımının panelinde her satır yeşilse rahatlamak kolaydır. Ancak yeşil ışık, yedeğin alındığını söyler; o yedekten çalışır bir sisteme dönebileceğinizi söylemez. Bu ikisi aynı şey değildir.
Bir arıza anında ölçülen tek şey şudur: ERP, üretim takip sistemi veya dosya sunucusu ne kadar sürede yeniden çalışır ve bu sırada ne kadar veri kaybedilir. Bu iki sorunun cevabı yedek alındığı gün değil, geri dönüş denendiği gün belli olur.
Yedekleme yazılımının başarı kaydı, verinin kaynaktan okunup hedefe yazıldığını gösterir. Bu kayıt, verinin tutarlı olduğunu, uygulamanın o veriyle açılacağını veya sanal makinenin önyükleme yapacağını göstermez.
Aradaki boşluk genellikle üç yerde ortaya çıkar. Birincisi, uygulama farkındalığı olmadan alındığı için tutarsız kalan veritabanı dosyaları. İkincisi, geri dönüş için gereken ama kendisi yedeklenmemiş bileşenler: lisans sunucusu, sertifikalar, etki alanı denetleyicisi, şifreleme anahtarları. Üçüncüsü, yedeği açacak boş donanım veya kapasitenin hiç ayrılmamış olması.
Bu nedenle yedekleme başarı oranı tek başına anlamlı bir ölçüt değildir. Ölçülmesi gereken şey, geri dönüş denemesinin sonucudur.
RPO, kabul edilebilir veri kaybının süresidir. Gece yedek alıyorsanız ve sistem ertesi gün öğleden sonra durursa, o gün girilen üretim kayıtları, irsaliyeler ve kalite ölçümleri yedekte yoktur. RPO bu boşluğun büyüklüğüdür.
RTO ise sistemin yeniden çalışır hale gelmesi için tanınan süredir. Bu süre geri dönüşün teknik olarak ne kadar sürdüğüyle değil, işin duruşa ne kadar dayanabildiğiyle belirlenir.
Kısa bir RPO isteniyorsa gecelik tam yedek yetmez; gün içinde çalışan artımlı yedek veya çoğaltma gerekir. Kısa bir RTO isteniyorsa, yedeği açacak donanım veya sanallaştırma kapasitesi önceden ayrılmış, yapılandırma adımları önceden yazılmış olmalıdır.
RPO ve RTO sistem bazında belirlenir. ERP veritabanı ile ortak dosya paylaşımını aynı hedefe bağlamak hem gereksiz maliyet hem de yanlış öncelik üretir. Bu değerleri BT tek başına değil, süreç sahibiyle birlikte yazmalıdır.
Test, üretim ortamına dokunmadan, izole bir ağda yapılır. Amaç yedeğin açılması değil, uygulamanın o veriyle çalıştığının doğrulanmasıdır.
Testin sıklığı sistemin kritikliğine göre değişir. Yılda bir yapılan tek bir deneme, aradaki altyapı değişiklikleriyle geçerliliğini kaybeder. Sunucu, uygulama sürümü, depolama veya ağ topolojisi değiştiğinde test tekrarlanmalıdır.
Yedekleme sistemine erişim günlük kullanılan yönetici hesaplarıyla aynı kimlik altyapısına bağlıysa, bir fidye yazılımı olayında yedekler de kaybedilebilir.
Rapor kısa olmalı ve teknik olmayan bir yöneticinin de okuyabileceği açıklıkta yazılmalı. Amaç arşiv doldurmak değil, bir sonraki adımı belirlemek.
Rapordaki en değerli satır genellikle engeller bölümüdür. Eksik bir parola, bulunamayan bir kurulum dosyası veya kimsenin bilmediği bir yapılandırma adımı, gerçek bir olayda kurtarma süresini belirgin biçimde uzatır.
Ücretsiz bir değerlendirmeyle başlıyoruz. Mevcut durumunuzu çıkarıyor, riskleri ve eksikleri önceliklendirilmiş bir yol haritası halinde sunuyoruz.
Ücretsiz değerlendirme
