İşletmeler İçin Yedekleme Sistemleri

Yedekleme konusunda en sık karşılaştığımız durum, yedeğin var olduğunun sanılması ama hiç test edilmemiş olmasıdır. Yedek almak bir işlemdir; geri dönebilmek ise ayrı bir yetenektir ve yalnızca deneyerek doğrulanır. Aradaki farkı çoğu işletme, ancak gerçekten ihtiyaç duyduğu gün öğrenir.

Önce şu iki soruyu yanıtlayın

Yedekleme planı kurmadan önce iki rakamın netleşmesi gerekir. Birincisi: ne kadarlık bir veri kaybını göze alabilirsiniz? Bir günlük mü, bir saatlik mi? Bu, yedekleme sıklığını belirler. Günde bir kez yedek alıyorsanız, en kötü senaryoda bir günlük veriyi kaybedersiniz.

İkincisi: sistemler ne kadar süre kapalı kalabilir? Bu da geri dönüş yönteminizi belirler. Buluttan yüz gigabaytlık bir veriyi indirmek saatler sürer; aynı veri yerel bir diskten çok daha hızlı döner. İki soruya verdiğiniz cevap, yedekleme çözümünün maliyetini doğrudan etkiler.

3-2-1 kuralı

Yedekleme dünyasının en yaygın ve hâlâ geçerli kuralı:

• Verinin en az 3 kopyası bulunsun (aslı dahil).
• Bu kopyalar 2 farklı ortamda tutulsun (örneğin yerel disk ve bulut).
• En az 1 kopya fiziksel olarak başka bir yerde olsun.

Kural, tek noktada yaşanan bir olayın tüm kopyaları birden yok etmesini engellemek için vardır. Yangın, su baskını, hırsızlık veya fidye yazılımı — hepsi aynı binadaki tüm kopyaları etkileyebilir.

Sık yapılan hata, sunucunun yanında duran bir harici diski 'ikinci kopya' saymaktır. Aynı odada, aynı elektrik hattında ve aynı ağda duran bir disk, gerçek bir felakette ana veriyle birlikte kaybolur.

Senkronizasyon yedekleme değildir

En yaygın ve en pahalıya patlayan yanılgı budur. OneDrive, Google Drive veya Dropbox gibi araçlar dosyalarınızı buluta kopyalar, ama yaptıkları iş yedekleme değil senkronizasyondur. Aradaki fark, hatanın hangi yöne aktığındadır.

Bir dosyayı yanlışlıkla sildiğinizde senkronizasyon bu silmeyi sadakatle her yere yansıtır. Bir fidye yazılımı dosyalarınızı şifrelediğinde şifreli hâlleri buluta yüklenir. Yani bozulma, kopyayı da bozar. Yedekleme ise geriye dönük ayrı sürümler tutar; bozulan hâl, sağlam hâlin üzerine yazılmaz.

Bu araçların sürüm geçmişi özelliği kısmi bir koruma sağlar ancak sınırlıdır: geçmiş belirli bir süre saklanır ve toplu bir şifrelenmede binlerce dosyayı tek tek geri almak pratik değildir. Senkronizasyonu kullanmaya devam edin; sadece onu yedek yerine saymayın.

Tam, artımlı ve fark yedeği

Yedekleme yazılımlarında karşınıza çıkan üç yöntem, alan kullanımı ile geri dönüş hızı arasındaki dengeyi belirler:

• Tam yedek: her seferinde verinin tamamı kopyalanır. En çok alanı kullanır, en hızlı ve en güvenli geri dönüşü sağlar.
• Artımlı yedek: yalnızca bir önceki yedekten bu yana değişenler alınır. En az alanı kullanır; geri dönüşte zincirdeki bütün yedeklere ihtiyaç duyulur, aradan biri bozulursa sonrası da kullanılamaz.
• Fark yedeği: son tam yedekten bu yana değişenler alınır. Alan kullanımı ortadadır; geri dönüş için yalnızca son tam yedek ve son fark yedeği yeterlidir.

Çoğu işletme için makul kurgu, haftalık bir tam yedek ile günlük artımlı yedeklerin birleşimidir. Ancak seçim yaparken şunu unutmayın: artımlı zincir uzadıkça geri dönüş süresi de uzar. Zinciri düzenli aralıklarla yeni bir tam yedekle kırmak, hem süreyi kısaltır hem de tek bir bozuk dosyanın tüm geçmişi kullanılamaz hâle getirmesini engeller.

Fidye yazılımı ve değiştirilemez kopya

Fidye yazılımları artık yalnızca dosyaları şifrelemekle kalmıyor; sisteme sızdıktan sonra erişebildikleri yedekleri de arayıp siliyor veya şifreliyor. Ağa sürekli bağlı duran bir yedekleme diski bu senaryoda koruma sağlamaz.

Çözüm, yedeğin bir kez yazıldıktan sonra belirli bir süre değiştirilemeyecek şekilde saklanmasıdır. Bulut sağlayıcılarının çoğu bu özelliği sunar; genellikle 'immutable' veya 'object lock' adıyla geçer. Etkinleştirildiğinde, yönetici yetkisi ele geçirilse bile o süre dolmadan yedek silinemez.

Ağdan tamamen ayrık bir kopya da aynı işi görür: haftalık olarak alınıp kasaya kaldırılan bir disk, teknolojik olarak eski ama fidye yazılımına karşı etkilidir.

Neyi yedeklemeyi unutuyoruz?

Yedekleme planları genellikle dosya sunucusuna odaklanır ve şunlar gözden kaçar:

• Muhasebe programının veritabanı — çoğu zaman sunucuda değil, tek bir bilgisayarda durur.
• E-posta arşivi — buluttaysa da yedeklenmesi gerekir; sağlayıcı silinen veriyi sınırsız süre saklamaz.
• Web sitesi ve veritabanı.
• Kullanıcıların masaüstünde ve 'İndirilenler' klasöründe tuttuğu dosyalar.
• Sunucu yapılandırmaları — veriyi geri getirmek yetmez, sistemi de yeniden kurabilmek gerekir.
• Lisans anahtarları ve erişim bilgileri.

Kaç sürüm, ne kadar süre saklanmalı?

Yedeklerin ne kadar geriye gittiği, sıklığı kadar önemlidir. Yalnızca son yedeği tutan bir sistem, dünkü bir hataya karşı korur; üç hafta önce bozulmuş ve bugün fark edilmiş bir veritabanına karşı hiçbir işe yaramaz. Bozulmalar her zaman aynı gün fark edilmez.

Bu yüzden kademeli saklama kullanılır: son günlerin tamamı, sonrasında haftalık birer kopya, daha geride aylık birer kopya. Böylece hem yakın geçmişte ayrıntılı bir seçim yapabilirsiniz hem de birkaç ay öncesine dönme imkânı korunur. Alan maliyeti, her günü sonsuza kadar saklamaya göre çok daha düşük olur.

Saklama süresini belirlerken yasal yükümlülükleri de hesaba katın. Muhasebe ve fatura kayıtları için mevzuatın öngördüğü saklama süreleri, teknik ihtiyacınızdan uzun olabilir. Buna karşılık kişisel veri içeren kayıtları gereğinden uzun saklamak da ayrı bir risktir; ihtiyaç bittiğinde silinmesi gereken veriyi süresiz tutan bir yedekleme politikası, KVKK açısından sorun üretir.

Bulut yedekleme güvenli mi?

Doğru yapılandırıldığında evet. Kritik nokta şudur: veri, sizin cihazınızdan çıkmadan önce şifrelenmeli ve şifre çözme anahtarı sizde kalmalıdır. Bu yapıldığında sağlayıcının çalışanları bile içeriği okuyamaz.

Buna karşılık anahtarı kaybetmek, veriyi kaybetmekle aynı anlama gelir. Anahtarın kendisi de güvenli ve ayrı bir yerde saklanmalıdır.

Test etmeden yedekleme sayılmaz

Düzenli aralıklarla bir dosyayı gerçekten geri yükleyin. Ayda bir yapılan bu basit alışkanlık, kritik anda çalışmayan bir yedekle karşılaşma ihtimalini büyük ölçüde ortadan kaldırır.

Yılda en az bir kez de daha kapsamlı bir tatbikat yapılmalı: sunucunun tamamı boş bir makineye geri yüklenebiliyor mu? Bu testi yapmamış hiçbir işletme, felaket kurtarma planı olduğunu söyleyemez.

Tatbikatın ikinci amacı süreyi ölçmektir. Geri dönüşün ne kadar sürdüğünü bilmek, planın kendisi kadar değerlidir. 'Yedeğimiz var' cümlesi ile 'sunucuyu dört saatte ayağa kaldırabiliyoruz' cümlesi arasındaki fark, bir kriz anında işletmenin ne yapacağını bilip bilmemesi anlamına gelir.

Kurtarma planı yazılı olmalı

Bir felaket anında planın en kritik özelliği, o an panik hâlindeki bir kişinin okuyup uygulayabilmesidir. Bu yüzden plan akılda değil kâğıtta olmalıdır. Yazılı bir kurtarma planında en az şunlar bulunmalı: hangi sistemin hangi sırayla ayağa kaldırılacağı, yedeklerin fiziksel ve dijital olarak nerede durduğu, şifre çözme anahtarına kimin eriştiği, sağlayıcıların iletişim bilgileri ve çalışanların bilgilendirilme biçimi.

Planın bir kopyasının çevrimdışı bulunması gerekir. Yalnızca şirket sunucusunda duran bir felaket kurtarma planı, tam da ihtiyaç duyulduğu anda erişilemez hâlde olur.