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.

Gerçek hayattan bir senaryo

Küçük bir otelin personel paneli tek bir Raspberry Pi üzerinde çalışıyor. İlk kurulumda "yedek" olarak veritabanı dökümü aynı SD kartta duruyordu. Bu bir yedek değildir: kart bozulduğunda hem canlı veri hem "yedek" gider. Düzeltilmiş düzen şöyle: gece dökümü Pi'de, aynı dökümün kopyası yerel ağdaki ikinci bir makinede, haftalık şifreli kopya ise dış bir konumda. Gerçek bir tatbikatta bulduğumuz eksikleri SD kart bozulursa: yedek tatbikatı yazısında anlattık.

Yedek planınızı puanlayın

Kendi planınızı şu sorularla sınayın; her "hayır" bir açıktır:

1. Verinizin canlı kopyası dışında en az iki kopya var mı?
2. Kopyalardan biri farklı bir cihazda, biri farklı bir binada ya da bulutta mı?
3. En az bir kopya, ana sisteminiz ele geçirilse bile silinemeyecek ya da şifrelenemeyecek şekilde mi duruyor?
4. Yedeğin başarısız olduğunu otomatik olarak öğreniyor musunuz?
5. Son üç ayda gerçek bir geri yükleme denediniz mi?
6. Yapılandırma dosyalarınız, zamanlayıcılarınız ve gizli bilgilerin nasıl yeniden oluşturulacağı yazılı mı?
7. Saklama süreniz (kaç gün/hafta/ay) belirli ve disk alanı hesaplanmış mı?

Disk alanı için yedek alanı hesaplayıcıyı kullanabilirsiniz.

Sık yapılan hatalar

• Senkronizasyonu yedek sanmak. Bir bulut klasörüne eşitleme yedek değildir: dosyayı yanlışlıkla silerseniz ya da fidye yazılımı şifrelerse, değişiklik hemen kopyaya da yansır. Yedek, geçmiş sürümleri tutmalıdır.
• Yedeği aynı ağda ve aynı kimlikle açık bırakmak. Ana makineyi ele geçiren biri, ona bağlı yedek sürücüyü de silebilir. Yedek hedefi yalnızca ekleme yapabilen ayrı bir kullanıcıyla erişilmeli.
• Şifre kaybı. Şifreli yedeğin parolasını yalnızca aynı makinede tutmak, o makine gidince yedeğin de erişilemez olması demektir. Parolayı ayrı ve güvenli bir yerde saklayın.
• Sadece veriyi yedeklemek. Uygulamayı yeniden kurmak için gereken paket listesi, servis dosyaları ve ayarlar da kayıt altında olmalı.
• Hiç test etmemek. Sessizce bozulan yedek, ihtiyaç duyulduğu anda ortaya çıkar. Geri yükleme testini takvime bağlayın.

Sık sorulan sorular

Üç kopya çok mu fazla? Üç kopya, tek bir arızanın, hatanın ya da saldırının tüm kopyaları aynı anda yok etmesi ihtimalini çok düşürür. Küçük veri için maliyet çoğu zaman ihmal edilebilir.

Bulut yedeği tek başına yeterli mi? Bulut, "uzak kopya" ihtiyacını karşılar; ancak hesabınız ele geçirilirse ya da erişiminizi kaybederseniz kopyaya ulaşamayabilirsiniz. Yerel bir kopya da bulundurun.

Ne sıklıkla yedek almalıyım? Cevap, "ne kadar veriyi kaybetmeyi göze alabilirim?" sorusundadır. Günde bir yedek alıyorsanız en kötü durumda bir günlük veriyi kaybedersiniz. Veri çok değerliyse sıklığı artırın.