Yedekleme Stratejisi: 3-2-1 Kuralı ve Ransomware Çağı

Her IT yöneticisinin duyduğu 3-2-1 kuralı şu der: 3 kopya, 2 farklı medyada, 1 off-site. 1990'larda tape backup zamanında çıkmış bu kural ransomware çağında hala anlamlı mı? Kısa cevap: evet, ama eksik.

Kuralın özü

3 kopya: Production veri + en az 2 yedek. Tek yedeğin çıkıp gelmediği yıllar olur — bant okunmaz, disk bozulur, bulut hesabı kapanır.

2 farklı medya: Aynı disk array'de 5 kopya tutmak işe yaramaz; controller bozulduğunda hepsi gider. Disk + bant, veya disk + cloud, veya on-prem disk + farklı sağlayıcıda cloud.

1 off-site: En az bir kopya fiziksel olarak başka yerde olmalı. Yangın, sel, hırsızlık tek bina'daki her şeyi alır.

Ransomware kuralı kırdı mı

Hayır, ama bir gereklilik daha ekledi: immutable (değiştirilemez) yedek. Modern ransomware ağa girdiğinde önce yedeklere ulaşıp onları silmeye veya şifrelemeye çalışır. Eğer yedekleriniz aynı domain'den erişilebilirse, yedek anlamsızlaşır.

Çözüm: yedek depolama katmanı silinemez ve değiştirilemez olmalı belirli bir süre boyunca. Sektörde “3-2-1-1” veya “3-2-1-1-0” gibi türevler bu nedenle ortaya çıktı (son 1: immutable, son 0: doğrulanmış errorsuz).

Pratik immutable backup uygulamaları

Üç pratik yol var:

• S3 Object Lock — AWS S3, Wasabi, MinIO. Yedek objesi WORM (write-once-read-many) modunda yazılır. Belirlenen retention süresi boyunca kimse silemez, root user dahil.
• ZFS snapshot + send/receive — Snapshot'lar read-only. Off-site ZFS sunucusuna replikasyon yapıldığında oradaki snapshot'lar üzerine yazma haklarınızı kaldırırsanız efektif olarak immutable olur.
• Tape (LTO-9) — Eski moda ama hala işe yarar. Bant fiziksel olarak yedek alındıktan sonra rafa kalkar; ransomware dijital olarak ulaşamaz. Eski şirketlerde hala kullanılır.

3-2-1'in unutulan 4. parçası: test

Yedeklemenin en sinsi tuzağı: yedek alıyorsunuz ama hiç restore denemiyorsunuz. Restore zamanı geldiğinde bant okunmaz, parolayı kimse hatırlamaz, restore prosedürü değişmiş ve dokümante edilmemiş olur.

Müşterilerimizle çalıştığımız standart: ayda bir restore drill (rastgele bir dosyayı yedekten geri getir, doğrula), yılda bir full DR tatbikatı (production sistemini geçici ortama restore et, çalıştığını kanıtla). Tatbikat raporu müşteriye teslim edilir — sertifikasyon denetimlerinde de kanıt görevi görür.

Yedekleme yazılımı seçimi

Kurumsal seçenekler: Veeam (de facto standart, lisanslı, mükemmel UI), Bareos (Veeam'in açık kaynak alternatifi, daha fazla efor), Restic (komut satırı, kriptografik şifreleme built-in, S3 backend), BorgBackup (deduplication çok güçlü).

Küçük ve orta ölçekte Restic genellikle yeterli — komut satırı dostluğu sysadmin için artı, S3 Object Lock'la immutable yedek sağlanabilir. Büyük kurumsal Windows ortamlarda Veeam daha pratik.

RPO ve RTO — bir parantez

Yedekleme stratejisi tasarlanırken iki sayı belirleyin: RPO (Recovery Point Objective — “ne kadar veriyi kaybetmeyi göze alıyoruz?”) ve RTO (Recovery Time Objective — “ne kadar sürede ayağa kalkmalıyız?”). Günlük yedek = RPO 24 saat. Saatlik snapshot = RPO 1 saat. Restore süresi her yöntemde farklı.

Bu sayılar iş sürekliliği planının çekirdeğidir; sözleşmede yer almalı. Sayıları aklında olmayan yedekleme stratejisi hayalden ibarettir.

Sonuç

3-2-1 kuralı 30 yıldır geçerli. Modern eklenti: en az 1 kopya immutable olmalı. Hepsinden önemlisi: test edilmemiş yedek, yedek değildir. Yedek almak kolay, restore etmek beceri. Beceriyi sadece düzenli pratikle kazanırsınız.