Yedekleme ve Felaket Kurtarma: Veriniz Yarın Sabah Yoksa Ne Olur?

Yedekleme ve felaket kurtarma, çoğu şirketin yönetiminde konuşulmayan ama başına geldiğinde her şeyi durduran bir konudur. Sunucu bozulur, bir çalışan yanlışlıkla tabloyu siler, fidye yazılımı sistemi kilitler ya da ofis basit bir yangında zarar görür; bu senaryoların hepsinde asıl soru aynıdır: veriniz geri gelir mi, gelirse ne kadar sürede ve ne kadarı kaybolmuş olur?

Bu yazıda yedekleme kavramını ciddiyetle ele alıyor, iyi bir yedekleme stratejisinin neye benzediğini, felaket kurtarmanın yedeklemeden nasıl farklı olduğunu ve bir şirketin bu konuda kendine sorması gereken soruları anlatıyoruz. Amaç korku yaratmak değil; bu konunun yalnızca sorun çıktığında hatırlanan bir başlık olmaktan çıkmasını sağlamak.

Yedekleme ve felaket kurtarma nedir, birbirinden farkı ne?

Yedekleme, verinin bir kopyasının düzenli aralıklarla ayrı bir yerde saklanmasıdır. Felaket kurtarma ise bir arıza, saldırı ya da afet durumunda sistemin ne kadar sürede ve hangi veri kaybıyla yeniden ayağa kaldırılacağını tanımlayan daha geniş bir plandır. Yedekleme, felaket kurtarmanın yalnızca bir parçasıdır; yedek almak tek başına bir kurtarma planı değildir.

Bu farkı bir örnekle açıklamak kolaydır. Bir şirketin her gece alınan yedeği olabilir, ama sunucu çöktüğünde bu yedeği nereye, nasıl ve kaç saatte geri yükleyeceğini kimse denememiş olabilir. O zaman yedek vardır ama kurtarma planı yoktur. Felaket kurtarma, yedeğin var olmasının ötesinde, o yedeğin gerçekten işe yarayıp yaramadığının test edilmesini de içerir.

İyi bir felaket kurtarma planı iki temel ölçütle tanımlanır: ne kadar veri kaybına razı olunabileceği ve sistemin yeniden ne kadar sürede ayağa kalkması gerektiği. Bu iki ölçüt, hangi yedekleme sıklığının ve hangi altyapının gerekli olduğunu belirler. Bir e-ticaret sitesi için birkaç dakikalık kesinti bile ciddi kayıptır; bir iç raporlama aracı için birkaç saat sorun olmayabilir.

Yedekleme yapmayan bir şirket ne risk altında?

Yedekleme yapmayan bir şirket, tek bir donanım arızasıyla yılların birikimi olan müşteri, sipariş ve finans verisini tamamen kaybetme riski altındadır; bu kayıp genellikle geri döndürülemez. Sigorta, donanımın maddi bedelini karşılayabilir ama içindeki veriyi asla geri getiremez. Veri, bir kez gittiğinde gitmiştir.

Bu risk yalnızca donanım arızasıyla sınırlı değildir. İnsan hatası, örneğin yanlışlıkla silinen bir tablo ya da üzerine yazılan bir dosya, günlük operasyonda donanım arızasından çok daha sık yaşanır. Fidye yazılımı saldırıları ise son yıllarda küçük ve orta ölçekli şirketleri de hedef almakta; saldırganlar veriyi şifreleyip fidye talep eder, güncel bir yedek olmadan bu durumda pazarlık gücü tamamen saldırgandadır.

Riskin büyüklüğü şirketin ölçeğiyle orantılı değildir. Aksine, küçük bir şirket için tüm müşteri geçmişinin, sözleşmelerin ve finansal kayıtların bir gecede silinmesi, büyük bir şirkete göre çok daha yıkıcı olabilir; çünkü küçük şirketin bu kaybı telafi edecek yedek insan gücü ya da finansal tampon olasılığı daha düşüktür.

İyi bir yedekleme stratejisi nasıl olmalı?

İyi bir yedekleme stratejisi üç ilkeye dayanır: birden fazla kopya, birden fazla ortam ve düzenli test. Yaygın kabul gören kural, verinin en az üç kopyasının, en az iki farklı ortamda, en az birinin de fiziksel olarak farklı bir konumda tutulmasıdır. Tek bir yedek, tek bir noktada tutulan yedek her zaman kırılgandır.

Yedekleme sıklığı, verinin ne kadar hızlı değiştiğine göre belirlenir. Sürekli işlem gören bir satış ya da randevu sisteminde günlük yedek yetersiz kalabilir; saatlik ya da gerçek zamanlıya yakın yedekleme gerekebilir. Nadiren güncellenen bir arşiv için günlük yedek fazlasıyla yeterlidir. Doğru sıklık, kaybedilmesi kabul edilebilir en fazla veri miktarına göre hesaplanır.

Yedeklerin şifrelenmesi de stratejinin parçasıdır; çünkü bir yedek dosyası çalınırsa, orijinal sistem kadar hassas bir veri sızıntısı yaşanır. Ayrıca yedeklere erişim de rol bazlı sınırlanmalı, kimin yedek geri yükleyebileceği net tanımlanmalıdır. Yedekleme, veri güvenliğinin bir istisnası değil, doğrudan bir parçasıdır.

Yedek almak yeterli mi, geri yükleme testi neden şart?

Yedek almak tek başına yeterli değildir; bir yedeğin işe yaradığını bilmenin tek yolu onu gerçekten geri yükleyip denemektir. Pek çok şirket yıllarca yedek aldığını düşünür, gerçek bir kriz anında yedeğin bozuk, eksik ya da uyumsuz olduğunu keşfeder. O an, en kötü zamanda öğrenilen en pahalı derstir.

Geri yükleme testi düzenli aralıklarla, örneğin üç ayda bir, gerçek bir kriz simüle edilerek yapılmalıdır: yedek ayrı bir ortama geri yüklenir, verinin eksiksiz ve tutarlı geldiği doğrulanır, bu işlemin ne kadar sürdüğü ölçülür. Bu test hem yedeğin sağlamlığını hem de gerçek bir krizde ne kadar sürede ayağa kalkılacağını gösterir.

Test sırasında ortaya çıkan sorunlar, kriz anında değil sakin bir günde düzeltilir. Belki yedekleme betiği bir tabloyu atlıyordur, belki geri yükleme süresi kabul edilebilir sınırın çok üzerindedir. Bu bulgular, planı gerçek bir felaketten önce iyileştirmenin tek yoludur. Test edilmeyen yedek, aslında yedek olduğu varsayılan bir belirsizliktir.

Bulutta çalışan sistemlerde yedekleme kimin sorumluluğu?

Bulutta çalışan sistemlerde yedekleme, genellikle yazılım tedarikçisinin sorumluluğundadır, ama bu sorumluluğun sözleşmede açıkça tanımlanmış olması gerekir; aksi halde şirket, kimsenin üstlenmediği bir boşlukla karşılaşabilir. Bulut sağlayıcısının altyapı yedekliliği ile yazılımın kendi verisinin düzenli yedeklenmesi aynı şey değildir; ikisi karıştırılmamalıdır.

Bir SaaS ürünü kullanıyorsanız sormanız gereken sorular nettir: verilerim ne sıklıkla yedekleniyor, yedekler nerede tutuluyor, bir veri kaybında geri yükleme ne kadar sürer, geri yükleme testleri düzenli yapılıyor mu? İyi bir tedarikçi bu sorulara net cevap verir ve genellikle bu bilgileri hizmet sözleşmesinin ya da güvenlik dökümanının bir parçası olarak paylaşır.

Şirkete özel geliştirilen ve bulutta işletilen sistemlerde ise yedekleme, geliştirme sözleşmesinin bir parçası olarak baştan tanımlanmalıdır. Kimin yedekleme altyapısını kuracağı, kimin izleyeceği ve kimin test edeceği net olmazsa, bu sorumluluk sessizce hiç kimseye düşmüş olabilir. Bu, en sık rastlanan ve en pahalıya patlayan boşluklardan biridir.

Felaket kurtarma planı hangi soruları cevaplamalı?

Bir felaket kurtarma planı şu soruları net cevaplamalıdır: hangi sistemler kritik ve hangi sırayla ayağa kaldırılacak, ne kadar veri kaybı kabul edilebilir, sistem yeniden ne kadar sürede çalışır hale gelmeli, kriz anında kim ne yapacak ve müşterilere ne söylenecek. Bu sorulara kriz anında değil, sakin bir günde cevap verilmiş olmalıdır.

Kritik sistemlerin sıralanması özellikle önemlidir. Bir şirketin randevu sistemi, ödeme kaydı ve müşteri iletişim geçmişi aynı anda kesintiye uğradığında hangisinin önce geri geleceği belirsizse, kriz anında değerli saatler tartışmayla geçer. Bu sıralama önceden yapılmışsa, ekip tartışmadan doğrudan harekete geçer.

İletişim planı da genellikle unutulan bir kalemdir. Müşterilere, çalışanlara ve gerekiyorsa düzenleyici kurumlara ne zaman ve ne söyleneceği baştan kararlaştırılmalıdır. Sessizce sorunu çözmeye çalışıp müşterilere hiç bilgi vermemek, güveni kısa vadeli bir rahatlıktan çok daha büyük ölçüde zedeler; şeffaf ve zamanında bir iletişim, krizin itibar üzerindeki etkisini büyük ölçüde azaltır.

Küçük bir şirket için gerçekçi bir yedekleme planı nasıl kurulur?

Küçük bir şirket için gerçekçi bir yedekleme planı, karmaşık bir altyapı gerektirmez; günlük otomatik yedekleme, yedeğin en az bir kopyasının farklı bir bulut ortamında tutulması ve üç ayda bir yapılan basit bir geri yükleme testinden oluşabilir. Önemli olan büyüklük değil, düzenli ve test edilmiş olmasıdır.

İlk adım, hangi verinin gerçekten kritik olduğunu belirlemektir. Müşteri kayıtları, finansal veriler ve sözleşmeler genellikle en kritik kategoridir; bunların yedeklenmesi öncelik olmalıdır. İkinci adım, bu yedeklemenin kimin sorumluluğunda olduğunu net biçimde bir kişiye ya da tedarikçiye bağlamaktır; sorumluluğu belirsiz bırakmak, sorumluluğun hiç kimseye ait olmaması anlamına gelir.

Üçüncü adım ise takvime bağlı bir test alışkanlığı kurmaktır. Yılda dört kez, örneğin her çeyrek başında, bir geri yükleme denemesi yapılıp sonucunun kısa bir notla kayda geçirilmesi yeterlidir. Bu küçük alışkanlık, büyük bir felaket anında şirketin saatler içinde toparlanmasıyla günlerce veri kaybı yaşaması arasındaki farkı yaratır.

Yedekleme bir teknik iş değil, bir yönetim kararıdır

Yedekleme ve felaket kurtarma sık sık bir bilgi işlem detayı gibi görülür, oysa aslında bir yönetim kararıdır. Şirketin kaç saatlik kesintiye, kaç dakikalık veri kaybına dayanabileceğine karar vermek, o şirketin işini en iyi bilen yöneticinin işidir. Teknik ekip bu kararı uygular, ama kararın kendisi işin sahibine aittir.

Rezon, şirketlere özel CRM, ERP ve bayi portalı sistemleri kuran, kendi SaaS ürünlerini canlıda işleten İstanbul merkezli bir yazılım çözümleri şirketidir. FizyoDesk ve OdyoDesk'te düzenli otomatik yedekleme ve geri yükleme testleri işletmenin doğal bir parçasıdır; şirketlere kurduğumuz özel sistemlerde de yedekleme ve felaket kurtarma planını sözleşmenin açık bir maddesi haline getiriyoruz. Sisteminizin yedekleme planını birlikte gözden geçirmek için İletişim sayfamızdan ücretsiz keşif görüşmesi talep edebilir, yaklaşımımızı Çözümler sayfamızdaki Özel Yazılım bölümünde inceleyebilirsiniz.