Felaket kurtarma planı, bir işletmenin sunucu arızası, siber saldırı, yangın veya doğal afet gibi büyük bir kesinti durumunda verilerini ve sistemlerini önceden belirlenmiş adımlarla geri getireceğini tanımlayan yazılı bir plandır. En yaygın kullanılan çerçeve 3-2-1 kuralıdır: verinin en az 3 kopyası, 2 farklı ortamda, bunlardan 1'i de fiziksel olarak farklı bir konumda tutulur.
Bu yazıda 3-2-1 kuralını ve bir felaket kurtarma planının kapsamını anlatıyoruz; günlük yedekleme sürecinin nasıl işlediğini kurumsal yedekleme yazımızda, veri kaybı sonrası kurtarmanın mümkün olup olmadığını da veri kurtarma yazımızda ayrıca ele aldık.
Kuralın ilk basamağı, verinin en az 3 kopyasının bulunmasıdır: 1 asıl veri ve 2 yedek kopya. İkinci basamak, bu kopyaların 2 farklı ortamda (örneğin bir yerel disk ve bir bulut hizmeti) tutulmasıdır. Üçüncü basamak ise kopyalardan en az 1'inin, asıl verinin bulunduğu binadan fiziksel olarak farklı bir konumda saklanmasıdır — böylece tek bir olay tüm kopyaları aynı anda etkileyemez.
RTO (Recovery Time Objective), bir kesinti sonrası sistemlerin ne kadar sürede tekrar çalışır hale getirilmesinin hedeflendiğini; RPO (Recovery Point Objective) ise geri yüklenen verinin, kesinti anından ne kadar geriye giden bir zaman noktasını yansıtacağını tanımlar. Bu iki hedef, işletmenin ne kadar veri kaybını ve kesinti süresini kabul edilebilir bulduğuna göre kurum içinde birlikte belirlenir.
Hayır. Yedekleme, planın yalnızca bir bileşenidir; plan ayrıca bir kesinti anında kimin ne yapacağını, hangi sistemin öncelikli olarak geri getirileceğini ve iletişimin nasıl yürütüleceğini de tanımlar. Yedek verisi olsa bile bu veriyi kimin, hangi sırayla ve ne kadar sürede geri yükleyeceği belirsizse, kriz anında değerli zaman kaybedilir.
Kağıt üzerinde hazırlanmış ama hiç denenmemiş bir plan, gerçek bir kriz anında beklenmedik aksaklıklarla karşılaşabilir. Periyodik olarak yapılan tatbikatlar; planın eksik kaldığı noktaları, güncel olmayan iletişim bilgilerini veya süresi dolmuş erişim yetkilerini önceden ortaya çıkarır.
Felaket kurtarma planı yalnızca doğal afetleri değil; donanım arızası, fidye yazılımı saldırısı, yangın/su baskını ve insan hatasıyla yanlışlıkla silinen kritik veriler gibi çok daha sık karşılaşılan senaryoları da kapsar. Planın kapsamı, işletmenin gerçekte karşılaşabileceği riskler göz önünde bulundurularak belirlenir.
Evet. Felaket kurtarma planı yalnızca büyük kurumlara özgü bir kavram değildir; küçük bir işletme için bile hangi verinin kritik olduğunu, nereye yedeklendiğini ve bir kesinti anında ilk kimin aranacağını yazılı hale getirmek, kriz anındaki kararsızlığı büyük ölçüde azaltır.
Plan, işletmenin BT altyapısını bilen bir ekip veya dış hizmet sağlayıcı tarafından hazırlanmalı; ancak sahiplenilmesi yalnızca teknik ekiple sınırlı kalmamalıdır. Sistemler, kullanıcılar veya kritik veri değiştikçe planın da güncellenmesi gerekir, aksi halde plan zamanla gerçek durumu yansıtmayan bir belgeye dönüşür.
Yedekleme, verinin bir kopyasını almak ve bu kopyayı geri yükleyebilmektir; felaket kurtarma planı ise bu yedeği hangi öncelik sırasıyla, kim tarafından, ne kadar sürede geri getireceğini tanımlayan daha geniş bir çerçevedir. İyi bir yedekleme rutini, iyi bir felaket kurtarma planının yalnızca bir parçasıdır.
Fidye yazılımı saldırıları, klasik donanım arızasından farklı olarak yedeklerin de şifrelenmesi riskini taşır; bu nedenle plan, en azından bir yedek kopyanın değişmez (immutable) veya çevrimdışı tutulmasını özellikle içermelidir.
Techno Fusion'da: Kurumunuza özel bir felaket kurtarma planını, 3-2-1 kuralına uygun yedekleme mimarisiyle birlikte kuruyor, planı periyodik olarak sizinle birlikte test ediyoruz.
TF Bilişim ekibimiz, kurumunuzun kritik sistemlerini ve kabul edilebilir kesinti süresini keşif aşamasında belirliyor, buna uygun bir felaket kurtarma planı ve yedekleme mimarisi kuruyoruz. Eskişehir, İstanbul ve Elazığ'daki saha ekibimizle yerinde, bu üç ilin dışında kalan kurumsal projelerde ise randevulu keşif sonrası proje bazlı ilerliyoruz.