Felaket Kurtarma Merkezi: Yedekleme, Replikasyon ve İş Sürekliliği

Felaket kurtarma merkezi nedir?

Felaket kurtarma (disaster recovery, DR), kurumun bilgi sistemlerinin ciddi bir kesinti sonrasında kabul edilebilir sürede ve kabul edilebilir veri kaybıyla yeniden çalışır hale getirilmesini sağlayan plan, altyapı ve süreçlerin bütünüdür. Felaket kurtarma merkezi ise ana sistemlerin çalıştığı yerden farklı bir lokasyonda bulunan, kritik verilerin ve gerektiğinde sunucuların kopyalarının tutulduğu ikinci merkezdir. Bu merkez kurumun başka bir binası, bir veri merkezinde kiralanan alan ya da bulut altyapısı olabilir.

"Felaket" kelimesi akla deprem, sel ya da yangını getirir; bunlar Türkiye için gerçek risklerdir. Ancak pratikte kesintilerin çok daha sık görülen nedenleri vardır: fidye yazılımının sunucuları ve bağlı yedekleri şifrelemesi, depolama ünitesinin arızalanması, yanlışlıkla silinen veri, başarısız bir güncelleme, sistem odasında yaşanan su baskını ya da uzun süreli enerji kesintisi. İyi tasarlanmış bir felaket kurtarma yapısı bu senaryoların hepsine cevap verir.

Felaket kurtarma çözümleri özellikle şu kurumlar için kritiktir:

• Muhasebe, ERP, öğrenci ya da hasta bilgi sistemi gibi kesintiye tahammülü düşük uygulamaları kendi sunucularında çalıştıranlar,
• Tek bir binada, tek bir sistem odasında tüm verisini tutan işletmeler,
• Yedekleri olan ama bu yedeklerden hiç geri yükleme denemesi yapmamış kurumlar,
• Denetim, müşteri ya da sektörel düzenlemeler nedeniyle iş sürekliliği planı sunmak zorunda olan firmalar.

Yedekleme ile felaket kurtarma arasındaki fark

Yedekleme, verinin bir kopyasını almaktır. Felaket kurtarma ise o kopyadan, belirli bir sürede, sistemleri gerçekten ayağa kaldırabilmektir. Aradaki fark, kriz anında ortaya çıkar: yedek var ama hangi sunucuya geri yüklenecek? Sunucu da yandıysa yeni donanım ne zaman gelecek? Veri tabanı geri döndü ama uygulama hangi ayarlarla çalışıyordu? Kullanıcılar sisteme nereden bağlanacak? Felaket kurtarma planı bu soruların cevaplarını önceden hazırlar.

Planlamanın merkezinde iki ölçü vardır:

• RTO (Recovery Time Objective): Bir sistemin kesintiden sonra en geç ne kadar sürede yeniden çalışması gerektiği. Örneğin "muhasebe sistemi en geç dört saat içinde dönmeli".
• RPO (Recovery Point Objective): Kabul edilebilir en fazla veri kaybı süresi. "En fazla son bir saatlik veriyi kaybedebiliriz" demek, en az saatlik yedek ya da replikasyon gerektiği anlamına gelir.

RTO ve RPO küçüldükçe maliyet artar. Bu yüzden her sistem için aynı hedefi koymak yerine, sistemleri kritiklik seviyesine göre gruplamak en doğru yaklaşımdır.

Felaket kurtarma projesi nasıl yürütülür?

1. İş etki analizi: Hangi süreçler hangi sistemlere bağlı, bir saatlik, bir günlük, bir haftalık kesintinin kuruma etkisi ne olur? Bu görüşmeler BT ekibiyle değil, süreç sahipleriyle yapılır.
2. Risk değerlendirmesi: Lokasyonun deprem ve sel riski, enerji ve internet altyapısı, mevcut yedeklerin durumu ve fidye yazılımına karşı dayanıklılığı incelenir.
3. RTO / RPO hedeflerinin belirlenmesi: Her sistem için hedefler yönetimle birlikte kararlaştırılır.
4. Mimari tasarım: Yedekleme sıklığı, saklama süreleri, ikinci lokasyon (başka bina, veri merkezi ya da bulut), replikasyon yöntemi ve bant genişliği ihtiyacı belirlenir.
5. Kurulum: Yedekleme yazılımı, depolama, replikasyon ve gerekiyorsa ikinci merkezdeki sunucu ve ağ altyapısı kurulur.
6. Kurtarma prosedürlerinin yazılması: Hangi sistem, hangi sırayla, kim tarafından, hangi adımlarla ayağa kaldırılacak? Adım adım runbook'lar hazırlanır.
7. Tatbikat: Plan gerçek bir ortamda, üretimi etkilemeden test edilir; ölçülen kurtarma süreleri hedeflerle karşılaştırılır.
8. Gözden geçirme: Altyapı değiştikçe plan güncellenir, tatbikatlar düzenli aralıklarla tekrarlanır.

Hizmet kapsamı

Yedekleme stratejisi ve replikasyon

Yaygın olarak kabul gören 3-2-1 kuralı temel alınır: verinin en az üç kopyası, en az iki farklı ortamda, bunlardan biri farklı bir lokasyonda tutulur. Fidye yazılımı tehdidi nedeniyle buna en az bir değiştirilemez (immutable) ya da ağdan yalıtılmış kopya ve düzenli geri yükleme testi eklenir. Kritik sistemlerde günlük yedeğin ötesine geçilerek sanal sunucuların ikinci merkeze periyodik ya da sürekli replikasyonu kurulur. Veeam gibi yaygın yedekleme yazılımları, sanallaştırma platformlarının kendi replikasyon özellikleri ya da açık kaynak çözümler arasından kurumun altyapısına ve bütçesine uygun olan seçilir.

RTO / RPO hedeflerine göre tasarım

Her kurumun bir "ikinci veri merkezi"ne ihtiyacı yoktur. Bazı sistemler için ertesi gün geri yüklenebilen bir yedek yeterliyken, bazıları için dakikalar içinde devreye girebilecek hazır bir kopya gerekir. Tasarımı, sistemleri genellikle üç gruba ayırarak yaparız: dakikalar/saatler içinde dönmesi gerekenler, bir gün içinde dönmesi yeterli olanlar ve birkaç gün bekleyebilecekler. Bu sınıflandırma, gereksiz yatırımın önüne geçer.

Kurtarma tatbikatları

Test edilmemiş bir felaket kurtarma planı, bir varsayımdan ibarettir. Tatbikatlarda yedekten tam sunucu geri yükleme, ikinci merkezde sistemleri ayağa kaldırma, uygulamanın ve veri tabanının tutarlılığını doğrulama ve kullanıcı erişimini test etme adımları uygulanır. Her tatbikat sonunda ölçülen süreler, karşılaşılan sorunlar ve iyileştirme önerileri raporlanır.

İş sürekliliği planı

Felaket kurtarma teknik tarafı kapsar; iş sürekliliği planı ise "sistemler dönene kadar kurum nasıl çalışmaya devam edecek?" sorusunu cevaplar. Kriz ekibi ve iletişim zinciri, karar yetkileri, personele ve müşterilere yapılacak bilgilendirme, geçici çalışma yöntemleri ve tedarikçi iletişim bilgileri plana dahil edilir. Plan kısa, okunabilir ve kriz anında erişilebilir olmalıdır; yalnızca ana sunucuda duran bir plan, o sunucu çöktüğünde işe yaramaz. ISO 22301 gibi standartları referans alan kurumlarda planın yapısını bu çerçeveyle uyumlu hazırlarız.

Fidye yazılımına karşı kurtarma hazırlığı

Fidye yazılımı saldırılarında saldırganlar artık önce yedekleri hedef alıyor. Bu yüzden yedekleme altyapısının yönetim hesapları ana dizin hizmetinden ayrılır, iki faktörlü kimlik doğrulama kullanılır, yedek depolaması ana ağdan izole edilir ve en az bir kopya silinemez şekilde tutulur. Ağ tarafındaki önlemler için firewall hizmetlerimiz ile birlikte bölümlendirme yapılır.

Kriz anında erişim ve iletişim

Felaket senaryolarında sıkça unutulan konu, sistemler ikinci merkezde ayağa kalktıktan sonra kullanıcıların oraya nasıl ulaşacağıdır. DNS kayıtlarının yönlendirilmesi, VPN bağlantılarının ikinci merkeze açılması, kimlik doğrulama servisinin ikinci merkezde de çalışması ve dışarıya açık servislerin yeni adreslerine geçiş planlanmazsa, sunucular çalışır ama kimse bağlanamaz. Ayrıca e-posta sistemi de etkilendiyse ekibe ve müşterilere ulaşmak için alternatif iletişim kanalı önceden belirlenmelidir. Bu adımlar kurtarma prosedürüne yazılır ve tatbikatlarda mutlaka denenir.

Kimler için? Kullanım senaryoları

• Üniversite ve okullar: Öğrenci bilgi sistemi, muhasebe ve e-posta gibi kesintiye duyarlı sistemler için kampüs içi farklı binada ya da farklı şehirde ikinci kopya.
• Sağlık kuruluşları: Hasta bilgi sistemleri için kısa RTO hedefleri, yerinde hızlı geri dönüş ve uzakta ikinci kopya.
• Üretim firmaları: Üretim planlama ve ERP sistemlerinin kesintisinin üretim hattını durdurmaması için replikasyon.
• KOBİ'ler: Tek sunuculu yapılarda bile değiştirilemez bulut yedeği ve yazılı geri dönüş prosedürü ile büyük bir risk azaltılabilir. Başlangıç için büyük bütçe gerekmez; önemli olan doğru kurgulanmış ve test edilmiş bir yapıdır.
• Çok lokasyonlu firmalar: Şubelerden birinin ikinci merkez olarak kullanılması; merkez ile şube arasındaki bağlantı ve güvenlik kurgusunun replikasyon trafiğine göre boyutlandırılması.

Felaket kurtarma çözümü seçerken nelere dikkat edilmeli?

• İkinci lokasyon, ana merkezle aynı riski (aynı fay hattı, aynı sel bölgesi, aynı enerji altyapısı) paylaşıyor mu?
• Yedeklerden en az biri fidye yazılımının erişemeyeceği şekilde yalıtılmış mı?
• Kurtarma süreleri gerçekten ölçüldü mü, yoksa tahmin mi?
• Felaket anında sistemleri kim, hangi dokümana bakarak ayağa kaldıracak?
• Veri yurt dışındaki bir buluta gidiyorsa KVKK kapsamında yurt dışına aktarım değerlendirmesi yapıldı mı?

Aşağıdaki tablo, en sık değerlendirilen yaklaşımları karşılaştırıyor:

Çoğu kurum için en dengeli sonuç karma bir yapıdır: hızlı geri dönüş için yerinde bir yedek, bina kaybına karşı farklı lokasyonda ya da bulutta ikinci bir kopya ve en az bir değiştirilemez kopya.

Felaket kurtarma maliyeti nasıl belirlenir?

Maliyeti belirleyen en önemli unsur, hedeflediğiniz RTO ve RPO değerleridir. Bunun yanında:

• Korunacak sunucu ve veri miktarı, verinin günlük değişim oranı,
• İkinci lokasyonun türü (kurum binası, veri merkezi, bulut) ve aradaki bağlantı,
• Yedekleme ve replikasyon yazılımlarının lisans modeli,
• Saklama süreleri ve arşiv ihtiyacı,
• Tatbikat sıklığı ve sürekli yönetim kapsamı

teklifi doğrudan etkiler. İş etki analizi, bu kalemlerden hangisine ne kadar yatırım yapılması gerektiğini netleştirir.

Neden ASRİ TECH?

• Uygulamayı tanıyan ekip: Yazılım geliştirdiğimiz için yalnızca sunucuyu değil, uygulamanın ve veri tabanının tutarlı biçimde geri dönmesini de önemsiyoruz.
• Altyapı bütünlüğü: Felaket kurtarmayı sunucu ve sanallaştırma, veri tabanı hizmetleri ve ağ güvenliğiyle birlikte tasarlıyoruz.
• Kurum içi, bulut veya hibrit: Verinizin nerede duracağına siz karar verirsiniz; biz her senaryoda çalışırız.
• Tatbikat odaklı yaklaşım: Planı kâğıtta bırakmıyor, düzenli olarak test ediyoruz.
• Tek muhatap.

Mevcut yedekleme ve kurtarma hazırlığınızı birlikte değerlendirmek için felaket kurtarma için teklif isteyin.

Sık sorulan sorular

Felaket kurtarma merkezi nedir?

Ana sistemlerin bulunduğu yerden farklı bir lokasyonda, kritik veri ve sistemlerin kopyalarının tutulduğu ikinci merkezdir. Ana merkezde ciddi bir kesinti olduğunda sistemler bu merkezden ayağa kaldırılır. Bu merkez kurumun başka bir binası, bir veri merkezi ya da bulut olabilir.

RTO ve RPO nedir?

RTO, bir sistemin kesintiden sonra en geç ne kadar sürede yeniden çalışması gerektiğini; RPO ise kabul edilebilir en fazla veri kaybı süresini ifade eder. Bu iki değer küçüldükçe gereken altyapı ve maliyet artar.

Yedekleme ile felaket kurtarma arasındaki fark nedir?

Yedekleme verinin kopyasını almaktır. Felaket kurtarma ise bu kopyalardan, önceden belirlenmiş sürede ve sırayla sistemleri yeniden çalışır hale getirmeyi sağlayan altyapı, prosedür ve testlerin bütünüdür.

3-2-1 yedekleme kuralı nedir?

Verinin en az üç kopyasının, en az iki farklı ortamda tutulması ve bu kopyalardan birinin farklı bir lokasyonda bulunması prensibidir. Fidye yazılımlarına karşı buna en az bir değiştirilemez ya da çevrimdışı kopya eklenmesi önerilir.

Felaket kurtarma merkezi ana merkezden ne kadar uzakta olmalı?

Kesin bir mesafe kuralı yerine, ikinci lokasyonun ana merkezle aynı riskleri paylaşmaması esas alınır: farklı deprem ve sel riski, farklı enerji ve internet altyapısı gibi. Bazı kurumlar bunun için başka bir şehri ya da bulut bölgesini tercih eder.

Felaket kurtarma tatbikatı ne sıklıkla yapılmalı?

Kritik sistemlerde yılda en az bir kez kapsamlı tatbikat, daha sık aralıklarla da örnek geri yükleme testleri yapılması yaygın bir uygulamadır. Altyapıda büyük bir değişiklik olduğunda plan güncellenmeli ve yeniden test edilmelidir.

DRaaS (hizmet olarak felaket kurtarma) nedir?

Felaket kurtarma altyapısının bulut ya da veri merkezi sağlayıcısı üzerinden hizmet olarak alınmasıdır. İlk yatırımı azaltır; ancak veri konumu, KVKK kapsamında yurt dışına aktarım ve kurtarma süreleri sağlayıcı seçiminde mutlaka değerlendirilmelidir.

Küçük bir işletmenin felaket kurtarma planına ihtiyacı var mı?

Evet, ancak büyük bir ikinci merkeze değil. Farklı lokasyonda tutulan ve fidye yazılımından yalıtılmış bir yedek, düzenli geri yükleme testi ve kısa, yazılı bir geri dönüş prosedürü küçük işletmeler için büyük risk azaltır.