Kurumunuz ne kadar dijital? Üç dakikalık ölçümle öğrenin. Endeksinizi ölçün →
Thro

E-Posta Yedekleme

4 dk okuma Barındırma ve Bulut Altyapı Kurumsal E-Posta

Sağlayıcıda duruyor demek, yedeklendi demek değildir.

"E-postalarımız bulutta, yedeğe gerek yok" cümlesi yaygın ve yanlıştır. Sağlayıcı altyapı arızasına karşı koruma sağlar; kullanıcı hatasına, ele geçirmeye ya da hesap kaybına karşı değil.

Hangi senaryolara karşı?

SenaryoSağlayıcı korur mu?
Sunucu arızasıEvet
Kullanıcı yanlışlıkla sildiKısa süre
Ele geçirilen hesapta toplu silmeKısıtlı
Hesap kapatıldıHayır
Sağlayıcı değişimiHayır
Sağlayıcıyla anlaşmazlıkHayır
Uzun geçmişe erişimKısıtlı
Fidye yazılımıKısmen

Dördüncü satır kritiktir: Ödeme yapılmadığı ya da hesap kapatıldığı için erişim kesildiğinde, veriler belirli bir süre sonra silinir.

1. Adım — Kapsamı belirleyin

  • ☐ Hangi hesaplar yedeklenecek?
  • ☐ Paylaşımlı kutular dahil mi?
  • ☐ Rol adresleri dahil mi?
  • ☐ Ayrılan çalışan arşivleri dahil mi?
  • ☐ Takvim ve kişiler dahil mi?
  • ☐ Ekler dahil mi?

İkinci madde: destek@ ve bilgi@ gibi kutular genelde en değerli geçmişi taşır ama yedekleme kapsamında unutulur.

2. Adım — Yöntemi seçin

Sağlayıcının yedekleme hizmeti

Bazı sağlayıcılar ek bir yedekleme seçeneği sunar.

Avantaj: Entegre, kolay.

Dikkat: Aynı sağlayıcıya bağımlılık devam eder.

Bağımsız yedekleme hizmeti

Üçüncü taraf bir hizmet, e-postalarınızı ayrı bir yerde saklar.

Avantaj: Sağlayıcıdan bağımsız, sağlayıcı değişiminde koruma.

Dikkat: Ek maliyet, yeni bir veri işleyen ilişkisi.

Yerel yedekleme

Mesajların bir dosyaya aktarılması.

Avantaj: Düşük maliyet, tam kontrol.

Dikkat: Manuel süreç, cihaza bağımlılık, arama zorluğu, güvenlik riski.

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

  • ☐ Ne sıklıkla yedek alınacak?
  • ☐ Kabul edilebilir kayıp süresi belirlendi
  • ☐ Kritik kutular daha sık yedekleniyor mu?
  • ☐ Otomatik çalışıyor mu?

İkinci madde: Günlük yedek alıyorsanız, en kötü senaryoda bir günlük yazışmayı kaybedersiniz. Bu sizin için kabul edilebilir mi?

4. Adım — Saklama süresini belirleyin

  • ☐ Yedekler ne kadar saklanacak?
  • ☐ Kaç sürüm tutulacak?
  • ☐ Saklama politikasıyla uyumlu mu?
  • ☐ Silinen verinin yedekte kalması değerlendirildi

Dördüncü madde bir uyum konusudur: Saklama politikanız gereği silinen bir veri, yedekte yaşamaya devam ediyorsa politikanız fiilen uygulanmıyor demektir.

5. Adım — Güvenliği sağlayın

  • ☐ Yedekler şifreli saklanıyor
  • ☐ Erişim sınırlı
  • ☐ Erişim kayıt altında
  • ☐ Ayrı bir konumda
  • ☐ Ana sistemden bağımsız kimlik doğrulaması

Beşinci madde: E-posta hesabınız ele geçirildiğinde yedeğinize de erişilebiliyorsa, yedek koruma sağlamaz.

6. Adım — Geri getirmeyi test edin

  • ☐ Tek bir mesaj geri getirildi
  • ☐ Bir klasör geri getirildi
  • ☐ Tüm bir kutu geri getirildi
  • ☐ Süre ölçüldü
  • ☐ Ekler eksiksiz geldi
  • ☐ Tarih bilgileri korundu
  • ☐ Test kayıt altına alındı

Bu adım atlanamaz. Denenmemiş bir yedek, yedek sayılmaz. Test edilmeyen yedeklerin ihtiyaç anında çalışmadığı sıkça görülür.

7. Adım — Sorumluluğu tanımlayın

  • ☐ Yedekten kim sorumlu?
  • ☐ Başarısız yedek uyarısı kime gidiyor?
  • ☐ Geri getirme talebi nasıl yapılıyor?
  • ☐ Onay gerekiyor mu?
  • ☐ Test kim tarafından yapılıyor?

İkinci madde: Sessizce başarısız olan bir yedekleme, aylarca fark edilmeyebilir.

8. Adım — İzleyin

  • ☐ Yedek başarı durumu izleniyor
  • ☐ Başarısızlıklar araştırılıyor
  • ☐ Yedek boyutu takip ediliyor
  • ☐ Yeni hesaplar kapsama ekleniyor
  • ☐ Kapatılan hesaplar değerlendiriliyor

Dördüncü madde: Yeni açılan bir hesabın yedeklemeye eklenmesi, hesap açma sürecinin bir parçası olmalıdır.

Sağlayıcı değişimi senaryosu

Yedeklemenin en somut değer ürettiği durum budur:

  • ☐ Geçmiş yazışmalar bağımsız bir yerde
  • ☐ Geçiş sırasında kayıp olsa bile kurtarma mümkün
  • ☐ Eski sağlayıcıya bağımlılık yok
  • ☐ Sözleşme sonrası veri erişimi güvence altında

Fidye yazılımı senaryosu

  • ☐ Yedekler ana sistemden ayrı
  • ☐ Yedeklere yazma erişimi kısıtlı
  • ☐ Geçmiş sürümler saklanıyor
  • ☐ Bulaşma öncesi bir sürüme dönülebiliyor

İkinci madde: Ana sistemden erişilebilen yedekler, zararlı yazılım tarafından da şifrelenebilir.

Yaygın hatalar

  • "Bulutta, yedeğe gerek yok" varsayımı
  • Yalnız kullanıcı bilgisayarında saklamak
  • Geri getirmeyi hiç denememek
  • Paylaşımlı kutuları kapsam dışı bırakmak
  • Yedek başarısızlığını izlememek
  • Yedeği aynı hesapla erişilebilir yapmak
  • Saklama politikasıyla çelişmek
  • Yeni hesapları kapsama eklememek

Asgari düzen

Kaynağınız kısıtlıysa şu dört madde temel korumayı sağlar:

  1. Kritik kutular (yönetim, mali işler, müşteri ilişkileri, paylaşımlı kutular) yedekleniyor
  2. Yedek ana sistemden bağımsız bir yerde
  3. Geri getirme yılda en az bir kez test ediliyor
  4. Sorumlu kişi belli
Paylaş:
T
Thro
Thro · 12 Ağustos 2026

Yorumlar (0)

Henüz yorum yok — ilk yorumu siz yazın.

Yorum yaz