Veri Yedekleme ve Felaket Kurtarma Planı Nasıl Hazırlanır?

Veri kaybı çoğu işletmede aynı cümleyle başlar: "Yedeğimiz vardı ama…" O "ama"nın arkasında genelde şunlardan biri çıkar: yedek aylardır çalışmıyormuş, yedek diski de virüs kapmış, ya da yedek var ama nasıl geri dönüleceğini kimse bilmiyor. Yedekleme kâğıt üzerinde herkeste vardır; işe yarayanı ise sınanmış olandır. Bu yazıda, ihtiyaç anında gerçekten geri gelen bir yedekleme ve felaket kurtarma yapısını nasıl kuracağınızı adım adım anlatıyoruz.

Önce İki Kavramı Netleştirelim: RTO ve RPO

İyi bir plan, iki basit soruyla başlar. Birincisi: bir felaket olduğunda sistemin en geç ne kadar sürede tekrar ayakta olması gerekir? Bunun cevabı RTO'dur (kurtarma süresi hedefi). İkincisi: en fazla ne kadarlık veriyi kaybetmeyi göze alabilirsiniz? Bunun cevabı da RPO'dur (kurtarma noktası hedefi).

Somutlaştıralım: RPO'nuz 24 saatse ve günde bir kez yedek alıyorsanız, en kötü senaryoda son bir günün verisini kaybedersiniz. Bu bir muhasebe firması için kabul edilemez, küçük bir tanıtım sitesi için sorun bile olmayabilir. Bu iki sayıyı belirlemek, ne kadar sık yedek almanız ve ne kadar hızlı bir kurtarma altyapısına yatırım yapmanız gerektiğini doğrudan söyler. Sayıyı koymadan yapılan yedekleme, hedefi olmayan bir harcamadır.

RTO ve RPO'yu iş birimleriyle birlikte belirlemenizi öneririz. Teknik ekip "bir hafta idare eder" derken, satış ekibi bir günlük duruşun bile müşteri kaybı demek olduğunu bilir.

3-2-1 Kuralı: Basit ama Sağlam

Yedekleme dünyasının en dayanıklı kuralı hâlâ 3-2-1. Anlamı şu: verinizin en az üç kopyası olsun, bunları en az iki farklı ortamda tutun ve bir kopya fiziksel olarak başka bir yerde (site dışında) bulunsun. Bu kural, tek bir olayın tüm kopyalarınızı birden yok etmesini engellemek için tasarlanmıştır.

Günümüz tehditlerine karşı bu kurala bir de "1" eklemek faydalı: kopyalardan biri çevrimdışı ya da değiştirilemez (immutable) olsun. Çünkü fidye yazılımı, ağa bağlı yedek diskini de bulup şifreleyebilir. Erişilemeyen ya da yazılamayan bir kopya, bu senaryoda kurtarıcınız olur.

  • 3 kopya: Bir üretim, iki yedek.
  • 2 ortam: Örneğin bir yerel disk/NAS ve bir bulut.
  • 1 site dışı: Ofis dışında, coğrafi olarak ayrı.
  • +1 değiştirilemez: Fidye yazılımına karşı sigorta.

Neyi Yedeklediğinizi Bilin

Her şeyi yedeklemek pahalı ve gereksizdir; kritik olanı yedeklememek ise felakettir. Bu yüzden bir veri envanteri çıkarın: hangi veri işin devamı için hayati, hangisi yeniden üretilebilir, hangisinin yasal saklama zorunluluğu var. Muhasebe kayıtları, müşteri veritabanı, sözleşmeler ve e-posta arşivi genellikle en üst sıradadır. Bu önceliklendirme, hem maliyeti hem de kurtarma sırasını belirler.

Felaket Kurtarma Planı: Sadece Yedek Değil, Senaryo

Yedekleme verinin kopyasını almaktır; felaket kurtarma (DR) ise o veriyle işi yeniden ayağa kaldırma senaryosudur. İkisi karıştırılır ama farklıdır. Elinizde eksiksiz yedek olsa bile, "hangi sırayla neyi geri getireceğiz, kim yapacak, uygulamalar birbirine bağımlıysa hangisi önce açılacak" sorularının cevabı yoksa kurtarma saatler yerine günler sürer.

Planda mutlaka olması gerekenler

  1. Kritik sistemlerin öncelik sırası ve bağımlılıkları.
  2. Her sistem için kimin sorumlu olduğu ve iletişim bilgileri.
  3. Adım adım geri yükleme prosedürü (yedeğe nereden, nasıl erişilir).
  4. Alternatif çalışma yöntemi: sistemler kapalıyken iş nasıl yürür.
  5. Müşteri ve çalışanlara yapılacak bilgilendirmenin planı.

Bu planı tek sayfada özetleyip erişilebilir (ve dijital sistemler çökse bile ulaşılabilir, örneğin basılı) bir yerde tutun. Kriz anında kimse uzun bir dokümanı okumaz; net bir kontrol listesi arar.

En Kritik Adım: Test

Bir yedek, geri yüklenene kadar sadece bir varsayımdır. En az üç ayda bir gerçek bir geri dönüş tatbikatı yapın: seçtiğiniz bir sistemi yedekten ayağa kaldırın ve süreyi ölçün. Bu tatbikat hem yedeğin sağlığını doğrular hem de gerçek RTO'nuzu gösterir. Projelerimizde çıkan en yaygın sürpriz, "çalışıyor sandığımız" yedeğin aslında aylardır boş dosya ürettiğidir.

Ne Sıklıkla ve Ne Kadar Süre Saklamalı

Yedekleme sıklığı doğrudan RPO'nuzdan çıkar: kaybını göze alabileceğiniz süre neyse, yedek aralığınız ondan kısa olmalı. Sürekli işlem gören bir muhasebe ya da e-ticaret sistemi için günde bir kez bile az kalabilir; burada saatlik ya da sürekli (anlık) yedekleme devreye girer. Statik, seyrek değişen veriler içinse günlük veya haftalık yeterli olur.

Saklama süresi ise ayrı bir karardır. Sadece "en son" yedeği tutmak tehlikelidir; çünkü bir sorun (bozulan bir dosya, sessizce yayılan bir zararlı yazılım) günler sonra fark edilebilir ve o zaman elinizdeki tek yedek de zaten bozulmuş olur. Bu yüzden katmanlı bir saklama planı kurun: son birkaç günün günlük yedeği, birkaç haftanın haftalık yedeği ve birkaç ayın aylık yedeği bir arada bulunsun. Böylece geriye dönüp temiz bir noktaya ulaşma şansınız olur. Yasal saklama zorunluluğu olan veriler için bu süreleri mevzuata göre ayrıca belirleyin.

Otomatikleştirin ve İzleyin

İnsana bağlı yedekleme, unutulmaya mahkûmdur. Yedekleri otomatik zamanlayın ve daha önemlisi, sonucu izleyin. Başarısız bir yedeklemenin size bir uyarı olarak ulaşması şart; sessizce başarısız olan bir yedek, hiç olmayan bir yedekten daha tehlikelidir çünkü size güvende olduğunuz yanılgısını yaşatır. Basit bir bildirim mekanizması bile ("gece yedeği başarısız oldu") çoğu felaketi önceden yakalar.

Yedekleme Yöntemleri Arasındaki Fark

Her yedekleme aynı değildir ve yöntem seçimi hem depolama maliyetini hem de geri dönüş hızını etkiler. Üç temel yaklaşımı bilmek, size uygun dengeyi kurmanızı sağlar.

  • Tam yedek: Her seferinde tüm verinin kopyası alınır. Geri dönüşü en basit olandır ama en çok yer kaplar ve en uzun sürer.
  • Artımlı yedek: Yalnızca son yedekten bu yana değişenler alınır. Hızlı ve az yer kaplar; ancak geri dönüşte birden çok yedeğin sırayla birleştirilmesi gerekir.
  • Fark (diferansiyel) yedek: Son tam yedekten bu yana değişen her şey alınır. İkisinin arasında bir denge sunar.

Pratikte çoğu işletme için sağlam bir düzen, haftalık tam yedek ile günlük artımlı yedeğin birleşimidir. Buradaki asıl mesele "hangisi doğru" değil, seçtiğiniz düzenin RTO ve RPO hedeflerinizi karşılayıp karşılamadığıdır. Yer kazandırıyor diye seçilen bir yöntem, geri dönüşü saatlerce uzatıyorsa aslında pahalıya mal oluyor demektir.

Bulut Yedeği mi, Yerel Yedek mi?

Bu ikisi rakip değil, tamamlayıcıdır. Yerel yedek (örneğin bir NAS ya da harici disk) hızlı geri dönüş sağlar; büyük bir dosyayı ya da sunucuyu yerel ağdan geri getirmek dakikalar sürer. Bulut yedeği ise site dışı kopyayı ve coğrafi dağıtımı sağlar; ofisinizin başına bir şey gelse bile veriniz uzakta güvendedir.

Sağlam bir kurgu genellikle ikisini birlikte kullanır: gündelik hızlı geri dönüşler için yerel, felaket senaryosu ve site dışı koruma için bulut. Bulut yedeğinde bir noktayı da atlamayın; büyük hacimli veriyi buluttan geri indirmek internet hızınıza bağlıdır ve düşündüğünüzden uzun sürebilir. Bu süreyi kurtarma planınızda gerçekçi hesaplamak, kriz anında hayal kırıklığını önler.

Sorumluluğu Tek Kişiye Bağlamayın

Yedekleme ve kurtarma bilgisinin tek bir çalışanın kafasında durması, sık karşılaştığımız ve tehlikeli bir durum. O kişi izinde, hasta ya da işten ayrılmışsa, felaket tam da en kötü anda kimsenin ne yapacağını bilmediği bir kaosa dönüşür. Bu yüzden kurtarma prosedürünü yazılı hale getirin ve en az iki kişinin bu süreci uygulayabildiğinden emin olun.

Aynı şekilde, yedeklerin saklandığı yerlerin erişim bilgileri de güvenli ama tek kişiye bağımlı olmayan bir biçimde tutulmalı. Kurtarma planınızı yılda bir kez, o işi normalde yapan kişi olmadan denemek iyi bir sınavdır: eğer plan yalnızca "uzmanımız hallediyor" ise, aslında bir planınız yok demektir.

Yaygın Hatalar

  • Yedeği aynı sunucuda tutmak: Sunucu çökerse yedek de gider.
  • Sadece dosya yedeklemek, sistemi unutmak: Uygulama yapılandırmaları ve veritabanları olmadan dosyalar tek başına işi kurtarmaz.
  • Test etmemek: En sık ve en pahalı hata.
  • Saklama süresini düşünmemek: Bir fidye yazılımı fark edilmeden haftalarca sistemde kalabilir; sadece son birkaç günün yedeği varsa, temiz bir noktaya dönemezsiniz.

Nereden Başlamalı

Karmaşık görünse de doğru başlangıç sade: kritik verinizi listeleyin, RTO/RPO hedeflerinizi belirleyin, 3-2-1 kuralına göre kopyalarınızı kurun, kurtarma adımlarını yazın ve düzenli test edin. Bu beş adım, çoğu işletmeyi veri kaybı karşısında dayanıklı hale getirir.

Mevcut yedekleme yapınızın gerçekten geri dönüp dönmediğini denetlemek ya da işletmenize uygun bir felaket kurtarma planı kurmak isterseniz ücretsiz bir değerlendirme talebi oluşturabilirsiniz. Verinizin nerede durduğuna bakıp zayıf noktaları birlikte kapatalım.

Paylaş:

Projeniz İçin Ücretsiz Danışmanlık

Uzman ekibimiz, işletmenize özel çözümler ve yol haritası oluşturur.