📑 İçindekiler
Çoğu şirkette yedekleme bir politika değil, bir alışkanlıktır: bir kişi bir şeyler ayarlamıştır, çalışıyordur, kimse dokunmaz. Sorun, o kişi ayrıldığında ya da kötü gün geldiğinde ortaya çıkar. Yazılı bir politika, yedeklemeyi kişiye bağımlı olmaktan çıkarır.
Aşağıdaki başlıklar, kullanabileceğiniz bir iskelettir. Her maddenin altında neye karar vermeniz gerektiğini yazdım.
1. Kapsam — neyi yedekliyoruz?
Tek tek sayın; "sitemiz" yeterli bir tanım değildir. En az şu üçünü ayrı ayrı ele alın:
- Dosyalar: web kökü, yüklenen belge ve görseller, özelleştirilmiş tema dosyaları.
- Veritabanı: içerik, kullanıcılar, siparişler, ayarlar.
- E-posta: kurumsal posta kutuları — çoğu politikada unutulan kalem budur.
Kapsam dışında bıraktıklarınızı da yazın. "Sunucu işletim sistemi yedeklenmez, yeniden kurulur" cümlesi, kriz anında tartışma bitirir.
2. Sıklık — ne kadar veri kaybını göze alıyoruz?
Bu sorunun teknik adı RPO'dur: kabul edilebilir azami veri kaybı. Cevabı doğrudan sıklığınızı belirler.
- Tanıtım sitesi → haftalık veya günlük
- Blog / haber → günlük
- E-ticaret → saatlik
- Yoğun mağaza → saatlikten daha sık
Bileşenlere ayrı sıklık vermek hem korumayı artırır hem maliyeti düşürür: dosyalar nadiren değişir, veritabanı sürekli. Ayrıntılı anlatım için felaket kurtarma planı sayfamıza bakabilirsiniz.
3. Saklama — ne kadar geriye dönebilmeliyiz?
Bu, sıklıktan ayrı bir karardır ve genelde atlanır. Belirleyici soru şudur: bir sorunu ne kadar geç fark edebiliriz?
Sessiz bozulmalar (bir eklentinin verileri yavaşça bozması, fark edilmeyen bir saldırı) haftalar sonra ortaya çıkabilir. Saklama süreniz kısaysa elinizdeki tüm yedekler zaten bozuk hâli içerir. Pratik yaklaşım, her türden birkaç kopyayı tutmak ve süreyi işin kritikliğine göre uzatmaktır.
Kişisel veri işliyorsanız buna bir sınır da ekleyin: KVKK, veriyi işleme amacından fazla saklamamanızı ister. Saklama ve imha politikanızda bu süreyi tanımlar, yedekleme tarafında da otomatik temizlik kurallarıyla uygularsınız.
📍 "Yedek nerede saklanmalı?" sorusunun kısa cevabı
En az bir kopya, yedeklediğiniz sistemden bağımsız bir yerde durmalıdır. Aynı sunucuda duran yedek, sunucu kaybolduğunda birlikte kaybolur. Bu, yedeklemenin en temel ve en sık ihlal edilen kuralıdır — ayrıntı için 3-2-1 kuralı.
4. Konum ve erişim — nerede duruyor, kim açabiliyor?
- Yedekler fiziksel/mantıksal olarak nerede duruyor? Hangi sağlayıcı, hangi bölge?
- Kimler erişebiliyor? Erişim kayıt altına alınıyor mu?
- Şifreleme kullanılıyor mu, anahtar kimde ve nerede yedekli?
Son madde hayati: şifreleme anahtarınız yalnızca kaybettiğiniz sunucudaysa, şifreli yedeğiniz de kaybolmuş demektir. Anahtarı sistemden bağımsız bir yerde saklayın.
5. Sorumluluk — kim, ne zaman, neyi yapıyor?
- Yedekleme düzeninin sahibi kim? (Kişi değil, rol yazın.)
- Uyarılar kime gidiyor? O kişi izinliyken kime gidiyor?
- Geri yükleme kararını kim veriyor?
- Kriz anında müşteri bilgilendirmesi kimin sorumluluğunda?
6. Test — politika gerçekten çalışıyor mu?
Bu madde olmadan politika bir temenniden ibarettir. En az şunları tanımlayın: geri yükleme ne sıklıkta deneniyor, kim deniyor, sonuç nereye kaydediliyor ve başarısız bir testte ne yapılıyor.
Şunu ayırt edin: yedeğin alınmış olması, bütünlüğünün doğrulanmış olması ve geri yüklenebildiğinin denenmiş olması üç ayrı şeydir. Politikanız üçünü de kapsamalıdır — bkz. yedek doğrulama.
7. Maliyet — ne kadar harcamalıyız?
Doğru soru "yedekleme ne kadar tutar" değil, "bir günlük veri kaybı bize ne kadara mal olur" sorusudur. İkincisini hesaplayın: kaybedilen sipariş geliri, yeniden üretilecek içeriğin iş gücü maliyeti, müşteri güveni ve olası yasal yükümlülükler.
Bu sayının yanında yedekleme maliyeti genellikle küçük kalır. Maliyeti düşürmenin meşru yolları da vardır: artımlı yedekleme aktarılan veriyi ve depolama kullanımını azaltır, bileşen bazında sıklık ayarı yalnızca ihtiyaç duyduğunuz yere ödeme yapmanızı sağlar.
8. Gözden geçirme
Politikanın en son ne zaman güncellendiğini yazın ve bir gözden geçirme aralığı belirleyin. Sistemler değişir: yeni bir uygulama eklenir, sunucu taşınır, bir bileşen kaldırılır. Güncellenmemiş politika, yanlış güven verir.
Özet: minimum çalışan politika
Kapsam yazılı · her bileşen için sıklık belirli · saklama süresi tanımlı · en az bir kopya sistemden bağımsız · şifreleme anahtarı ayrı yerde · sorumlu rol belirli · test takvimi var ve sonuçları kaydediliyor. Bu yedi maddeyi karşılayan bir sayfa, çoğu şirketin bugün sahip olduğundan iyidir.
Sık Sorulan Sorular
Yedekleme politikası ne içermelidir?
En az şu yedi başlık: kapsam (neyin yedeklendiği ve neyin yedeklenmediği), her bileşen için yedekleme sıklığı, saklama süresi, yedeklerin konumu ve erişim yetkileri, şifreleme ve anahtar yönetimi, sorumluluk rolleri ve test takvimi. Test maddesi olmayan bir politika, doğrulanmamış bir temennidir.
Yedek nerede saklanmalı?
En az bir kopya, yedeklediğiniz sistemden bağımsız bir yerde durmalıdır. Aynı sunucuda ya da aynı hosting hesabında duran yedek; sunucu kaybolduğunda, hesap askıya alındığında veya fidye yazılımı diski şifrelediğinde birlikte kaybolur. Bu, yedeklemenin en temel kuralıdır.
Yedekleme maliyeti ne kadar olmalı?
Doğru karşılaştırma yedekleme ücreti ile değil, bir günlük veri kaybının maliyetiyle yapılır: kaybedilen sipariş geliri, içeriğin yeniden üretilme iş gücü, müşteri güveni ve olası yasal yükümlülükler. Bu sayının yanında yedekleme maliyeti çoğu işletmede küçük kalır. Artımlı yedekleme ve bileşen bazında sıklık ayarı maliyeti düşürmenin meşru yollarıdır.
Saklama süresini nasıl belirlemeliyim?
Belirleyici soru şudur: bir sorunu ne kadar geç fark edebiliriz? Sessiz bozulmalar ve fark edilmeyen saldırılar haftalar sonra ortaya çıkabilir; saklama süreniz kısaysa elinizdeki tüm yedekler zaten sorunlu hâli içerir. Kişisel veri işliyorsanız ayrıca KVKK gereği veriyi işleme amacından fazla saklamamanız gerekir.
Küçük bir işletmenin de yazılı politikaya ihtiyacı var mı?
Evet, ama uzun bir belgeye değil. Tek sayfalık bir metin bile yedeklemeyi kişiye bağımlı olmaktan çıkarır. Asıl risk politikanın yokluğu değil, tek bir kişinin aklında olmasıdır; o kişi ayrıldığında veya kriz anında ulaşılamadığında sistem sahipsiz kalır.