Veri Kaybı Bir İhtimal Değil, Zamanlama Sorunudur
Disk arızası, yanlışlıkla silme, fidye yazılımı, hırsızlık, yangın veya basit bir yazılım hatası; veri kaybının yüzlerce yolu vardır ve bunların hiçbiri "bize olmaz" denecek kadar nadir değildir. Üstelik kayıpların önemli bölümü dramatik felaketlerden değil, sıradan insan hatalarından doğar. İşletmeler için kritik soru, veri kaybının yaşanıp yaşanmayacağı değil, yaşandığında ne kadar verinin ve sürenin kaybedileceğidir. Doğru kurgulanmış bir yedekleme stratejisi, bu kaybı felaket boyutundan yönetilebilir bir aksaklığa indirir.
3-2-1 Kuralı Nedir?
Sektörde altın standart kabul edilen 3-2-1 kuralı üç ilkeden oluşur:
- 3 kopya: Verinizin, kullanımdaki asıl kopya dahil en az üç kopyası bulunmalıdır.
- 2 farklı ortam: Kopyalar en az iki farklı depolama ortamında tutulmalıdır (ör. sunucu diski + NAS, ya da disk + bulut depolama). Amaç, tek bir ortam türünün ortak arıza riskinden kaçınmaktır.
- 1 kopya farklı konumda: En az bir kopya fiziksel olarak başka bir yerde durmalıdır. Aynı binadaki iki kopya; yangın, su baskını ve hırsızlıkta birlikte kaybolur.
Modern tehditler bu kurala bir ek getirmiştir (bazen 3-2-1-1-0 olarak anılır): Kopyalardan biri çevrimdışı veya değiştirilemez (immutable) olmalı ve yedekler sıfır hatayla, yani doğrulanmış olmalıdır. Fidye yazılımları, eriştikleri ağdaki yedekleri de şifrelemeye çalışır; sürekli bağlı bir harici disk veya aynı kimlik bilgileriyle erişilebilen bir yedek sunucusu, saldırı anında asıl veriyle birlikte kaybedilir.
Neyi, Ne Sıklıkla Yedeklemeli?
Her veri aynı değerde değildir. Veri envanterinizi üç soruyla önceliklendirin: Bu veri kaybolursa işletme ne kadar zarar görür? Yeniden üretilebilir mi? Yasal saklama yükümlülüğü var mı? Bu değerlendirmeden iki hedef çıkar: RPO (kabul edilebilir veri kaybı süresi; son yedekten bu yana geçen süre) ve RTO (kabul edilebilir kesinti süresi; geri dönüşün alacağı süre). Örneğin sipariş veritabanı için saatlik artımlı yedek gerekirken, nadiren değişen dosya arşivi için günlük veya haftalık yedek yeterli olabilir. Yedekleme sıklığını teknik alışkanlık değil, bu iş hedefleri belirlemelidir.
Yedek Türleri
Tam yedek: Tüm verinin eksiksiz kopyasıdır; geri dönüşü en basit, depolama maliyeti en yüksek türdür. Artımlı yedek: Son yedekten bu yana değişen verileri alır; hızlı ve ekonomiktir, ancak geri dönüş zincirdeki tüm parçalara ihtiyaç duyar. Fark yedeği: Son tam yedekten bu yana değişenleri alır; ikisinin ortasıdır. Yaygın pratik, periyodik tam yedek ile aradaki günlerde artımlı yedeği birleştirmektir. Veritabanları için dosya kopyası yeterli değildir; tutarlı anlık görüntü veya veritabanının kendi yedekleme aracı (dump, log gönderimi) kullanılmalıdır. Eşitleme (sync) hizmetlerinin yedek olmadığını da vurgulayalım: Yanlışlıkla silinen veya şifrelenen dosya, eşitlemeyle tüm kopyalara yayılır; sürüm geçmişi olmayan eşitleme, yedek sayılmaz.
Otomasyon ve Saklama Politikası
Elle alınan yedek, unutulan yedektir. Yedekleme tamamen otomatik çalışmalı; başarısız işler e-posta veya mesajla uyarı üretmeli ve bu uyarılar gerçekten takip edilmelidir. Saklama politikasında kademeli yaklaşım kullanın: Örneğin son 7 günün günlük, son 4 haftanın haftalık, son 12 ayın aylık yedeği. Bu kurgu, hem yakın geçmişe ince taneli dönüş hem de eski bir tarihe dönüş imkânı sağlarken depolama maliyetini dengeler. KVKK kapsamındaki kişisel veriler için saklama ve imha sürelerinizin yedekleri de kapsadığını unutmayın; süresi dolan verinin yedeklerden de imha edilmesi planlanmalıdır. Yedeklerin şifrelenmesi (hem aktarımda hem depolamada) ve şifreleme anahtarlarının yedeklerden ayrı saklanması da zorunlu iyi uygulamadır.
Bulut ve SaaS Verilerini Kapsama Alın
Yedekleme planları genellikle sunucuları kapsar ama günlük işin aktığı SaaS platformlarını unutur. E-posta kutuları, ofis dokümanları, CRM kayıtları ve proje yönetim verileri için sorumluluk paylaşımı modeli geçerlidir: Sağlayıcı platformun çalışmasından sorumludur, verinizin yanlışlıkla silinmesine veya kötü niyetli değiştirilmesine karşı korunması ise büyük ölçüde size aittir. Çöp kutusu ve sürüm geçmişi özellikleri kısa vadeli hatalarda yardımcı olur; ancak saklama süreleri sınırlıdır ve hesap ele geçirme senaryolarında yetersiz kalır. Kritik SaaS verileri için bağımsız bir yedekleme çözümü kullanın veya en azından düzenli dışa aktarma rutini kurun. Aynı ilke web siteniz için de geçerlidir: Yalnızca hosting sağlayıcının yedeğine güvenmek, tek konum ve tek tedarikçi riskini birleştirir.
Test Edilmeyen Yedek, Yedek Değildir
Yedekleme projelerinin en kritik ve en çok atlanan adımı geri yükleme testidir. Düzenli aralıklarla (en az çeyrekte bir) gerçek bir geri dönüş tatbikatı yapın: Rastgele seçilen dosyaları, bir veritabanını ve mümkünse sistemin tamamını izole bir ortama geri yükleyin. Bu testler üç şeyi doğrular: Yedekler gerçekten çalışıyor mu, geri dönüş prosedürü belgelenmiş ve uygulanabilir mi, RTO hedefiniz gerçekçi mi? Kriz anında ilk kez denenen geri yükleme, kötü sürprizlerin en klasik kaynağıdır.
OPEIS Teknoloji Desteği
Yedekleme stratejisi tasarımı, otomasyon kurulumu, fidye yazılımına dayanıklı değiştirilemez yedek mimarileri ve felaket kurtarma planlaması konularında destek sağlıyoruz. Mevcut yedekleme düzeninizin değerlendirilmesi için destek ekibimizle iletişime geçebilirsiniz.