Muhasebe ekibi ayı kapatmaya çalışırken ERP’ye erişim aniden kesiliyor. Sunucu odasındaki bir disk arızası mı, yoksa fidye yazılımı mı olduğu ilk yarım saat belli olmuyor. Telefon trafiği artıyor, sevkiyat departmanı sipariş durumunu göremiyor, satış ekibi teklif hazırlayamıyor. Bu senaryoyu yaşayan işletmelerin ortak sorusu aynı: “Son yedeğimiz ne zaman alındı, ve sistemi kaç saatte geri getirebiliriz?”
Bu iki soru, felaket kurtarma (disaster recovery) planlamasının özünü oluşturuyor. Yedekleme dosyasının var olması yetmez — hangi veri kaybının kabul edilebilir olduğu ve sistemin ne kadar sürede yeniden ayakta olması gerektiği önceden tanımlanmamışsa, kriz anında karar vermek panik halinde yapılır. Bu yazıda ERP özelinde felaket kurtarma ve iş sürekliliğinin temel kavramlarını, yedekleme stratejisinin pratik adımlarını ve bulut altyapısının bu denklemi nasıl değiştirdiğini ele alıyoruz.
İş Sürekliliği ile Felaket Kurtarma Aynı Şey Değil
İki terim sıkça birbirinin yerine kullanılıyor ama kapsamları farklı.
İş sürekliliği (business continuity) daha geniş bir çerçeve: bir kesinti sırasında kritik iş fonksiyonlarının nasıl devam edeceğini tarif eder — hangi süreç manuel yürütülecek, hangi ekip kim tarafından yedeklenecek, müşteriye nasıl bilgi verilecek gibi sorulara cevap verir. Felaket kurtarma (disaster recovery) ise bunun teknik alt kümesi: sistemlerin, verinin ve altyapının nasıl geri getirileceğine odaklanır.
ERP söz konusu olduğunda ikisi iç içe geçer. Sistem çökerken satış ekibinin telefonla sipariş alıp sonradan sisteme girmesi bir iş sürekliliği kararıdır; verinin hangi zaman noktasından geri yükleneceği ise felaket kurtarma kararıdır. Plan yazarken ikisini ayrı ayrı düşünmek, kriz anında hangi ekibin ne yapacağını netleştirir.
RPO ve RTO: Planın Omurgasını Oluşturan İki Sayı
Felaket kurtarma planlamasının merkezinde iki hedef metrik var:
| Metrik | Ne Sorar | Örnek Anlamı |
|---|---|---|
| RPO (Recovery Point Objective) | Ne kadarlık veri kaybını göze alabiliriz? | RPO 1 saat ise, en kötü ihtimalle son 1 saatlik işlem tekrar girilmeli |
| RTO (Recovery Time Objective) | Sistem ne kadar sürede yeniden çalışır hale gelmeli? | RTO 4 saat ise, kesintiden 4 saat sonra ERP’nin ayakta olması hedeflenir |
Bu iki sayı soyut değil; doğrudan maliyetle bağlantılı. RPO’yu sıfıra, RTO’yu dakikalara indirmek teknik olarak mümkün ama bunun bedeli var — sürekli veri çoğaltma (replikasyon), yedek altyapı, otomatik yük devretme mekanizmaları gerektirir. Bir üretim işletmesinde stok ve sevkiyat verisinin RPO’su ile arşivlenmiş yıllar öncesine ait raporların RPO’su aynı olmak zorunda değil. Kritik sorulardan biri şu: hangi modülün, hangi veri setinin kesintisi işletmeyi gerçekten durdurur? Plan, bu önceliklendirmeyle başlamalı; her şeye aynı sıkılıkta hedef koymak bütçeyi gereksiz şişirir.
Yedekleme Stratejisinde 3-2-1 Yaklaşımı
Yedekleme sıklığından önce, yedeğin kendisinin güvenilir olması gerekiyor. IT sektöründe uzun süredir kullanılan 3-2-1 yaklaşımı bunun için pratik bir çerçeve sunuyor:
- 3 kopya: Üretim verisinin kendisi dahil en az üç kopya bulunur.
- 2 farklı ortam: Kopyalar aynı diskte veya aynı sunucuda tutulmaz; en az iki farklı depolama türü/lokasyonu kullanılır.
- 1 kopya uzakta (off-site): Fiziksel olarak farklı bir lokasyonda — yangın, su baskını, yerel siber saldırı gibi tek noktadan etkileyen riskleri bertaraf etmek için.
Bunun ERP’deki pratik karşılığı: yalnızca “yedek alınıyor” demek yeterli değil, o yedeğin düzenli olarak geri yükleme testinden geçtiğinden emin olmak gerekiyor. Birçok işletme yedekleme işleminin çalıştığını görür ama geri yükleme adımını hiç denemez; sorun tam da kriz anında ortaya çıkar. Yılda en az bir kez, gerçek bir geri yükleme tatbikatı yapılması — RPO/RTO hedeflerinin kağıt üzerinde değil pratikte doğrulanması anlamına gelir.
Bulut Altyapısının Felaket Kurtarmadaki Rolü
Yerinde (on-premise) kurulan bir ERP’de felaket kurtarma sorumluluğu tamamen işletmenin IT ekibine düşer: yedek sunucu, yedek lokasyon, otomasyon scripti, izleme — hepsi kurulup bakımı yapılmalı. Bulut tabanlı bir ERP’de bu yükün önemli kısmı altyapı sağlayıcısına kayar.
Qera ERP, Microsoft Azure altyapısında çalışır. Azure’ın coğrafi olarak yedekli depolama (geo-redundant storage) seçenekleri, veriyi farklı veri merkezlerine otomatik olarak çoğaltma imkanı sunar — yani “1 kopya uzakta” ilkesi, işletmenin kendi başına kurması gereken bir proje olmaktan çıkar, altyapının bir parçası haline gelir. Bunun pratik karşılığı: donanım arızası, yerel kesinti ya da bölgesel bir sorun yaşandığında kurtarma süreci tek bir sunucunun onarılmasını beklemeye bağlı kalmaz.
Tek platform mimarisinin de burada gözden kaçan bir katkısı var. ERP, CRM ve raporlama ayrı sistemlerde çalıştığında felaket anında hangi sistemin önce ayağa kalkacağı, veriler arasındaki tutarlılığın nasıl sağlanacağı ayrı bir problem oluşturur. Tek omurgada birleşik çalışan bir yapıda bu koordinasyon yükü büyük ölçüde ortadan kalkar.
KVKK ve Veri İhlali Bildirimi: Felaket Kurtarma ile Kesişen Nokta
Felaket kurtarma yalnızca teknik bir konu değil; kişisel veri içeren bir kesinti aynı zamanda KVKK kapsamında bir “veri ihlali” sayılabilir. Türkiye’de veri sorumlusu, bir ihlali öğrendiği andan itibaren gecikmeksizin ve en geç 72 saat içinde Kişisel Verileri Koruma Kurulu’na bildirim yapmakla yükümlü. Bu süre hafta sonlarını da kapsıyor ve başlangıç noktası ihlalin fiilen gerçekleştiği an değil, öğrenildiği an.
Bu, felaket kurtarma planına doğrudan bir gereklilik ekliyor: olay tespit edildiğinde hangi ekibin hangi sırayla bilgilendirileceği, bildirim formunun kim tarafından hazırlanacağı önceden netleşmemişse, 72 saatlik pencere teknik kurtarma çabasıyla birlikte hızla daralır. Güncel ceza tutarları ve prosedür detayları için mali müşavirinizle veya doğrudan KVKK Kurumu’nun güncel duyurularıyla teyitleşmenizi öneririz — bu alan zaman zaman güncellenen bir mevzuat konusu.
Qera’daki KVKK, şifreleme ve veri lokasyonu yaklaşımını daha ayrıntılı incelemek isteyenler ilgili yazıya bakabilir.
Felaket Kurtarma Planı İçin Kontrol Listesi
Bir planı sıfırdan kurarken ya da mevcut planı gözden geçirirken sorulacak sorular:
- Kritik modüller (satış, stok, finans) için RPO/RTO hedefleri ayrı ayrı tanımlandı mı?
- Yedekler 3-2-1 ilkesine uygun mu; en az bir kopya farklı bir lokasyonda mı?
- Son geri yükleme testi ne zaman yapıldı, sonuç belgelendi mi?
- Kesinti anında kimin karar vereceği, kimin müşteriyi bilgilendireceği net mi?
- KVKK kapsamında veri ihlali bildirim sorumlusu belirlendi mi?
- Sistem tedarikçisinin (bulut sağlayıcı dahil) kendi felaket kurtarma taahhütleri ve SLA’sı biliniyor mu?
Bu listeyi yılda bir kez değil, önemli bir sistem değişikliğinden (yeni modül, yeni entegrasyon, tedarikçi değişimi) sonra da tekrar gözden geçirmek gerekiyor — plan, ERP kurulduğu günün fotoğrafı değil, canlı bir doküman olmalı.
Sistem seçimi aşamasındaysanız ve mevcut yapınızın felaket kurtarma açısından yeterliliğini değerlendirmek istiyorsanız, Qera ERP ekibinden ücretsiz bir demo talep ederek altyapı ve süreklilik yaklaşımını birebir görüşebilirsiniz.
Sıkça Sorulan Sorular
RPO ve RTO arasındaki fark nedir?
RPO, kabul edilebilir veri kaybı süresini (yedekleme sıklığıyla bağlantılı); RTO ise sistemin yeniden çalışır hale gelmesi için hedeflenen süreyi ifade eder. İkisi birlikte felaket kurtarma planının teknik hedeflerini oluşturur.
3-2-1 yedekleme kuralı nedir?
Verinin en az 3 kopyasının, en az 2 farklı ortamda tutulması ve bunlardan en az 1’inin fiziksel olarak farklı bir lokasyonda (off-site) bulunması ilkesidir. Tek noktadan etkileyen risklere (yangın, yerel siber saldırı) karşı koruma sağlar.
Bulut ERP felaket kurtarmayı otomatik olarak çözer mi?
Tamamen değil; altyapı tarafındaki coğrafi yedekleme ve çoğaltma yükünü büyük ölçüde sağlayıcıya (örneğin Azure) devreder, ama işletme tarafında hâlâ RPO/RTO hedeflerinin tanımlanması, geri yükleme testlerinin yapılması ve kriz iletişim planının hazır olması gerekir.
KVKK veri ihlali bildirimi kaç saat içinde yapılmalı?
Veri sorumlusu, ihlali öğrendiği andan itibaren gecikmeksizin ve en geç 72 saat içinde Kişisel Verileri Koruma Kurulu’na bildirim yapmakla yükümlüdür. Güncel prosedür ve yaptırımlar için KVKK Kurumu’nun güncel duyurularını veya hukuk danışmanınızı takip etmeniz önerilir.
Yedeklerin çalıştığından nasıl emin olunur?
Yedekleme işleminin başarıyla tamamlandığını görmek yeterli değildir; düzenli aralıklarla (örneğin yılda bir) gerçek bir geri yükleme tatbikatı yapılmalı ve sonuç belgelenmelidir. Aksi halde sorun ancak gerçek bir kriz anında fark edilir.
Felaket kurtarma planı kaç modülü kapsamalı?
Tüm ERP modüllerini aynı sıkılıkta hedeflemek gerekmez. Öncelik, kesintisi işletmeyi doğrudan durduran modüllere (örneğin satış, stok, finans) verilmeli; daha az kritik alanlar için daha geniş RPO/RTO hedefleri kabul edilebilir.
