KOBİ'ler İçin Yedekleme ve Felaket Kurtarma Rehberi

Yedek almak yeterli değil; geri yüklenebilir olması gerekir. KOBİ'ler için pratik yedekleme ve felaket kurtarma stratejisi.

9 Temmuz 2026 · 7 dk okuma

Bir sunucu çöktüğünde, bir dizüstü bilgisayar çalındığında veya fidye yazılımı tüm dosya sunucusunu şifrelediğinde, işletmenin ayakta kalıp kalmayacağını belirleyen tek şey genellikle yedekleme ve felaket kurtarma stratejisinin ne kadar sağlam kurulduğudur. Çoğu KOBİ "yedek alıyoruz" der, ama bu genellikle bir harici diske kopyalanan dosyalar veya bulut senkronizasyonu kadar basit bir önlemden ibarettir; sorun, kriz anında bu yedeğin gerçekten işe yarayıp yaramadığının hiç test edilmemiş olmasıdır. Bu rehber, yedekleme ve felaket kurtarmayı ürün seçimi değil bir strateji meselesi olarak ele alıyor.

3-2-1 Kuralı ve Genişletilmiş Hali: 3-2-1-1-0

Yedekleme dünyasının en eski ama hâlâ en geçerli kuralı 3-2-1'dir: verinin en az 3 kopyası bulunmalı, bu kopyalar 2 farklı ortamda (örneğin yerel disk + bulut, ya da disk + teyp) tutulmalı ve bunlardan 1 tanesi fiziksel olarak farklı bir konumda saklanmalıdır. Bir yangın, sel veya hırsızlık tüm ofisi etkilese bile, konum dışındaki kopya kurtarmayı mümkün kılar.

Son yıllarda bu kural, fidye yazılımı tehdidine karşı 3-2-1-1-0 şeklinde genişletildi:

• 1 (ek): Kopyalardan en az biri değiştirilemez (immutable) veya çevrimdışı (air-gapped) olmalı. Yani saldırgan ağa sızsa bile o kopyaya dokunamamalı.
• 0: Yedeklerde sıfır hata anlamına gelir; düzenli test ve doğrulama ile yedeğin bozuk veya eksik olmadığından emin olunmalı.

Neden Basit Bir Yedek Fidye Yazılımına Karşı Yetmiyor

Modern fidye yazılımı saldırıları artık sadece dosyaları şifrelemekle kalmıyor; ağa sızdıktan sonra günlerce, bazen haftalarca sistemde gizlenip önce yedekleme sunucularını, yedekleme ajanlarını ve bulut senkronizasyon hesaplarını tespit edip siliyor veya şifreliyor. Sürekli bağlı kalan, aynı Windows domain kimlik bilgileriyle erişilebilen bir yedek, saldırgan için normal bir dosya sunucusundan farksızdır. Bu yüzden en az bir kopyanın ağdan fiziksel veya mantıksal olarak izole (air-gapped) ya da belirli bir süre boyunca kimsenin (yöneticiler dahil) değiştiremeyeceği şekilde kilitli (immutable) olması kritik önem taşır. Bulut yedekleme çözümlerinin çoğu artık bu tür değiştirilemez depolama seçeneklerini sunuyor; önemli olan bunu varsayılan ayar olarak değil, bilinçli bir yapılandırma kararı olarak devreye almak.

RTO ve RPO: Kurtarmanın İki Temel Ölçütü

Felaket kurtarma planlaması iki basit ama kritik soruya dayanır:

RTO (Recovery Time Objective): Ne Kadar Sürede Ayağa Kalkarız?

RTO, bir sistemin çökmesinden yeniden çalışır hale gelmesine kadar kabul edilebilir maksimum süredir. Muhasebe sisteminizin 4 saat kapalı kalması tolere edilebilir mi, yoksa e-ticaret siteniz 15 dakikadan fazla duramaz mı? Her sistem için ayrı ayrı belirlenmeli.

RPO (Recovery Point Objective): Ne Kadar Veri Kaybını Göze Alabiliriz?

RPO, bir arıza anında kabul edilebilir maksimum veri kaybı süresidir. Günde bir kez gece yarısı alınan yedekle çalışıyorsanız, RPO'nuz 24 saattir; öğleden sonra bir çökme yaşarsanız o günkü tüm işlemleri kaybedersiniz. Kritik sistemler için RPO'yu saatlere, hatta dakikalara indirmek gerekebilir; bu da yedekleme sıklığını doğrudan belirler.

RTO ve RPO hedefleri ne kadar sıkı olursa, çözüm o kadar maliyetli olur. Bu yüzden her sistem için gerçekçi hedefler belirlemek, her şeyi "en yüksek seviyede" korumaya çalışmaktan çok daha verimlidir.

Yedekleri Test Etmeden Yedek Almanın Anlamı Yok

Yedekleme yazılımının "başarılı" raporu vermesi, verinin gerçekten geri yüklenebilir olduğu anlamına gelmez. Bozuk dosyalar, eksik veritabanı tutarlılığı veya yanlış yapılandırılmış zamanlayıcılar yıllarca fark edilmeden kalabilir; sorun ancak gerçek bir kurtarma anında ortaya çıkar. Bu yüzden:

• Kritik sistemler için en az üç ayda bir, tam bir geri yükleme testi yapılmalı.
• Test, sadece dosyanın açılabildiğini değil, uygulamanın ve veritabanının tutarlı şekilde çalıştığını doğrulamalı.
• Test sonuçları kayıt altına alınmalı; böylece hangi sistemin ne kadar sürede geri yüklendiği bilinir ve RTO hedefleriyle karşılaştırılabilir.

Test edilmemiş bir yedek, aslında bir varsayımdır, garanti değildir.

Bulut, Yerinde (On-Prem) veya Hibrit: Doğru Model Nasıl Seçilir

Hiçbir model tek başına "en doğrusu" değildir; işletmenin veri hacmi, internet bant genişliği ve bütçesine göre değişir.

Yerinde (on-prem) yedekleme, hızlı geri yükleme sağlar çünkü veri yerel ağdadır, ancak ofisi etkileyen bir felakette (yangın, sel, hırsızlık) tek başına yeterli koruma sunmaz.

Bulut yedekleme, coğrafi olarak izole bir kopya sağlar ve donanım yatırımı gerektirmez, ancak büyük veri hacimlerinde geri yükleme süresi internet hızına bağlı olarak uzayabilir.

Hibrit model çoğu KOBİ için en dengeli seçenektir: günlük operasyonlar için yerel bir kopya hızlı erişim sağlar, buluttaki kopya ise hem coğrafi izolasyon hem de fidye yazılımına karşı ek bir güvenlik katmanı sunar. Bant genişliği kısıtlıysa, önce en kritik sistemleri buluta taşıyıp geri kalanı yerinde tutmak makul bir orta yol olabilir.

Basit Bir Felaket Kurtarma Planı: Nelerin Yazılı Olması Gerekir

Yedekleme bir teknik önlem, felaket kurtarma planı ise bu önlemin krizde nasıl devreye gireceğini anlatan bir eylem planıdır. Asgari olarak şunları içermeli:

1. Sistem önceliklendirmesi: Hangi sistem önce ayağa kalkacak? E-posta mı, muhasebe mi, üretim yazılımı mı? Öncelik sırası önceden belirlenmeli, kriz anında tartışılmamalı.
2. Sorumluluk dağılımı: Kim yedekten geri yükleme yapacak, kim müşterileri bilgilendirecek, kim tedarikçilerle iletişime geçecek? İsimler ve yedek kişiler net olmalı.
3. İletişim planı: Ana BT sorumlusuna ulaşılamazsa kim aranacak? İletişim bilgileri, sadece etkilenen sistemde değil ayrı bir yerde de saklanmalı.
4. Geri yükleme adımları: Hangi yedekten, hangi sıra ile, hangi ortama geri yükleme yapılacağı adım adım yazılı olmalı.
5. Yıllık tatbikat: Plan kâğıt üzerinde kalmamalı; yılda en az bir kez gerçek bir senaryo üzerinden tatbik edilmeli.

Kriz anında doğaçlama, kayıp zaman ve büyüyen hasar demektir. Yazılı ve test edilmiş bir plan, kurtarma süresini saatler mertebesinde kısaltabilir.

Sonuç

Yedekleme ve felaket kurtarma, bir kerelik kurulum değil, sürekli bakım isteyen bir disiplindir. 3-2-1-1-0 kuralını uygulamak, RTO ve RPO hedeflerini sistem bazında netleştirmek, yedekleri düzenli test etmek ve yazılı bir kurtarma planına sahip olmak, bir fidye yazılımı saldırısı veya donanım arızası sonrasında işin saatler içinde toparlanmasıyla günler süren kesinti arasındaki farkı yaratır.

4gen olarak, Trend Micro Vision One ve Worry-Free Business Security çözümleriyle uç nokta ve ağ tarafını korurken, KOBİ'lere yedekleme mimarisi kurulumu, immutable depolama yapılandırması ve felaket kurtarma planı hazırlığı konusunda da danışmanlık veriyoruz. Mevcut yedekleme altyapınızı birlikte gözden geçirmek isterseniz bize ulaşabilirsiniz.