Bir yedekleme planı yazılım seçimiyle değil, iki soruyla başlar: Bu sistem en fazla ne kadar süre durabilir? Bu sistemde en fazla ne kadar veri kaybını kaldırabilirsiniz? Birinci sorunun cevabına RTO (Recovery Time Objective, kurtarma süresi hedefi), ikincisininkine RPO (Recovery Point Objective, kurtarma noktası hedefi) denir. Bu iki hedef; yedekleme sıklığını, geri dönüş yöntemini ve dolayısıyla maliyeti belirler. Bu yazıda iki kavramı, aralarındaki farkı ve hedefleri sistem bazında nasıl belirleyeceğinizi anlatıyoruz. Hedefler dakikalar seviyesindeyse konu felaket kurtarma planına dönüşür.
RTO nedir?
RTO, bir sistemin arıza sonrasında kurtarma aşamasında kalabileceği, iş süreçlerini olumsuz etkilemeye başlamadan önceki en uzun süredir. ABD Ulusal Standartlar ve Teknoloji Enstitüsü (NIST) kavramı bu şekilde tanımlar. Daha basit söylersek: Sistem durduğu andan yeniden kullanılabilir olduğu ana kadar geçmesine izin verdiğiniz süre.
RTO saatle ölçülür ve yalnızca teknik bir geri yükleme süresi değildir. Arızanın fark edilmesi, karar verilmesi, yedeğin bulunması, geri yüklenmesi, uygulamanın kontrol edilmesi ve kullanıcıların yeniden bağlanması bu sürenin içindedir. Beş saat süren bir geri yükleme, dört saatlik bir RTO’yu teknik olarak karşılayamaz.
RPO nedir?
RPO, bir kesintiden sonra verinin geri getirilmesi gereken zaman noktasıdır. Pratikte şu soruya cevap verir: Son yedekten bu yana oluşan veriden ne kadarını kaybetmeyi kabul edebilirsiniz?
Gece bir kez yedeği alınan bir muhasebe veritabanı, öğleden sonra bozulursa sabahtan beri girilen tüm faturalar kaybolur. Bu sistemin RPO’su fiilen yaklaşık bir gündür. Bu kabul edilemiyorsa yedek sıklığı artırılmalı, gerekirse veri başka bir sisteme sürekli kopyalanmalıdır.
RTO ile RPO arasındaki fark
İki kavram çoğu zaman karıştırılır, çünkü ikisi de zamanla ölçülür. Fark, zaman çizelgesinin hangi yönüne baktıklarıdır: RPO arızadan geriye, RTO arızadan ileriye bakar.
| RPO | RTO | |
|---|---|---|
| Cevapladığı soru | Ne kadar veri kaybedebilirim? | Ne kadar süre durabilirim? |
| Zaman yönü | Arızadan geriye, son sağlam kopyaya | Arızadan ileriye, sistemin yeniden açılmasına |
| Neyi belirler? | Yedek sıklığını, replikasyon ihtiyacını | Geri dönüş yöntemini, yedek altyapının hızını |
| Nasıl kısalır? | Daha sık yedek, sürekli replikasyon | Hızlı geri yükleme, yedek üzerinden çalıştırma, hazır bekleyen kopya |
İki hedef birbirinden bağımsızdır. Bir sistemin RPO’su kısa, RTO’su uzun olabilir: Hiç veri kaybetmek istemediğiniz ama bir gün beklemeye razı olduğunuz bir arşiv veritabanı gibi. Tersi de mümkündür.
Hedefleri nasıl belirlersiniz?
RTO ve RPO, BT ekibinin tek başına vereceği kararlar değildir. İş birimleriyle birlikte, her sistemin durmasının işe etkisine bakılarak belirlenir. Şu adımlar işe yarar:
- Sistemleri listeleyin. ERP, muhasebe veritabanı, e-posta, dosya sunucusu, üretim hattı yazılımı, web sitesi.
- Her birinin durmasının etkisini sorun. Bir saat durursa ne olur? Bir gün durursa? Sipariş alınamıyor mu, üretim duruyor mu, yasal bir süre mi kaçıyor?
- Kaybedilen verinin yeniden oluşturulup oluşturulamayacağını sorun. Kâğıt üzerinden yeniden girilebilen veri ile hiçbir yerde kaydı kalmayan veri aynı değildir.
- Sistemleri kademelere ayırın. Genellikle sistemlerin küçük bir kısmı gerçekten kritiktir.
- Maliyetle dengeleyin. Hedef kısaldıkça maliyet artar. Her sisteme dakikalık hedef koymak gerekmez.
Bu çalışmada üçüncü bir kavramla da karşılaşabilirsiniz: azami tolere edilebilir kesinti süresi (MTD, Maximum Tolerable Downtime). NIST’in acil durum planlama rehberinde MTD, bir iş sürecinin kesintiye uğramasını yönetimin kabul edebileceği toplam süreyi ifade eder. RTO bu sürenin içinde kalmalıdır; çünkü sistem ayağa kalktıktan sonra da verinin kontrol edilmesi, eksik kayıtların tamamlanması ve iş sürecinin yeniden başlaması zaman alır. Kısacası MTD işin sınırını, RTO ise BT’nin bu sınır içindeki payını gösterir.
Aşağıdaki tablo, orta ölçekli bir üretim firması için örnek bir sonuçtur. Rakamlar yalnızca örnektir; sizin hedefleriniz iş süreçlerinize göre farklı olacaktır.
| Sistem | Örnek RPO | Örnek RTO | Olası yöntem |
|---|---|---|---|
| ERP ve muhasebe veritabanı | 15 dakika | 1 saat | Sık yedek ve replikasyon |
| E-posta | 1 saat | 4 saat | Sık yedek ve e-posta arşivi |
| Dosya sunucusu | 4 saat | 8 saat | Gün içinde birkaç kez yedek |
| Arşiv sunucusu | 24 saat | 2 gün | Günlük yedek |
Hedeften yönteme
Hedefler belirlendikten sonra teknik tasarım kendiliğinden şekillenir.
RPO’yu karşılamak
RPO saatler seviyesindeyse gün içinde birden fazla yedek almak genellikle yeterlidir. Dakikalar seviyesindeyse sık artımlı yedekler ya da ikinci bir lokasyona sürekli replikasyon gerekir. Veritabanlarında işlem günlüklerinin (transaction log) ayrıca yedeklenmesi, RPO’yu tam yedek sıklığından bağımsız olarak kısaltır.
RTO’yu karşılamak
Onlarca terabaytlık bir sunucuyu yedekten geri yüklemek saatler sürebilir. RTO bundan kısaysa, sanal makineyi doğrudan yedek dosyası üzerinden çalıştıran anında kurtarma yöntemleri ya da ikinci lokasyonda hazır bekleyen replikalar gerekir. Uzak kopyanın bulutta durması da RTO’yu etkiler: Buluttan geri yükleme, internet hattınızın hızıyla sınırlıdır. Bu yüzden hızlı geri dönüş için yerel bir kopya, felaket senaryosu için uzak bir kopya birlikte planlanır.
Test edilmemiş hedef, hedef değildir
Kâğıt üzerindeki RTO ile gerçek geri dönüş süresi arasındaki farkı yalnızca test gösterir. Bir geri yükleme testinde süreyi baştan sona ölçün: arızanın fark edilmesi, kararın verilmesi, geri yükleme ve kullanıcıların sisteme dönmesi. Sonuç hedefi aşıyorsa ya yöntem değişmeli ya da hedef iş birimleriyle yeniden konuşulmalıdır. Testleri canlı sistemi etkilemeyen yalıtılmış bir ortamda, düzenli aralıklarla yapmak gerekir.
Hedefleri de zaman zaman yeniden gözden geçirin. Yeni bir e-ticaret kanalı açıldığında, üretim vardiyası arttığında ya da bir sistem buluta taşındığında, dün kabul edilebilir olan bir günlük kesinti bugün kabul edilemez hâle gelebilir. Yılda en az bir kez, iş birimleriyle birlikte listeyi güncellemek iyi bir alışkanlıktır.
Teknik hedeflerin iş tarafındaki karşılığını, kimin neyi hangi sırayla yapacağını iş sürekliliği planı yazımızda anlattık.
Nereden başlamalı?
İlk adım, en kritik üç sisteminizi seçip her biri için iki soruyu sormaktır: En fazla ne kadar durabilir, en fazla ne kadar veri kaybedebiliriz? Ardından mevcut yedekleme yapınızın bu cevapları gerçekten karşılayıp karşılamadığına bakın. Çoğu işletmede fark, bu karşılaştırmada ortaya çıkar.
- Önce dinleriz. Sistemlerinizi iş etkisine göre sıralar, RTO ve RPO hedeflerini iş birimlerinizle birlikte belirleriz.
- Birlikte planlarız. Hangi sistemin yedekleme ile, hangisinin replikasyonla korunacağını, maliyeti hedeflerle dengeleyerek tasarlarız.
- Kurar ve ölçeriz. Kurulumun ardından gerçek bir geri dönüş testi yapar, ölçülen süreleri hedeflerle karşılaştırırız.
- Yanınızda kalırız. Testleri düzenli aralıklarla tekrarlar, sistemleriniz değiştikçe hedefleri birlikte güncelleriz.
Kritik sistemleriniz için yedekten daha hızlı bir geri dönüş yolu arıyorsanız felaket kurtarma sayfamıza göz atabilirsiniz.
