Ağ Verimliliği

Yedekleme ve Felaket Kurtarma: Hayatta Kalma Planı

Data Plus · Süreklilik & Güvenlik

Verileriniz yedekli olabilir, ama bir felaket sonrası tüm sistemi geri getirebilir misiniz? Yedekleme verileri korur, felaket kurtarma ise tüm sistemi ayağa kaldırır. Bu rehberde 3-2-1 kuralını, RTO/RPO’yu, altyapı yedeklemeyi ve yedek testinin neden kritik olduğunu anlatıyoruz.

İki kavram, bir amaç

“Verilerimiz yedekli” demek, çoğu işletmenin rahatladığı bir cümledir. Ama yedekleme, felaket karşısında hayatta kalmanın sadece bir parçasıdır. İki kavramı ayırmak önemlidir: yedekleme, verilerin kopyasını almaktır; felaket kurtarma ise bir felaket sonrası tüm sistemi — veri, altyapı, işleyiş — yeniden ayağa kaldırma planının bütünüdür. Yedekleme, felaket kurtarmanın temel taşıdır ama tek başına yeterli değildir. Bu rehberde her ikisini ve fiziksel altyapıyla ilişkisini anlatıyoruz. Yedekli altyapı için Sunucu Odası Tasarımı yazımıza bakabilirsiniz.

3-2-1 YEDEKLEME KURALI3 KOPYAorijinal + 2 yedek2 ORTAMdisk + bulut/teyp1 OFF-SITEtesis dışıtek bir olay tüm kopyaları yok edemez
Çoklu kopya Tesis dışı

3-2-1 kuralı

Yedeklemenin altın standardı 3-2-1 kuralıdır ve basit ama güçlü bir mantığa dayanır: 3 kopya (orijinal + 2 yedek), 2 farklı ortam (örneğin disk + bulut), 1 tesis dışı (off-site). Bu kuralın amacı, tek bir olayın tüm kopyaları yok etmesini önlemektir. Düşünün: tüm yedekler aynı odadaysa, bir yangın hepsini yok eder. Aynı diskteyse, bir disk arızası hepsini götürür. 3-2-1 kuralı, kopyaları farklı ortamlara ve yerlere dağıtarak bu riski ortadan kaldırır. Tesis dışı kopya özellikle kritiktir — yangın, sel veya hırsızlık tüm tesisi etkilese bile, dışarıdaki kopya hayatta kalır.

Hangi felaketlere karşı?

Felaket kurtarma planı yaparken, neye karşı hazırlandığımızı netleştirmek faydalı. “Felaket” sadece deprem veya yangın gibi büyük olaylar değildir; çok daha sık karşılaşılan, küçük ama yıkıcı olaylar da bu kapsama girer:

  • Donanım arızası: En yaygın — bir disk, switch veya sunucu çöker.
  • İnsan hatası: Yanlışlıkla silinen veri, hatalı yapılandırma.
  • Siber saldırı: Fidye yazılımı (ransomware), veri şifreleme/silme.
  • Güç ve altyapı: Uzun elektrik kesintisi, su baskını, yangın.
  • Doğal afet: Deprem, sel — tüm tesisi etkileyen olaylar.

Dikkat çekici nokta: en sık felaketler büyük afetler değil, donanım arızası ve insan hatasıdır. Bir çalışanın yanlışlıkla kritik bir klasörü silmesi veya bir diskin çökmesi, deprem kadar nadir değildir — ve iyi bir yedekleme planı, bunların hepsine karşı korur. Özellikle fidye yazılımı saldırıları son yıllarda çok yaygınlaştı; bu saldırılarda tek kurtuluş, saldırıdan etkilenmemiş (ideal olarak çevrimdışı/off-site) bir yedektir. Bu yüzden 3-2-1 kuralındaki “tesis dışı” kopya, sadece yangına değil, fidye saldırısına karşı da hayati bir savunmadır. İyi bir plan, bu tehdit yelpazesinin tamamını göz önünde bulundurur ve her birine karşı bir kurtarma yolu sunar.

Sadece veri değil, altyapı da

Yedekleme denince akla hep dosyalar ve veritabanları gelir. Ama eksiksiz bir kurtarma için ağ altyapısının kendisi de yedeklenmelidir:

  • Cihaz yapılandırmaları: Switch, firewall, router ayarları.
  • Ağ şemaları: Fiziksel ve mantıksal dokümantasyon.
  • IP planı ve VLAN yapısı: Ağın mantıksal kurgusu.
  • Lisans ve erişim bilgileri: Sistemleri yeniden kurmak için gerekenler.

Neden? Çünkü bir switch arızalandığında, yeni cihazı sıfırdan yapılandırmak saatler alır — ama yapılandırma yedeği varsa, dakikalar içinde geri yüklenir. Ağ dokümantasyonu için Mantıksal vs Fiziksel Ağ Şeması yazımıza bakın.

RTO ve RPO: planın temeli

Felaket kurtarma planı iki temel hedefe dayanır:

MetrikSoruBelirler
RTONe kadar sürede geri gelmeli?Kurtarma hızı yatırımı
RPONe kadar veri kaybı kabul edilebilir?Yedekleme sıklığı

RTO (Recovery Time Objective), bir felaket sonrası sistemin ne kadar sürede geri gelmesi gerektiğidir — saatler mi, dakikalar mı? RPO (Recovery Point Objective), ne kadar veri kaybının kabul edilebilir olduğudur — son bir saatin verisi mi, son bir günün mü? Bu iki hedef, planın ne kadar kapsamlı (ve maliyetli) olması gerektiğini belirler. Çok kısa RTO/RPO, daha fazla yatırım gerektirir; her işletme kendi kritikliğine göre bu dengeyi kurar.

Test edilmeyen yedek, yedek değildir

Felaket kurtarmanın en sık ihmal edilen ama en kritik kuralı budur: test edilmemiş bir yedek, yedek sayılmaz. Çünkü bir yedeğin var olması, onun gerçekten çalıştığı anlamına gelmez. Yedekleme süreci sessizce bozulmuş olabilir, dosyalar bozuk olabilir, geri yükleme prosedürü eksik olabilir. Bunu öğrenmenin en kötü zamanı, gerçek bir felaket anıdır — “yedeğimiz vardı ama geri yüklenemedi” cümlesi, birçok işletmenin sonunu getirmiştir. Bu yüzden yedekler düzenli olarak test edilmelidir: gerçekten geri yüklenebiliyorlar mı, ne kadar sürüyor, tüm veri sağlam mı? Düzenli geri yükleme testleri, yedeklerin ve kurtarma planının gerçekten işe yaradığını doğrulayan tek yoldur.

Fiziksel altyapının rolü

Felaket kurtarma sadece yazılım ve veri meselesi değildir; fiziksel altyapı da kritik rol oynar. İyi tasarlanmış bir fiziksel altyapı, bazı felaketleri baştan önler ve diğerlerinden kurtarmayı hızlandırır. Yedekli kablolama ve ayrı güç yolları, tek bir arızanın tüm sistemi durdurmasını engeller. Sağlam bir sunucu odası (UPS, jeneratör, yangın güvenliği, su sensörleri) birçok felaketi önler veya etkisini sınırlar. İyi belgelenmiş ve etiketlenmiş bir altyapı, kurtarma sırasında hızlı müdahale sağlar. Yani felaket kurtarma planı, fiziksel altyapı tasarımıyla iç içedir — biri olmadan diğeri eksik kalır. Doğru kurulmuş fiziksel temel, felaket kurtarmanın görünmeyen ama hayati bir parçasıdır.

Hazırlık, hayatta kalmanın anahtarı

Yedekleme ve felaket kurtarma, “umarım hiç gerek olmaz” diye ertelenen ama bir gün hayati hale gelen bir hazırlıktır. Yedekleme (3-2-1 kuralıyla) verileri korur; felaket kurtarma planı (RTO/RPO hedefleriyle) tüm sistemin geri gelmesini sağlar. Sadece veri değil, ağ altyapısı ve yapılandırmalar da yedeklenmeli; yedekler düzenli test edilmeli; ve fiziksel altyapı bu hazırlığı desteklemelidir. Bu hazırlık, bir felaket hiç yaşanmazsa görünmez kalır — ama yaşandığında, işletmenin hayatta kalmasıyla yok olması arasındaki farkı belirler. Her ölçekteki kurum için, basit ama düzenli bir yedekleme ve kurtarma planı, en değerli sigortalardan biridir. Felakete hazırlıklı olmak, onu yaşamaktan çok daha ucuzdur.

Sıkça Sorulan Sorular

Yedekleme ve felaket kurtarma farkı nedir?
Yedekleme, verilerin kopyasını almaktır. Felaket kurtarma ise bir felaket sonrası tüm sistemi (veri + altyapı + işleyiş) yeniden ayağa kaldırma planıdır. Yedekleme, felaket kurtarmanın bir parçasıdır.
3-2-1 yedekleme kuralı nedir?
Verinin 3 kopyası, 2 farklı ortamda, 1’i tesis dışında (off-site) tutulması kuralıdır. Bu, tek bir olayın (yangın, hırsızlık, arıza) tüm kopyaları yok etmesini önler.
Ağ altyapısı da yedeklenmeli mi?
Evet. Sadece veri değil, switch/firewall yapılandırmaları, ağ şemaları ve dokümantasyon da yedeklenmeli. Bir cihaz arızasında, yapılandırma yedeği hızlı kurtarma sağlar.
RTO ve RPO nedir?
RTO (kurtarma süresi hedefi): bir felaket sonrası sistemin ne kadar sürede geri gelmesi gerektiği. RPO (kurtarma noktası hedefi): ne kadar veri kaybının kabul edilebilir olduğu. İkisi planın temelini belirler.
Yedekler test edilmeli mi?
Kesinlikle. Test edilmemiş bir yedek, yedek sayılmaz. Düzenli geri yükleme testleri, yedeklerin gerçekten çalıştığını ve kurtarmanın mümkün olduğunu doğrular.
Fiziksel altyapı felaket kurtarmayı nasıl etkiler?
Yedekli kablolama, ayrı güç yolları ve sağlam sistem odası, bir felaketin etkisini sınırlar. İyi tasarlanmış fiziksel altyapı, kurtarmayı hızlandırır ve bazı felaketleri baştan önler.
Küçük işletme de felaket planı yapmalı mı?
Kesinlikle. Veri kaybı veya uzun kesinti, küçük işletmeler için varoluşsal bir tehdittir. Basit ama düzenli bir yedekleme ve kurtarma planı, her ölçekte hayati önemdedir.
Özet
Yedekleme verileri korur (3-2-1 kuralı: 3 kopya, 2 ortam, 1 tesis dışı); felaket kurtarma tüm sistemi ayağa kaldırır (RTO/RPO hedefleriyle). Veri kadar ağ altyapısı ve yapılandırma da yedeklenmeli; yedekler düzenli test edilmeli. En sık felaketler donanım arızası, insan hatası ve fidye saldırısıdır. Fiziksel altyapı bu hazırlığı destekler.

İyi bir kurtarma planı nasıl olur?

Felaket kurtarma planı, kafadaki iyi niyetler değil, yazılı ve uygulanabilir bir belge olmalıdır. İyi bir plan birkaç özelliği taşır. Önce net adımlar içerir: bir felaket olduğunda kim, ne yapacak, hangi sırayla? Panik anında doğaçlama değil, takip edilecek bir kontrol listesi gerekir. İkincisi, roller ve iletişim tanımlıdır: kim sorumlu, kim aranacak, nasıl koordine olunacak? Üçüncüsü, öncelik sırası belirlidir: hangi sistemler önce geri gelmeli (kritik olanlar), hangileri bekleyebilir? Dördüncüsü, güncel tutulur: altyapı değiştikçe plan da güncellenir; eski bir plan, yanlış yönlendirdiği için tehlikelidir. Ve en önemlisi, test edilir: plan kâğıt üzerinde mükemmel görünebilir ama gerçek bir tatbikatta eksikleri ortaya çıkar. Düzenli tatbikatlar, hem planı keskinleştirir hem de ekibin felaket anında ne yapacağını bilmesini sağlar. Bir felaket anı, planı ilk kez okuma zamanı değildir. İyi hazırlanmış ve test edilmiş bir plan, kaotik bir krizi yönetilebilir bir sürece dönüştürür. Bu hazırlık, felaket yaşanana kadar görünmez bir yatırımdır; ama o gün geldiğinde, işletmenin en değerli varlığı haline gelir. Profesyonel bir altyapı kurulumu, bu planın fiziksel temelini (yedeklilik, dokümantasyon, sağlam sistem odası) sağlar; planın kendisi ise kurumun sürekli güncellediği yaşayan bir belgedir.

İşletmenizi felakete karşı hazırlayalım

Yedekli altyapı ve felaket kurtarma planı için bize ulaşın.

Teklif Al