Felaket kurtarma, yedeklemeler, RTO/RPO, failover ve hepsinden önemlisi, birçok şirketin ancak bir kesintiden sonra kendine sorduğu soru: Sistemi gerçekten geri yükleyip çalışmaya dönebiliyor muyuz?
Sunucu arızası. Hasarlı veritabanı. Bir dağıtım sonrasında ortaya çıkan hata. Fidye yazılımı. Altyapı sağlayıcısıyla ilgili sorunlar. Verilerin yanlışlıkla silinmesi. Tüm bir bölgenin devre dışı kalması.
Olası senaryolar çoktur. Sorun şu ki, çoğu şirket öncelikle kesintinin yaşanmaması için hazırlık yapar.
Ancak kesintinin gerçekten yaşanabileceği duruma çok daha nadir hazırlanır.
Felaket kurtarma tam da bu alanı kapsar.
Burada temel bir soru ortaya çıkar: Uygulamanız bugün saat 14.00'te çalışmayı durdurursa, onu yeniden çalışır duruma getirmek ne kadar sürer ve bu sırada ne kadar veri kaybedebilirsiniz?
Yanıtınız “Yedeğimiz var” ise bu, sorunun yanıtı değildir.
Yedekleme, felaket kurtarma değildir
Yedekleme, verilerin bir kopyasıdır. Felaket kurtarma ise sistemin çalışır duruma getirilmesi sürecidir.
Bu çok önemli bir ayrımdır.
Veritabanınız her gün yedekleniyor olabilir, ancak yine de şunları bilmiyor olabilirsiniz:
-
en son yedeğin sağlam olup olmadığını,
-
geri yüklenip yüklenemeyeceğini,
-
geri yüklemenin ne kadar süreceğini,
-
geri yüklemeden sonra veritabanının uygulamanın güncel sürümüyle çalışıp çalışmayacağını,
-
sistem yapılandırmasını da geri yükleyip yükleyemeyeceğinizi,
-
ortamı başlatmak için gereken tüm anahtarlara, sertifikalara ve gizli bilgilere sahip olup olmadığınızı,
-
uygulamayı çalıştırmak için gereken altyapının hâlâ kullanılabilir olup olmadığını,
-
adımları kimin gerçekleştireceğini,
-
tüm sürecin iş açısından kabul edilebilir süre içinde tamamlanıp tamamlanamayacağını.
NIST, yedeklerin geri yüklenmesini test etme gerekliliğini açıkça belirtirken AWS'nin güncel yönergeleri de düzenli kurtarma testlerini, yedeklemenin belirlenen RTO ve RPO hedeflerine gerçekten ulaşmayı sağlayıp sağlamadığını kontrol etmenin bir yolu olarak ele alıyor.
Bu nedenle yedekleme, kurtarma stratejisinin bir unsurudur; stratejinin bütünü değildir.
En önemli soru: Bir kesintiden sonra ne olacak?
Bir internet mağazası düşünelim.
Saat 10.17'de veritabanı yanıt vermeyi durduruyor.
Uygulama sunucusu çalışmaya devam ediyor ancak kullanıcılar giriş yapamıyor. Siparişler çalışmıyor. Yönetim paneli yanıt vermeyi kesiyor. Ödeme sistemi doğru bilgileri alamıyor.
Ekip durumu inceliyor.
Son veritabanı yedeğinin saat 8.00'de alındığı anlaşılıyor.
Teorik olarak veriler kurtarılabilir.
Ancak ardından başka sorular ortaya çıkıyor:
- Yedeğin nerede olduğu biliniyor mu?
- Nasıl geri yükleneceği biliniyor mu?
- Bunu yapabilecek kişi müsait mi?
- Yedek eksiksiz mi?
- Uygulama yapılandırması, yedekte kayıtlı sürümle eşleşiyor mu?
- Geri yüklemeden sonra veritabanı güncel uygulamayla çalışacak mı?
- Ve en önemlisi: mağazayı yeniden çalışır duruma getirmek ne kadar sürecek?
Daha önce kimse bunu kontrol etmediyse yanıt şaşırtıcı olabilir.
RTO — ne kadar süre hizmet dışı kalmayı kabul edebiliriz?
RTO (Recovery Time Objective), bir kesintiden sonra sistemin kurtarılması için kabul edilebilecek azami süreyi belirtir.
Örneğin: RTO = 4 saat , kuruluşun sistemin en fazla dört saat içinde yeniden çalışır duruma getirilmesini öngördüğü anlamına gelir.
Ancak bu, her uygulamanın RTO değerinin dört saat olması gerektiği anlamına gelmez.
Günde birkaç kez kullanılan bir iç sistem için bu süre kabul edilebilir olabilir. 7/24 çalışan bir satış platformu içinse çok ciddi kayıplara yol açabilir.
Dolayısıyla RTO, mevcut altyapının sunduklarına göre değil, iş ihtiyaçlarına göre belirlenmelidir.
NIST, RTO'yu sistemin kurtarma aşamasında kalabileceği ve bu sürenin sonunda kuruluşun faaliyetlerinin olumsuz etkilenmeye başlayacağı süre olarak tanımlar.
RPO — ne kadar veri kaybedebiliriz?
İkinci temel parametre, RPO (Recovery Point Objective) değeridir.
RPO şu soruyu yanıtlar: Bir kesintiden sonra verilerde ne kadar geriye gidebiliriz?
Örnek: RPO = 1 saat , kuruluşun en fazla yaklaşık bir saatlik veri kaybını kabul ettiği anlamına gelir.
Sistem saat 15.00'te arızalanırsa ve kullanılabilecek son yedek saat 14.00'e aitse, bu senaryo belirlenen RPO sınırları içindedir. Ancak yedek günde bir kez alınıyorsa, bir saatlik RPO beklemek zordur.
Dolayısıyla RPO, yedeklerin alınma yöntemini, veri çoğaltmayı ve altyapı tasarımını doğrudan etkiler.
RTO öncelikle ne kadar süre kullanılamaz durumda kalabileceğimizi söyler.
RPO ise ne kadar veri kaybedebileceğimizi söyler.
Bu iki parametre iş birimleriyle birlikte belirlenmelidir; çünkü bunlara ulaşmanın maliyeti ve teknik gereksinimleri vardır. Microsoft da RTO ve RPO'nun “sıfır kesinti ve sıfır veri kaybı” gibi soyut bir varsayımdan değil, gerçek iş gereksinimlerinden kaynaklanması gerektiğini vurguluyor.
Yedek mevcut olabilir ama yine de işe yaramayabilir
Bu, BT alanındaki en tehlikeli yanılgılardan biridir.
“Yedekleme başarılı şekilde yapılıyor” ifadesi otomatik olarak “sistem bu yedekten geri yüklenebilir” anlamına gelmez.
Yedek eksik olabilir. Hasarlı olabilir. Doğru şekilde kullanılamayacak veriler içerebilir. Tüm ortamın geri yüklenmesine olanak vermeyen bir yöntemle alınmış olabilir.
Bu nedenle yedek, gerçekten geri yüklenerek test edilmelidir.
Dosyanın mevcut olup olmadığını kontrol etmek yeterli değildir.
Yedeği geri yüklemek gerekir.
Sistemi başlatmak gerekir.
Verileri kontrol etmek gerekir.
Bağımlılıkları doğrulamak gerekir.
Yapılandırmayı kontrol etmek gerekir.
Süreyi ölçmek gerekir.
Ve sonucun RTO ve RPO hedeflerine uygun olup olmadığını yanıtlamak gerekir.
AWS, yedekten geri yüklerken sık yapılan bir hata olarak, geri yüklenen kaynağın gerçekten çalışıp çalışmadığını ve kurtarılan verilerin kullanılıp kullanılamadığını kontrol etmemeyi de belirtiyor.
Failover — geri yüklemeyi beklemek istemediğimizde
Her uygulama yeniden çalışır duruma getirilmek için saatlerce bekleyemez. Bu gibi durumlarda, diğer yöntemlerin yanı sıra failover mekanizmaları kullanılır.
Failover, çalışmanın birincil ortamdan önceden hazırlanmış yedek ortama aktarılmasıdır.
Bu ortam şunlardan biri olabilir:
-
yedek sunucu,
-
ikinci bir kullanılabilirlik alanı,
-
ikinci bir bölge,
-
veritabanı replikası,
-
bekleme ortamı,
-
başlatılmaya hazır alternatif altyapı.
En basit modelde uygulama tek bir yerde çalışır ve bir arıza durumunda yedek ortamı devreye alırız. Daha gelişmiş çözümlerde altyapının bir bölümü paralel olarak çalışır ve trafiği devralmaya hazırdır.
Ancak herkese uygun tek bir strateji yoktur.
Backup ve restore genellikle daha ucuzdur, ancak kurtarma süresinin daha uzun olması anlamına gelebilir. Warm standby veya aktif yedeklilik gibi çözümler kurtarma süresini önemli ölçüde kısaltabilir, ancak daha fazla yatırım ve daha karmaşık bir altyapı gerektirir.
Failover da test edilmelidir
Burada başka bir sorun ortaya çıkar.
Bir şirketin yedek ortamı olabilir, ancak bu ortamı iki yıldır kullanmamış olabilir;
- Hâlâ çalışıyor mu?
- Yapılandırması üretim ortamıyla aynı mı?
- Yeterli performansa sahip mi?
- Tüm hizmetler kullanılabilir durumda mı?
- Sertifikalar güncel mi?
- DNS doğru şekilde geçiş yapacak mı?
- Uygulama veritabanına bağlanacak mı?
- Yetkilendirme mekanizması çalışacak mı?
- Ekip tam olarak ne yapması gerektiğini biliyor mu?
Bu soruların yanıtını ancak test verebilir.
AWS, kurtarma yolunun çalıştığını doğrulamak ve gerçek RTO ile RPO değerlerinin varsayımlarla örtüşüp örtüşmediğini kontrol etmek için failover'ın düzenli olarak test edilmesini önerir.
Hiç test edilmemiş bir disaster recovery ortamı, kısmen yalnızca bir varsayımdan ibarettir.
Disaster recovery yalnızca altyapıdan ibaret değildir
DR'ye yalnızca sunucular açısından bakmak kolaydır.
Bu bir hatadır.
Kurtarma süreci şunları da kapsar:
- Veriler
Tüm önemli veriler koruma kapsamında mı? - Uygulama
Doğru kod sürümüne ve bunu dağıtma olanağına sahip miyiz? - Yapılandırma
Sistemi çalıştırmak için hangi ayarların gerektiğini biliyor muyuz? - Gizli bilgiler ve sertifikalar
Anahtarlara, token'lara ve sertifikalara güvenli erişimimiz var mı? - Dış bağımlılıklar
Harici ödeme sistemi, API, kimlik sağlayıcısı veya SaaS hizmeti kullanılamaz hale gelirse ne olur? - Altyapı
Uygulamayı çalıştırabileceğimiz bir ortamımız var mı? - İnsanlar
Prosedürü başlatma kararını kimin vereceği belli mi? - Prosedürler
Somut bir runbook var mı, yoksa kurtarma tek bir kişinin bilgisine mi dayanıyor?
Bu son nokta özellikle önemlidir.
Sistemi nasıl geri yükleyeceğini yalnızca bir yönetici biliyorsa henüz dayanıklı bir prosedürümüz yok demektir. Belirli bir kişiye bağımlıyız demektir.
Kurtarma prosedürü yazmak için en kötü zaman
Sistemin zaten çalışmadığı zamandır.
O sırada zaman baskısı, stres, müşterilerden gelen telefonlar ve yöneticilerin soruları vardır.
Bu nedenle prosedür önceden hazırlanmalıdır.
Prosedür, aşağıdakileri belirtmelidir:
-
disaster recovery'yi ne zaman başlatacağımızı,
-
kararı kimin vereceğini,
-
hangi sistemlere en yüksek önceliğin verileceğini,
-
yedeklerin nerede bulunduğunu,
-
yedeklerin nasıl geri yükleneceğini,
-
hangi bağımlılıkların devreye alınması gerektiğini,
-
failover'ın nasıl yapılacağını,
-
çalışmanın doğru olduğunu nasıl doğrulayacağımızı,
-
arıza hakkında nasıl iletişim kuracağımızı,
-
failback'e ne zaman başlanabileceğini,
-
birincil ortama dönüşü kimin onaylayacağını.
Ciddi bir arıza durumunda “Şimdi ne yapıyoruz?” sorusuna yer olmamalıdır.
Prosedür bu soruyu önceden yanıtlamalıdır.
DR, uygulamanın bir özelliği gibi test edilmelidir
Kurtarmayı yazılım testlerine benzer şekilde ele almak iyi bir yaklaşımdır. Prosedürü bir kez hazırlamak yeterli değildir.
Sistem değişir.
Veritabanı büyür.
Bağımlılıklar değişir.
Yeni altyapı eklenir.
Uygulama sürümleri değişir.
Yeni entegrasyonlar ortaya çıkar.
İzinler değişir.
Bu nedenle kurtarma stratejisi de sürekli olarak kontrol edilmelidir.
Teste basit bir senaryoyla başlanabilir: “Veritabanı kayboldu. En son yedekten geri yükleyelim.”
Daha sonra daha karmaşık senaryolara geçilebilir:
- “Uygulama sunucusu çalışmıyor.”
- “Üretim ortamının tamamı kullanılamıyor.”
- “Veriler şifrelendi.”
- “Altyapının birincil bölgesi çalışmıyor.”
- “Ana yöneticiye erişimimiz yok.”
Bu tür testlerin her biri, sistem normal çalışırken fark edilmeyen sorunları ortaya çıkarabilir.
Her uygulamanın gelişmiş bir disaster recovery çözümüne ihtiyacı var mı?
Hayır.
Bu da önemlidir.
Olası her senaryoya dayanıklı bir altyapı tasarlamak, orantısız derecede pahalı olabilir.
Dahili bir uygulamanın arızalanması bir saatlik aksaklığa yol açacaksa, birkaç bölgede active-active altyapısına ihtiyacımız olmayabilir. Ancak bir sistemin arızalanması satışların, üretimin, müşteri hizmetlerinin veya kritik bir iş sürecinin durması anlamına geliyorsa durum tamamen farklıdır.
Öncelikle arızanın iş üzerindeki etkisi belirlenmelidir.
Teknoloji seçimi bundan sonra yapılmalıdır.
Bu, farklı çözümlere yol açabilir:
Backup + restore
Daha az kritik sistemler için daha basit ve daha ucuz bir çözüm.
Warm standby
Yedek ortam kısmen hazırdır ve hızla devreye alınabilir.
Hot standby
Yedek ortam daha büyük ölçüde paralel çalışır ve yükü devralmaya hazırdır.
Active-active
İki ortam aynı anda trafiği işleyebilir ve tek bir arıza noktasına bağımlılığı azaltabilir.
Çözüm seçimi RTO, RPO, sistemin kritiklik düzeyi, kesinti maliyeti ve teknik olanaklara göre yapılmalıdır.
Kontrol listesi: Uygulamanız bir arızaya hazır mı?
Kendinize birkaç basit soru sormanızda fayda var.
1. Yedeğimiz var mı?
Bu yalnızca başlangıç.
2. Yedek, üretim ortamındaki bir arızaya karşı da koruma sağlayacak şekilde saklanıyor mu?
3. Hiç tam bir geri yükleme gerçekleştirdik mi?
4. Geri yükleme gerçekte ne kadar sürüyor?
5. RTO'yu biliyor muyuz?
6. RPO'yu biliyor muyuz?
7. Yalnızca verileri değil, uygulamayı ve yapılandırmasını da geri yükleyebilir miyiz?
8. Bir kurtarma prosedürümüz var mı?
9. Bu prosedürü birden fazla kişi uygulayabiliyor mu?
10. Failover'ı test ettik mi?
11. Yedek ortam güncel mi?
12. Sistemde yapılan son değişikliklerden sonra kurtarmayı yeniden test ettik mi?
Birkaç soruya “bilmiyorum” yanıtını veriyorsak disaster recovery stratejimizi gözden geçirmek için tam zamanı demektir.
En önemli test şudur: „Göster”
BT’de şunları söylemek çok kolaydır:
- „Yedeğimiz var.”
- „Yedek sunucumuz var.”
- „Bir prosedürümüz var.”
- „Felaket kurtarma planımız var.”
- Ancak sistem güvenliği yalnızca beyanlara dayanmamalıdır.
En önemli soru şudur: Sistemi geri yükleyebileceğinizi gösterin.
- Geri yüklemeyi başlatın.
- Süreyi ölçün.
- Verileri kontrol edin.
- Uygulamayı test edin.
- Failover gerçekleştirin.
- Prosedürü gözden geçirin.
- Önemli değişikliklerden sonra testi tekrarlayın.
Ancak o zaman kurtarma stratejisinin uygulamada test edildiği söylenebilir.
Yedekleme verileri korur. Kurtarma iş sürekliliğini sağlar
Sanırım en önemli fark bu.
Yedekleme şu soruya yanıt verir: „Bir kopyamız var mı?”
Felaket kurtarma ise çok daha zor bir soruya yanıt verir: „Bir arızadan sonra yeniden çalışmaya başlayabilir miyiz?”
Bu ikisinin arasında ise kurtarma mimarisinin tamamı yer alır: RPO, RTO, replikasyon, yedeklemeler, geri yükleme, failover, yapılandırma, prosedürler, sorumluluk ve düzenli testler.
İyi tasarlanmış bir sistem, arızanın hiç yaşanmayacağını varsaymaz. Bir gün arıza yaşanacağını ve ne yapılacağının bilinmesi gerektiğini varsayar.
Çünkü uygulamanın gerçek dayanıklılığı, hiç bozulmamasında değildir. Bir şeyler ters gittiğinde kuruluşun öngörülebilir, kontrollü ve iş gereksinimlerine uygun şekilde yeniden çalışmaya başlayabilmesindedir.
Sözlük
Felaket Kurtarma (DR) - ciddi bir arızanın ardından sistemlerin çalışmasını geri kazanmaya yönelik strateji ve prosedürler.
Yedekleme - daha sonra geri yüklenmek üzere hazırlanan veri kopyası.
Geri yükleme - verilerin veya sistemin yedekten geri yüklenmesi süreci.
RTO (Kurtarma Süresi Hedefi) - sistemin kurtarılması için kabul edilebilecek azami süre.
RPO (Kurtarma Noktası Hedefi) - zaman cinsinden ifade edilen, kabul edilebilir azami veri kaybı.
Failover - sistemin çalışmasının birincil ortamdan yedek ortama aktarılması.
Failback - arızanın nedeni giderildikten sonra sistemin çalışmasının birincil ortama geri alınması.
Kurtarma testi - sistemin belirlenen varsayımlara uygun şekilde gerçekten geri yüklenebileceğini doğrulamayı amaçlayan test.
Runbook - belirli bir arıza senaryosunda izlenecek adımlara ilişkin ayrıntılı talimat.
