Sistem Mimarisi logo Sistem Mimarisi Bilişim Blogu
Reklam Alanı
Sistem Mimarisi
Sistem Mimarisi

Yedekleme Stratejileri: 3-2-1 Kuralından Immutable Backup'a

29 Temmuz 2026 · 3 dk okuma · 10 okunma

Yedekleme, felaket kurtarma stratejisinin en temel ama en sık ihmal edilen bileşenidir. Bir yedekleme sisteminin varlığı yetmez; doğru çeşitlendirilmiş, test edilmiş ve kötü niyetli değişikliğe karşı korunaklı olması gerekir. Bu yazıda klasik 3-2-1 kuralından günümüzün immutable backup yaklaşımına uzanan çizgiyi ele alıyoruz.

3-2-1 Kuralı

3-2-1 kuralı, onlarca yıldır sektörde kabul görmüş basit bir formüldür:

  • 3 kopya: Verinin orijinaliyle birlikte en az iki yedek kopyası bulunmalı.
  • 2 farklı ortam: Kopyalar farklı depolama türlerinde tutulmalı (örneğin yerel disk + bulut nesne depolama), tek bir donanım hatası tüm kopyaları etkilememeli.
  • 1 kopya site dışında (offsite): Yangın, sel veya hırsızlık gibi fiziksel felaketlere karşı en az bir kopya farklı bir coğrafi konumda olmalı.

Örneğin bir veritabanı sunucusu için basit bir uygulama: canlı veritabanı (1. kopya), aynı veri merkezinde farklı bir diskte tutulan günlük snapshot (2. kopya) ve bulut nesne depolamaya (S3 uyumlu) şifreli olarak gönderilen haftalık tam yedek (3. kopya, offsite).

Yedekleme Türleri

  • Tam yedekleme (full): Tüm verinin komple kopyalanması; en güvenli ama en yavaş ve en fazla depolama gerektiren yöntem.
  • Artımlı yedekleme (incremental): Yalnızca bir önceki yedeklemeden bu yana değişen verilerin kopyalanması; hızlı ve az yer kaplar ama geri yükleme zinciri uzundur.
  • Farksal yedekleme (differential): Son tam yedeklemeden bu yana biriken tüm değişikliklerin kopyalanması; artımlıya göre daha fazla yer kaplar ama geri yükleme daha basittir.
# rsync ile basit artımlı yedekleme örneği
rsync -avz --delete /var/www/ backup@remote:/backups/www-$(date +%F)/

# PostgreSQL için mantıksal tam yedek
pg_dump -Fc mydb > mydb_$(date +%F).dump

Fidye Yazılımı Tehdidi ve Immutable Backup

Klasik yedekleme mimarilerinin en büyük zaafı, yedekleme sistemine erişimi olan bir saldırganın (veya fidye yazılımının) yedekleri de şifreleyebilmesi veya silebilmesidir. Bu tehdide karşı geliştirilen çözüm immutable backup (değiştirilemez yedek) yaklaşımıdır. Bu modelde yazılan bir yedek nesnesi, belirlenen bir süre boyunca hiçbir kullanıcı (root dahil) tarafından değiştirilemez veya silinemez.

Bu mantığın temelinde WORM (Write Once, Read Many) depolama ilkesi yatar. Bulut ortamlarında bu genellikle nesne kilidi (object lock) özelliğiyle uygulanır:

# AWS S3 Object Lock ile compliance modunda 30 gün immutability
aws s3api put-object-retention \
  --bucket sirket-yedekleri \
  --key veritabani/2026-09-28.dump \
  --retention '{"Mode":"COMPLIANCE","RetainUntilDate":"2026-10-28T00:00:00Z"}'

Compliance modunda, retention süresi dolmadan önce nesneyi silme yetkisi hesap sahibi de dahil hiç kimseye verilmez; bu, saldırgan API anahtarlarını ele geçirse bile yedekleri silemeyeceği anlamına gelir.

Geri Yükleme Testleri Şart

Test edilmemiş bir yedekleme, yedekleme değildir. Düzenli aralıklarla gerçek bir geri yükleme (restore) tatbikatı yapılmalı; yedeğin alınabiliyor olması, ondan başarıyla geri dönülebileceğinin garantisi değildir. RTO (Recovery Time Objective) ve RPO (Recovery Point Objective) hedefleri bu tatbikatlarla doğrulanmalıdır.

Sonuç

3-2-1 kuralı hâlâ sağlam bir temel oluşturur, ancak günümüzün fidye yazılımı odaklı tehdit ortamında immutable/WORM depolama katmanı olmadan bir yedekleme stratejisi eksik sayılır. Güvenlik açıklarının kök nedenlerini anlamak için OWASP Top 10 yazımıza da göz atabilirsiniz.

İlgili Yazılar