3-2-1 Yedekleme Kuralı: Sadece Yedek Almak Yetmez

Her gece yedekleriniz çalışıyor. Dashboard'da yeşil tikler görüyorsunuz. Ama gerçek şu: yedeğiniz olması güvende olduğunuz anlamına gelmez. Eğer tüm yedekleriniz production verisiyle aynı storage array'de duruyorsa, tek bir donanım arızası veya ransomware saldırısı her şeyi birlikte siler götürür. Tam da bu yüzden 3-2-1 yedekleme kuralı önemli — yönettiğim her ortamda uygulattığım minimum standart budur.

Kural basit: verinizin 3 kopyasını tutun, 2 farklı medya tipinde, 1 kopyası offsite'ta. Bu yazıda Linux ve Windows Server ortamlarında bunu nasıl uyguladığımı, hangi araçları kullandığımı ve adminlerin nerede hata yaptığını anlatacağım.

3-2-1 Yedekleme Kuralı Gerçekte Ne Demek

İnsanlar yanlış anladığı için 3-2-1 yedekleme stratejisini parça parça açıklayayım.

Verinizin 3 kopyası: Bu, orijinal production veriniz artı iki yedek demek. Üç yedek kopyası değil — kaynak dahil toplam 3 kopya.
2 farklı medya tipi: İki yedeği de aynı NAS'a koymayın. Farklı storage kullanın — local disk artı tape, veya local disk artı cloud object storage, veya SAN artı ucuz bir JBOD. Önemli olan tek nokta hatası riskini azaltmak.
1 kopya offsite: Bir yedek fiziksel olarak başka bir yerde veya bulutta durmalı. Binanız yanarsa veya biri tüm ağınızı şifrelerse hâlâ bir kurtarma yolunuz olur.

Pek çok admin "yedeğim var" noktasında duruyor ve o yedeğin gerçekten geri yüklenebilir olduğunu hiç kontrol etmiyor. Yedeklerin iki yıl boyunca başarıyla çalıştığı ama restore işleminin bir kez bile test edilmediği ortamlar gördüm. Ransomware geldiğinde yedeklerin başından beri bozuk olduğunu fark ettiler.

İlk İki Kopyayı Farklı Medyada Kurmak

Linux ortamlarımda genelde local kopya için restic veya borgbackup ile başlıyorum, sonra repository'yi ikinci bir storage hedefine sync ediyorum. restic ile kullandığım temel pattern şu:

# Initialize local repo on a separate disk
restic init --repo /mnt/backup/local/restic

# Run backup from production data
restic backup /var/www /etc /home --repo /mnt/backup/local/restic

# Copy to secondary storage (different media type)
restic copy --repo /mnt/backup/local/restic \
  --repo2 /mnt/tape/restic

/mnt/backup mount point'i ayrı bir disk array, production ile aynı sürücüdeki bir klasör değil. Ve /mnt/tape bir LTO tape library'sine veya ikincil bir disk rafına işaret ediyor. İki farklı medya tipi — kuralın ikinci direği bu.

Windows Server tarafında Veeam Backup & Replication'a güveniyorum. 3 kopya gereksinimini iyi karşılıyor çünkü aynı konsol içinde birincil backup hedefi, farklı bir repository'ye ikincil copy job ve tape veya cloud'a backup job kurabiliyorsunuz. Önemli olan birincil repository ile ikincil repository'nin aynı fiziksel SAN LUN üzerinde olmaması.

O Kritik Offsite Kopyayı Almak

Çoğu kurulum burada başarısız oluyor. Offsite kopyanın şatafatlı olması gerekmez, ama var olması ve test edilmesi gerekir.

Ortamımda local yedek tamamlandıktan sonra restic repo'sunu S3 uyumlu object storage'a push ediyorum:

# Sync restic repo to offsite S3-compatible storage
restic copy --repo /mnt/backup/local/restic \
  --repo2 s3:s3.eu-central-1.amazonaws.com/my-backup-bucket/restic

Veeam kullandığım Windows ortamlarında S3 uyumlu bir repository'ye veya Azure Blob storage'a Backup Copy Job yapılandırıyorum. Veeam'in capacity tier bunu kolaylaştırıyor — bir local performance tier ve bir S3 capacity tier ayarlıyorsunuz, Veeam policy'lere göre tiering'i otomatik hallediyor.

Uyarı: Offsite yedeğiniz production ağınızdan aynı credential'larla ulaşılabilen bir sistemde duruyorsa, ransomware onu da bulur ve şifreler. Offsite kopyanız izole olmalı. Ayrı credential, ayrı access key ve ideal olarak air-gapped veya immutable storage kullanın.

Restore Testi — Herkesin Atladığı Adım

Felaket kurtarma planlaması yazımda (https://furkanikkan.com/urun/yedeklerinizi-bozan-felaket-kurtarma-plani-hatalari-43) da belirttiğim gibi, test edilmemiş yedek bir dilektir, yedek değil. En az çeyrekte bir restore tatbikatı yaparım.

Restore test checklist'im şu:

Geçen haftanın yedeğinden rastgele bir dosya seç ve test sunucusuna geri yükle
Offsite kopyadan tam VM restore'u izole bir VLAN'a yap
Geri yüklenen sistemin boot ettiğini ve servislerin temiz başladığını doğrula
Restore ne kadar sürdüğünü belgele — bu senin RTO baseline'ın olur
restic check --read-data veya Veeam health check ile yedek bütünlüğünü kontrol et

# Verify restic repo integrity (reads all data packs)
restic check --read-data --repo /mnt/backup/local/restic

# Test restore a single file to /tmp
restic restore latest --target /tmp/restore-test \
  --include /etc/nginx/nginx.conf --repo /mnt/backup/local/restic

Restore testi başarısız olursa hemen düzelt. Gerçek bir felaket gelip yedeklerinin bozuk olduğunu keşfetmeyi bekleme.

Production'da Gördüğüm Yaygın 3-2-1 Hataları

Yedekleme ortamlarını denetlerken sürekli karşılaştığım pattern'ler bunlar:

Tüm yedekler aynı SAN'da: Aynı fiziksel storage üzerinde iki backup repo olması 2 farklı medya tipi demek değildir. Fazladan adımları olan 1 medya tipidir.
Offsite kopya domain credential kullanıyor: Offsite yedek production'da kullanılan aynı domain admin hesabıyla SMB üzerinden mount ediliyorsa, ransomware içine girip şifreler. En az yetkili dedicated service account kullanın — bu yaklaşımı sudo least-privilege yazımda anlattım (https://furkanikkan.com/urun/root-yetkisi-vermeden-linux-sistem-yonetimi-sudo-ile-en-az-yetki-46).
Immutability yok: Yedek storage'ınız silme veya değiştirmeye izin veriyorsa, erişimi olan bir saldırgan hepsini siler. S3 Object Lock, Veeam immutable repository veya append-only erişimli restic kullanın.
Yedek monitoring sonradan akla geliyor: Backup job sessizce üç hafta başarısız oluyorsa ve kimse fark etmiyorsa, 3-2-1 kurulumunuz anlamsız. Yedek durumunu monitoring stack'ime pipe ediyorum ki başarısızlıklar günler içinde değil dakikalar içinde alarm üretsin.

Pratik 3-2-1 Kurulumumun Özeti

Ortamlarımda sağlam bir 3-2-1 implementasyonu şu şekilde görünür:

Kopya 1: Canlı sunucudaki production verisi
Kopya 2: Local disk array'e gece yedeği (farklı fiziksel donanım)
Kopya 3: Object Lock açık S3 uyumlu cloud storage'a sync
Restore test: Belgelenmiş kurtarma süreleriyle çeyreklik tatbikat
Monitoring: Backup job hataları ortama göre Prometheus + Alertmanager veya Veeam One üzerinden alarm üretir

İpucu: Her şeyi otomatikleştirin. Offsite kopyayı bir insan manuel tetiklemek zorundaysa, eninde sonunda yapılmamaya başlar. Cron job, Veeam schedule veya systemd timer — stack'inize ne uyuyorsa onu yapın, otomatik olsun ve başarısızlıkta alarm üretsin.

3-2-1 yedekleme kuralı teorik değil. Patronunuza "her şeyi kaybettik" demek ile "şu an geri yüklüyoruz, iki saat kesinti bekleyin" demek arasındaki farktır. Uygulayın, test edin ve tek başına yeşil tiklere güvenmeyi bırakın.

Kapak görseli: Lenharth Systems · CC0 (Openverse / kamu malı) · https://stocksnap.io/photo/computer-hard-2J3PLNMO9M