Felaket Kurtarma Planı Olmayan Şirketler İçin Uyarı

Şirketlerin büyük çoğunluğu yedekleme stratejisinin ne kadar kırık olduğunu, yalnızca bir sistem çöktüğünde keşfeder. O ana kadar “backup alıyoruz” cümlesi yeterli görünür. Backup nereye alınıyor, ne sıklıkla alınıyor, test edildi mi, kim geri yükleyecek, ne kadar sürede? Bu sorulara cevap veremeyen pek çok şirket var.

Bu yazı bir alarm değil, pratik bir kontrol listesidir. Felaket kurtarma planı kavramını netleştirelim, gerçekten işe yarayan bir strateji nasıl kurulur anlatalım.

RTO ve RPO: İki Kritik Kavram

Felaket kurtarma planlamasının iki temel metriği vardır. Bunları anlamadan ne hazırlık yapılır ne de doğru araçlar seçilir.

RTO — Recovery Time Objective (Kurtarma Süresi Hedefi)

Bir sistem kesintisi yaşandığında, sistemi tekrar ayağa kaldırmak için kabul edilebilir maksimum süre. Örneğin “RTO: 4 saat” demek, bir sorun yaşandığında 4 saat içinde sistemi çalışır hale getirmeyi taahhüt etmek anlamına gelir.

Pratikte RTO şu soruya cevap verir: “Sistem kaç saat çevrimdışı kalabilir?” Bir e-ticaret sitesi için bu tolerans çok küçüktür. Dahili bir raporlama aracı için daha geniş olabilir.

RPO — Recovery Point Objective (Kurtarma Noktası Hedefi)

Bir felaket durumunda kabul edilebilir maksimum veri kaybı miktarı, zaman cinsinden ifade edilir. “RPO: 1 saat” demek, en kötü senaryoda son 1 saatlik veriyi kaybetmeyi kabul etmek anlamına gelir.

Pratikte RPO, backup sıklığını belirler. Eğer RPO’nuz 1 saatse, yedeklerinizin en az her saat alınması gerekir.

Bu iki metriği belirlemeden felaket kurtarma planı yazmak mümkün değildir. Çünkü RTO ve RPO, hangi teknoloji ve mimarinin seçileceğini doğrudan belirler.

En Yaygın Felaket Kurtarma Hataları

”Backup Alıyoruz” Ama Test Etmiyoruz

Bu, en tehlikeli yanılsamadır. Backup’ın var olması geri yüklenebileceği anlamına gelmez. Backup sürecinde bir hata olmuş olabilir. Geri yükleme prosedürü belgelenmemiş olabilir. Kısmen bozulmuş bir yedek, geri yükleme sırasında hata verebilir.

Backup’ı gerçekten test etmeden “yedeğimiz var” demek, yangın tatbikatı yapılmamış bir bina için “yangın söndürücümüz var” demek gibidir.

Yedekler Aynı Sistemde veya Aynı Region’da

Birincil veri tabanınız bir AWS region’ında, yedekleriniz de aynı region’da ise o region’ı etkileyen bir kesinti ikisini birden çökertir. Yedekler, koruduğu sistemden fiziksel ve lojistik olarak ayrı tutulmalıdır. Farklı bir cloud region’ı veya farklı bir provider ideal seçeneklerdir.

Runbook Yok — “Benim Bildiğim” Bir Plan

Kriz anında en kötü zaman, kimin ne yapacağını tartışmaktır. Eğer geri yükleme prosedürü yalnızca bir ya da iki kişinin kafasındaysa, o kişiler tatildeyken veya stres altındayken sistem güvende değildir.

Bir runbook basit bir belgedir: adım adım kim ne yapar, hangi araçlar kullanılır, hangi hesap bilgilerine nereden erişilir, kim kimi arar. Bir felaket anında bu belgeyi açıp takip edebilmek saatleri kurtarır.

Tek Backup Stratejisi — Tam Yedek, Seyrek Zamanlama

Günlük tam yedek almak yeterli gibi görünür, ama bu yaklaşımda sınırlar var. Büyük veri setlerinde tam yedek alma işlemi uzun sürer ve sistemi yavaşlatabilir. Daha sık yedeklemek için artımlı (incremental) backup stratejilerine geçmek gerekebilir.

Pratik Felaket Kurtarma Planı Nasıl Kurulur?

Adım 1: RTO ve RPO Tanımlayın

Teknik değil, iş kararıdır. “Sistemimiz kaç saat kapalı kalabilir, kaç saatlik veriyi kaybedebiliriz?” sorularını iş tarafıyla birlikte yanıtlayın. Farklı sistemler için farklı RTO/RPO değerleri olabilir.

Adım 2: Backup’ı Otomatize Edin

Manuel backup güvenilir değildir. Zamanlayıcı tabanlı otomatik yedeklemeler kurun. AWS RDS automated backups, S3 versioning, veritabanı dump’ları için cron job’lar — hangi araç kullanılırsa kullanılsın, insan müdahalesi olmadan çalışmalıdır.

Adım 3: Farklı Region/Provider’a Kopyalayın

Yedeklerinizi otomatik olarak en az bir farklı konuma kopyalayın. AWS S3 Cross-Region Replication, GCP Multi-Region Storage veya başka bir provider’a aktarım bunu sağlar. Bir region çökse bile yedekleriniz erişilebilir olmalıdır.

Adım 4: Runbook Yazın

Bir geri yükleme prosedürü belgelemek için bir sistem kesintisi beklemeyin. Şu soruları cevaplayın: Hangi sistem çöktüğünde kim uyarılır? Geri yükleme kararını kim verir? Adımlar nelerdir? Hangi araçlara, hangi kimlik bilgilerine ihtiyaç duyulur? Bu belgeyi teknik ekibin erişebileceği bir yerde tutun.

Adım 5: Üç Ayda Bir Test Edin

Yılda en az 2-4 kez DR tatbikatı yapın. Bu bir prodüksiyon kesintisi olmak zorunda değildir — izole bir ortamda geri yükleme simülasyonu yeterlidir. Tatbikat sırasında ortaya çıkan eksiklikler, gerçek bir kriz anında çok daha az stres altında çözülür.

Gerçekçi Bir Değerlendirme

Felaket kurtarma planı yapmak için “büyük” bir şirket olmak gerekmez. Aksine, kurumsal altyapısı ve dedicated IT ekibi olmayan küçük ve orta ölçekli şirketler bu riske karşı daha savunmasızdır.

Bir sistem kesintisi her şirkette yaşanır — soru ne zaman yaşanacağı değil, o an nasıl hazırlıklı olacağınızdır. “Bize olmaz” düşüncesi planlamanın en büyük düşmanıdır.

---

Felaket kurtarma stratejinizi gözden geçirmek veya sıfırdan oluşturmak istiyorsanız, ücretsiz bir keşif görüşmesinde mevcut durumu birlikte değerlendirebiliriz. RTO/RPO tanımından runbook yazımına kadar sizi yönlendirebiliriz.