Kurtarma süresi hedeflerinizi belirlemek, özellikle ağ saldırıları ve fidye yazılımı saldırıları yükselişteyken çok önemlidir. Bir sonraki kurbanın ne zaman olacağını asla bilemezsin. Bu noktada, Kurtarma Süresi Hedefiniz tanımlanmadıysa, nasıl bir veri yedekleme ve kurtarma planı oluşturursunuz?
Bu gönderi, RTO'nun temelleri ve RTO'nuzu ayarlarken akılda tutulması gereken faktörler konusunda size yol gösterecektir.
İyileşme Süresi Hedefi nedir?
Kurtarma Süresi Hedefi (RTO), bir uygulamanın bir felaket, başarısızlık veya kabul edilemez herhangi bir olay meydana geldikten sonra bir işletmede önemli bir hasara neden olmadan, bir uygulamanın kapalı olabileceği veya kuruluşun dayanabileceği maksimum kabul edilebilir kesinti süresi olarak tanımlanır.
RTO süresi, hizmet düzeyi anlaşmasında tanımlandığı şekilde, arızalı bir sistemin sistem geri yüklemesini kurtarmak ve bitirmek için geçen süreyi önerir. Hizmet düzeyi hedefi, iş sürekliliğini sağlamak için bir felaket meydana geldiğinde kritik görev BT süreçlerini/işlemlerini kurtarmak/geri yüklemek için kuruluş tarafından belirlenen kurtarma süresini hesaba katar.
Pro İpucu: Bir felaketin etkisini en aza indirmek için her zaman mümkün olan en düşük RTO'ya ulaşmayı hedeflemelisiniz. RTO'nuzu belirlemek için öncelikle verilerin bulunmadığı sürenin işletmeniz üzerindeki etkisini belirlemelisiniz.
Örneğin:
- Verilerin %10'unun 24 saat içinde mevcut olması gerekiyorsa,
- Ve veritabanının tamamen kaybedilmesinden sonra, verilerin %50'si 2 gün içinde mevcut olmalıdır,
- Verilerin kalan %40'ı önümüzdeki 5 gün içinde kullanılabilir olmalıdır, bu durumda,
Toplam RTO'nuz = 8 gündür.
Başka bir örnek vermek gerekirse:
Exchange Sunucusunun kapalı olduğunu varsayalım. RTO'nuz 5 saatteyse, işletmenizin dayanabileceği maksimum izin verilen kapalı kalma süresi 5 saattir ve Exchange Server için RTO'nuz 5 saatten az olmalıdır. Olağanüstü durum kurtarma politikanız, verileri yedeklemek ve geri yüklemek için BT departmanı tarafından atılan gerekli adımları içermelidir.
Bu nedenle, kurtarma hedefi için zaman belirlenirken, tek bedene uygun bir çözüm yoktur. iş sürekliliği planı. RTO'lar, bir olağanüstü durum sonrasında verileri kurtarmak üzere ayarlanabilir. Bununla birlikte, bir olay meydana gelirse, felaket kurtarma planınızın gerçek hayattaki pratiklikleri, kurtarma sağlamak için kullanılan belirli araçlara ve teknolojiye de bağlıdır. Dolayısıyla, farklı teknolojiler ve DR araçları yeteneklerine göre değişiklik gösterdiğinden, RTO'yu vurma yeteneği de değişir. RTO, kesinti başlamadan önce bile ölçülür ve sunucuları onarmak, öncelikli uygulamaları yüklemek ve verileri geri yüklemek için geçen süreyi içerir. Ayrıca kurtarma yöntemlerini ve kurtarılması gereken yedeklenmiş verileri içerir.
RTO Neyi Belirler?
Kurtarma Süresi Hedefi, uygulamaların, sistemlerin ve/veya süreçlerin aksama süresinde hayatta kaldığı ve kesinti başlamadan önce çalışmadığı hedeflenen bir süredir. RTO parametreleri dahilindeki uygulamalara ve süreçlere öncelik verilmesi için gereken sürenin uzunluğunu belirlemek için RTO büyük önem taşımaktadır. Veri koruma planında ve olağanüstü durum kurtarma stratejisinde RTO, "hizmet kesintisi bildiriminden sonra hizmetlerin geri yüklenmesi için belirlenen hedef süre nedir?" sorusuna yanıt verir.
RTO'lar şunları belirleyebilir:
- Bir siteyi, olayın normal operasyon akışını kestiği andan geri yüklenene kadar kesintiye uğrattığı andan itibaren kurtarmak için ayarlanacak gerçek zamanlı süre
- Olağanüstü durum kurtarma planının uygulanması için hangi BT hazırlıkları tasarlanmalıdır?
- Sistem veya temel uygulamalar çevrimdışı olduğunda kabul edilebilir veri kaybı riski düzeyi.
Olağanüstü Durum Kurtarma Planlaması için RTO Nasıl Hesaplanır?
Bir RTO metriği, sistem veya uygulamanın kapalı kalma süresinden sonra ne kadar hızlı kurtarılabileceğine ve sisteminizi tekrar çevrimiçi duruma getirebileceğine ilişkin eşiği belirlediğinden, BT ekibi için hedef beklentiyi önceden belirler. Bu önlemi, sistemi geri yüklemek için "gerçek zamanlı" miktar açısından tanımladıktan sonra, hizmeti yeniden çalışır hale getirmek için kurtarma stratejinizi planlayabilirsiniz. RTO'yu hesaplamak için, (BCP) İş Sürekliliği Planı kurtarma süresi hedefindeki bir kesintiyle ilişkili kayıpları göz önünde bulundurmalısınız. Ayrıca, hizmetlerin kesintiye uğramasının kısa vadeli veya uzun vadeli etkilerini açıklayan bir etki analizi de ekleyin. Buna riskler, kayıp gelir, giderler, müşteriye yönelik uygulamalar, görev açısından kritik uygulamalar ve etkilenen veya kullanılamayacak olan daha az öncelikli uygulamalar dahildir. RTO, veri kurtarma işlemi için kesinti süresi ve zaman sınırlamaları ile daha fazla ilgilenir.
Bir RTO'yu çözmek için birden fazla RTO kategorisine ihtiyacınız olabilir, çünkü bazı kesintiler fazla kurtarma süresi gerektirmeyebilirken bazıları farklı uzun vadeli koruma çözümleri gerektirebilir. Örneğin, görev açısından daha az kritik uygulamalar için RTO çok daha uzun olabilir (sık kullanılmaz). Çalışmakta olan birden çok güvenlik sisteminin karmaşıklık düzeylerine bağlı olarak, RTO'yu kısa ve uzun aralıklı yedeklemelere göre ayarlamanız gerekebilir. Bu, bir fidye yazılımı olayı veya başka bir büyük felaket olayı nedeniyle olabilir.
RTO Hesaplanırken Dikkat Edilmesi Gereken Asal Faktörler
- Geri kazanım çözümleri için maliyet/fayda denklemi
- Bireysel sistemlerin ve verilerin öncelikli uygulamaları
- BT altyapısını geri yüklemek için süreçlere, otomatikleştirilmiş tekniklere veya teknolojilere dayalı olarak BT departmanı tarafından atılacak adımlar
- Kesinti ve azaltma maliyeti
- Kurtarma prosedürünün karmaşıklığı
RTO Örnek Aralıkları
Sıfıra yakın bir RTO elde etmek çoğu BT kuruluşu için maliyetlidir, ancak uygulamalara ve verilere öncelik veriyorsanız bunu başarmak mümkündür. Daha az iş açısından kritik uygulamalar için, RTO saati normalden daha uzun objektif süreler tüketebilir. Görev açısından kritik uygulamalar için sıfıra yakın RTO planları, anında yük devretme özelliğini değerlendirmenizi gerektirebilir.
Kesintinin ciddiyetine bağlı olarak, ulaşılabilir hedef RTO süresini ayarlayabilirsiniz. Ancak, RTO geri yükleme süresi aynı zamanda BT organizasyonunun sınırlamalarına da bağlıdır. Örneğin, tüm BT işlevlerinin ve işlemlerinin geri yüklenmesi 3 saat sürüyorsa, RTO en az 3 saat olmalıdır.
not: Olağanüstü durum kurtarma (DR) açısından, RTO saati kurtarma işlemleri başladığında başlar.
İş birimleriniz için RTO'yu (Kurtarma Süresi Hedefi) hesaplarken şu örnek aralıkları göz önünde bulundurun:
1 saat
Bu aralık, harici sabit sürücülerde yedekli veri yedeklemesi içindir.
5 Günleri
Bu durumda, en uygun maliyetli çözüm, verileri bir kompakt disk, teyp veya tesis dışı disk depolama kullanarak yedeklemek olacaktır.
Zmanda Yolu olan RTO'ya ulaşın
Kurtarma Süresi Hedefi (RTO) ve Kurtarma Noktası Hedefi (RPO) inanılmaz derecede önemli hedeflerdir ve bir kurtarma planının temelidir. Pratik kurtarma hedeflerinin bir dizi adımını nasıl belirlersiniz? Yardım edebileceğimiz yer burası!
Zmanda'nın DRaaS planı ve özel hizmet düzeyi anlaşmaları ile, işletmenizin büyüklüğünden bağımsız olarak, iş ihtiyaçlarınıza bağlı olarak hizmet dışı kalma sürelerini kısaltmanıza ve hizmet dışı kalma süresinin acısını önlemenize yardımcı olabiliriz. Kurumsal çözümümüz, geçişi desteklemek ve nispeten daha hızlı RTO'lar elde etmek için hibrit yedeklemelerin yanı sıra, Amazon Glacier'ı sağlam bir yüksek kullanılabilirlik dağıtan ve iş sürekliliğini sağlayan 20 kat daha düşük maliyetli uzun vadeli veri arşivi ile birleştirir.
Kurumsal yedekleme çözümümüz, müşterilerin ihtiyaçlarına özel olarak uyarlanmış yedekleme, olağanüstü durum kurtarma ve uzun vadeli depolama arşivlemeyi birleştirir. Bu, toplam sunucu arızası olayı olduğunda bile ortamınızı kurtarırken güvenlik, güvenilirlik, ölçeklenebilirlik ve kullanılabilirlik sağlar.
Kendiniz görün! Bir ile başlayalım ücretsiz deneme veri yedeklemenizi planlamak veya bir gösteri. Herhangi bir sorunuz var mı? lütfen bize ulaşın okuyun.
