3-2-1 Yedekleme Kuralı: Küçük İşletmeler İçin Uygulanabilir Bir Plan

Yedekleme planı yapan herkes sonunda aynı kurala varır: 3-2-1. Fotoğrafçı Peter Krogh'a atfedilen bu kural kısa ve hatırlanması kolaydır:

• 3 kopya veri bulundurun (asıl veri + 2 yedek).
• 2 farklı depolama ortamı kullanın (ör. sunucu diski ve harici disk ya da bulut).
• 1 kopya farklı bir fiziksel konumda olsun.

Mantığı basittir: tek bir arızanın (disk bozulması, yangın, fidye yazılımı, yanlış komut) tüm kopyaları aynı anda yok etmemesi gerekir.

Her kural neyi önler?

Küçük bir iş yeri örneği

Bir Raspberry Pi üzerinde çalışan, veritabanlı bir iç uygulama düşünün (ör. personel takip paneli).

1. Kopya 1 (asıl veri): Pi'deki veritabanı.
2. Kopya 2 (aynı cihaz, farklı konum): Pi üzerinde ~/yedekler dizininde günlük sıkıştırılmış döküm. Bu yedek, yanlışlıkla silme ve bozulma durumunda en hızlı kurtarma yoludur ama kart ölürse gider; bu yüzden tek başına sayılmaz.
3. Kopya 3 (başka cihaz, başka yer): Ağdaki başka bir bilgisayara (örneğin bir Windows sunucuya) her gece SSH/rsync ile kopya. Bu kopya farklı bir ortamda ve mümkünse farklı bir odada ya da binada olmalıdır.

Pi'nin yedeği zaten aynı kartta durduğundan, gerçek koruma 3. kopyadan gelir. Yedeğin nasıl alınacağı için MariaDB yedek yazımıza bakabilirsiniz.

Fidye yazılımına karşı: değiştirilemez yedek

Modern saldırılarda fidye yazılımı yalnızca ana veriyi değil, erişebildiği yedekleri de şifreler. Bunu önlemek için üçüncü kopyayı "salt ekleme" (append-only) veya sürümlü tutun:

• Yedek hedefine yazma yetkisi olan hesap, eski yedekleri silememeli.
• Bulut depolarda nesne kilidi (object lock) ve sürümleme özellikleri bu amaçla vardır.
• Yedek hedefi, üretim sunucusundan ayrı kimlik bilgileriyle erişilen bir yer olsun. Üretim makinesi ele geçirilirse yedek hedefinin parolası da orada duruyor olmamalı.

Hangi sıklıkta, ne kadar saklayın?

İki kavram işi netleştirir:

• RPO (Recovery Point Objective): En fazla ne kadarlık veri kaybını göze alırsınız? Günlük yedek, en kötü durumda 24 saatlik kayıp demektir. Bu kabul edilemezse sıklığı artırın.
• RTO (Recovery Time Objective): Hizmet en fazla ne kadar süre kapalı kalabilir? Yedeğin nerede durduğu ve geri yükleme prosedürünün yazılı olup olmadığı bunu belirler.

Saklama için yaygın bir düzen: son 14 günün günlük yedekleri, son 8 haftanın haftalık yedekleri ve son 12 ayın aylık yedekleri. Kişisel veri içeren yedekler için saklama süresi hukuki çerçeveyle uyumlu olmalıdır. Sonsuza dek saklanan yedek, silinmesi gereken verinin de sonsuza dek durması demektir; bu konu KVKK yazımızda ele alınıyor.

Yedeğin çalıştığını kanıtlamak

• Yedek işi her çalıştığında sonucu kaydedin; başarısızlıkta e-posta alın.
• Dosya boyutunu izleyin. Bir gün aniden çok küçülen yedek bir alarm işaretidir.
• Ayda bir geri yükleme testi yapın ve sonucu not edin.
• Geri yükleme adımlarını, sunucuya erişemeyeceğiniz bir durumda da okunabilecek yere yazın (basılı veya başka bir cihazda).

Başlangıç için kısa liste

1. Neyi yedekleyeceğinizi listeleyin (veritabanı, yapılandırma dosyaları, .env, sertifikalar).
2. Otomatik günlük yedek kurun.
3. En az bir kopyayı başka bir cihaza ve başka bir konuma taşıyın.
4. Yedek hedefinde silme yetkisini kısıtlayın.
5. Geri yüklemeyi bir kez gerçekten deneyin.

Yedekleme sıkıcı bir iştir; sıkıcı kalması da onun iyi çalıştığının işaretidir.