Yedekleme Politikası Nasıl Oluşturulur?

"Yedeğimiz var" cümlesi tek başına bir şey ifade etmez. Kim alıyor, ne sıklıkla, nerede saklanıyor, ne kadar süreyle, geri yüklenebiliyor mu?

Bu soruların yazılı cevabı bir yedekleme politikasıdır ve her şirkette olmalıdır.

Başlamadan önce

• Hosting sözleşmenizdeki yedekleme maddesi
• Mevcut yedekleme düzeni hakkında bilgi
• Sitenizin ve veritabanınızın boyutu

1. Adım — Neyi yedekleyeceğinizi belirleyin

• ☐ Site dosyaları (kod, tema, eklentiler)
• ☐ Yüklenen medya (görseller, belgeler)
• ☐ Veritabanı (içerik, ayarlar, siparişler, kullanıcılar)
• ☐ Yapılandırma dosyaları
• ☐ E-posta kutuları
• ☐ DNS kayıtlarının kopyası
• ☐ SSL sertifika bilgileri

Son iki madde teknik olarak "yedek" sayılmaz ama bir taşıma ya da kriz anında hayati önem taşır.

2. Adım — Sıklığı belirleyin

Sıklık, kabul edebileceğiniz veri kaybına göre belirlenir:

Kritik soru: "Bir günlük veriyi kaybetsek ne olur?" Cevap kabul edilemezse, günlük yedek yetersizdir.

3. Adım — Saklama süresini belirleyin

Yalnız son yedeği tutmak yetersizdir. Bir sorun günler sonra fark edilebilir.

Yaygın bir düzen:

• Son birkaç günün günlük yedekleri
• Son birkaç haftanın haftalık yedekleri
• Son birkaç ayın aylık yedekleri

Bu düzen, hem yakın geçmişe hem de daha eski bir noktaya dönme imkânı verir.

4. Adım — Konumu belirleyin

Temel kural: Yedek, ana sistemle aynı yerde durmamalıdır.

Önerilen düzen:

• Sağlayıcının kendi yedeği (birinci kopya)
• Farklı bir hizmette ikinci kopya
• Kritik anlarda alınan manuel kopya (şirket içi ya da farklı bir depolama)

Neden: Sağlayıcı kaynaklı bir sorun (hesap kilidi, ödeme sorunu, altyapı kaybı) ana sistemi ve yedeği aynı anda etkileyebilir.

5. Adım — Sorumluyu belirleyin

• ☐ Yedeklemeden kim sorumlu?
• ☐ Çalıştığını kim doğruluyor?
• ☐ Ne sıklıkla kontrol ediliyor?
• ☐ Geri yükleme kararını kim veriyor?
• ☐ Geri yüklemeyi kim yapıyor?

En yaygın hata: Sağlayıcı, ajans ve şirket — her biri diğerinin aldığını varsayar. Sonuç: kimse almamıştır.

6. Adım — Doğrulama düzeni kurun

Yedek alındığını varsaymayın; doğrulayın:

• ☐ Yedek dosyaları oluşuyor mu?
• ☐ Boyutları beklenen düzeyde mi?
• ☐ Bildirim geliyor mu?
• ☐ Başarısız yedekler uyarı üretiyor mu?
• ☐ Aylık kontrol yapılıyor mu?

İkinci madde önemlidir: bozuk bir yedek genelde beklenenden çok küçük bir dosya olarak oluşur.

7. Adım — Geri yükleme testi planlayın

Bir yedek, geri yüklenebildiği kanıtlanana kadar yedek sayılmaz.

• ☐ Yılda en az bir kez test yapılıyor
• ☐ Test ortamına geri yükleniyor
• ☐ Geri yükleme süresi ölçülüyor
• ☐ Sonuç kayıt altına alınıyor

8. Adım — Politikayı yazın

Tek sayfalık bir belge yeterlidir:

Kapsam: [siteler ve veriler]
Sıklık: [günlük/haftalık]
Saklama: [süreler]
Konum: [birincil ve ikincil]
Sorumlu: [kişi/birim]
Doğrulama: [sıklık ve yöntem]
Geri yükleme testi: [sıklık]
Hedef kurtarma süresi: [süre]
Kabul edilebilir veri kaybı: [süre]

Son iki satır kurumsal açıdan önemlidir: bu iki hedef, yedekleme düzeninin tüm parametrelerini belirler.

Özel durumlar

Büyük değişiklik öncesi

Güncelleme, tasarım değişikliği ya da taşıma öncesi mutlaka manuel yedek alın ve indirin.

Kampanya öncesi

Yoğun döneme girmeden temiz bir yedek alın ve saklayın.

Sağlayıcı değişikliği

Eski hesabı kapatmadan önce tam bir yedek alın ve şirket içinde saklayın.

Ajansla ayrılık

İlişki bitmeden önce tüm dosya ve veritabanı kopyalarını teslim alın.

Sık yapılan hatalar

• Yedeği aynı sunucuda tutmak
• Yedeği web erişimine açık bir klasörde bırakmak (ciddi güvenlik açığı)
• Yalnız dosyaları yedekleyip veritabanını atlamak
• Geri yükleme testi yapmamak
• Sağlayıcının yedeğine tam güvenmek
• E-postaları yedeklememek
• Yedeklerin çalıştığını hiç kontrol etmemek

İkinci madde özellikle tehlikelidir: bulunabilir bir yedek dosyası, sitenizin ve veritabanınızın tamamının kopyalanması demektir.