Veri kaybının en acı tarafı, kaybın kendisi değil; yedeğin var sanılıp açılmadığının o gün anlaşılmasıdır. Bozuk arşiv, eksik veritabanı, altı ay önce sessizce durmuş bir cron görevi: hepsi sahada sık karşılaşılan senaryolar. 3-2-1 kuralı bu riski sadeleştirir, kurtarma tatbikatı ise kurulumun gerçekten işlediğini kanıtlar.

3-2-1 kuralı nedir?

Kural üç sayıdan oluşur: verinin 3 kopyası bulunsun, bu kopyalar 2 farklı ortamda saklansın ve en az 1 kopya farklı bir fiziksel konumda olsun. Üç kopya derken orijinali de sayarsınız; yani canlı veri artı iki yedek.

Mantığı basittir: aynı sunucudaki iki yedek, sunucu kaybedildiğinde birlikte gider. Aynı ofisteki iki disk, aynı yangında birlikte biter. Farklı ortam ve farklı konum, riskleri birbirinden ayırmak için vardır.

Kuralı uygulamaya çevirmeden önce iki sayıya karar vermeniz gerekir. Birincisi kabul edilebilir veri kaybı: en kötü ihtimalle kaç saatlik veriyi yeniden girmeyi göze alabilirsiniz? İkincisi hedef ayağa kalkma süresi: site kaç saat kapalı kalırsa iş durur? Bu iki sayı yazılı değilse, yedek sıklığınızı hislerle seçiyorsunuz demektir.

KOBİ ölçeğinde nasıl kurulur?

KopyaNerede dururSıklıkSaklama süresi
Canlı veriÜretim sunucusuSürekli-
Yedek 1Sunucuda ayrı disk veya sağlayıcının yedek alanıGünlük7-14 gün
Yedek 2Farklı sağlayıcıda nesne depolama veya ofis dışı diskGünlük ya da haftalık4-8 hafta
ArşivSoğuk depolama, salt okunurAylık6-12 ay

Tablodaki değerler bir başlangıç şablonudur; kendi kabul edilebilir kayıp sürenize göre sıkılaştırın. Günde 10 sipariş alan bir sitede gecelik yedek makul olabilir: en kötü senaryoda bir günlük sipariş elle yeniden girilir. Günde 300 sipariş alan bir sitede aynı politika, kötü bir günde onlarca siparişin kaybı demektir. Bu ölçekte veritabanı dökümünü 4-6 saatte bir almak, dosya yedeğini ise günlük tutmak dengeli bir kurulumdur; çünkü ürün görselleri gün içinde nadiren değişir, sipariş tablosu ise sürekli değişir.

Neyi yedekliyorsunuz?

"Site yedeği" tek bir şey değildir. Eksiksiz bir set şunları içerir:

  • Veritabanının tutarlı bir dökümü
  • Yüklenen dosyalar: ürün görselleri, fatura PDF'leri, sözleşme ekleri
  • Uygulama kodu ve özelleştirmeler
  • Yapılandırma dosyaları: web sunucusu, PHP ayarları, cron tanımları
  • SSL sertifikaları ve varsa anahtar dosyaları
  • E-posta kutuları ve DNS kayıtlarının yazılı bir kopyası

Bu listeyi bir kez çıkarıp yedek betiğinizin kapsamıyla satır satır karşılaştırın. Sahada en sık atlanan iki kalem, cron tanımları ve DNS kayıtlarıdır; ikisi de yedek dosyasının içinde durmaz, kaybolduğunda ise hatırlamak zordur.

Yedeği güvenli hâle getiren ayrıntılar

  • Şifreleme: Yedek içinde müşteri adı, adres, telefon gibi kişisel veriler bulunur. KVKK kapsamında bu veriler canlı sistemde nasıl korunuyorsa yedekte de korunmalıdır. Arşivleri şifreleyin, şifre anahtarını yedeğin yanında tutmayın.
  • Erişim ayrımı: Yedek deposuna yazma yetkisi olan bir kimlik, silme yetkisine sahip olmamalı. Fidye yazılımı bulaşan bir sunucu, ulaşabildiği tüm yedekleri de şifreler.
  • Sürümleme: Tek bir dosyayı sürekli üzerine yazmak yedek değildir. Bozulma fark edilene kadar geçen sürede tek kopyanız da bozulmuş olur.
  • Bildirim: Başarısız yedek işi sessiz kalmamalı. "Başarısızlıkta uyar" kuralı kurun; ama ayda bir başarı raporuna da bakın, çünkü tamamen durmuş bir görev hiç uyarı üretmez.
  • Boyut takibi: Yedek dosyası bir önceki güne göre belirgin şekilde küçüldüyse, muhtemelen içeriğin bir kısmı alınmıyordur. Basit bir eşik yeterlidir: dosya bir öncekinin yüzde 80'inin altındaysa uyarı üret.

Kurtarma tatbikatı: asıl çıktı burada ölçülür

Yedekleme bir maliyet kalemidir; kurtarma ise gerçek çıktıdır. Tatbikat, kurtarmayı gerçek gün gelmeden prova etmektir. Üç ayda bir, çoğu KOBİ kurulumunda yarım günlük bir çalışmayla yapılabilir.

  1. Senaryo seçin. "Sunucu tamamen kayboldu" veya "veritabanı dün gece bozuldu" gibi somut bir durum belirleyin.
  2. Kronometreyi başlatın. Süreyi ölçmezseniz hedefinizi tutturup tutturmadığınızı bilemezsiniz.
  3. Ayrı bir ortama geri yükleyin. Kesinlikle canlı sisteme değil; geçici bir sunucuya ya da alt alan adına kurun.
  4. İçeriği doğrulayın. Son siparişler görünüyor mu? Ürün görselleri yerinde mi? Bir kullanıcı hesabıyla giriş yapılabiliyor mu? Fatura kayıtları eksiksiz mi?
  5. Eksikleri not edin. Hangi dosya yoktu, hangi ayar elle girilmek zorunda kaldı, hangi şifreyi bulmak yirmi dakika sürdü?
  6. Süreyi ve bulguları yazın. Sonuç bir sayfayı geçmesin ama tarih, süre ve eksikler mutlaka yer alsın.
  7. Test ortamını silin. Geri yüklenmiş bir kopyanın internette açık kalması, ciddi bir veri sızıntısı riskidir.

Tatbikatın çıktısı iki sayıdır: kaç saatlik veri kaybettiniz ve siteyi kaç saatte ayağa kaldırdınız. Örneğin gece 03.00 yedeğinden dönüldüyse ve arıza saat 11.00'de olduysa kayıp sekiz saatliktir; geri yükleme 03.00'ten 14.30'a kadar sürdüyse ayağa kalkma süresi üç buçuk saattir. Bu iki sayı başta yazdığınız hedeflerin üstündeyse politika değişmeli: yedek sıklığı artmalı veya kurtarma adımları betiğe çevrilmelidir.

Sık yapılan hatalar

  • Yedeği aynı sunucuda tutmak. En yaygın hata. Sunucu gittiğinde her şey gider.
  • Sadece dosya yedeklemek. Veritabanı olmadan dosyalar bir işe yaramaz; tersi de geçerlidir.
  • Yedeği hiç açmamak. Bozuk arşiv ancak açmaya çalışınca anlaşılır.
  • Site kök dizinine yedek koymak. Tahmin edilebilir bir adrese konan yedek dosyası, tüm müşteri verinizi tarayıcıyla indirilebilir hâle getirir.
  • Yedek şifresini yedeğin yanına yazmak. Şifrelemeyi anlamsız kılar.
  • Sadece sağlayıcıya güvenmek. Birçok hosting paketinde yedek vardır ama kapsamı ve saklama süresi çoğu zaman sandığınızdan kısadır; koşulları yazılı olarak teyit edin.
  • Personel ayrıldığında erişimi güncellememek. Kurtarma anında hesap sahibine ulaşamamak en pahalı gecikmedir.

Uygulanabilir kontrol listesi

  1. Üç soruyu bugün yazılı yanıtlayın: kaç saatlik veri kaybını kaldırabilirim, ne kadar sürede ayağa kalkmam gerekir, bu işten kim sorumlu?
  2. Yedek kapsamını yukarıdaki altı maddelik listeyle karşılaştırın ve eksikleri betiğe ekleyin.
  3. 3-2-1'i kurun: en az bir kopya farklı sağlayıcıda ve şifreli olsun, silme yetkisi ayrı bir kimlikte dursun.
  4. Başarısızlıkta uyarı gönderen bir bildirim kurun; ayrıca dosya boyutu için yüzde 80 eşiği tanımlayın.
  5. Üç ayda bir, ayrı ortama geri yükleme tatbikatı yapın ve iki sayıyı kaydedin: veri kaybı ve ayağa kalkma süresi.
  6. Tatbikatta bulduğunuz her eksiği aynı hafta kapatın; not defterinde kalan bulgu, kapatılmamış risktir.