Mail Sunucusu Yedekleme Stratejisi

Bir web sitesini kaybedersen kötü bir gün geçirirsin; bir mail sunucusunu kaybedersen şirketin kurumsal hafızasını kaybedersin. Sözleşme yazışmaları, sipariş onayları, müşteriyle yapılan pazarlıklar, muhasebe kayıtları — hepsi posta kutularında durur ve hiçbiri başka bir yerde yedeklenmiş değildir. Mail sunucusu yedekleme stratejisi bu yüzden "arada bir dosyaları kopyalamak" değil, geri dönüş süresi ve veri kaybı toleransı üzerine kurulmuş bir plandır.

Bu rehberde önce mail yedeklemesinin neden diğer yedeklemelerden farklı olduğunu, sonra tam olarak neyin yedeklenmesi gerektiğini (posta kutularının çok ötesinde bir liste) anlatacağım. Ardından iki temel yöntemi —dosya sistemi seviyesinde ve IMAP/dsync seviyesinde— çalışan komutlarla göstereceğim, şifreleme ve saklama süresi kararlarına gireceğim ve en sona en çok atlanan adımı bırakacağım: geri dönüşü gerçekten test etmek. Çünkü denenmemiş yedek, yedek değildir; sadece bir umuttur.

Mail Yedeklemesi Neden Farklı#

Bir web sitesinin yedeği kolaydır çünkü içerik yavaş değişir ve bütünlüğü tek bir anda yakalanabilir. Mail sunucusu ise saniyede değişir: yeni mesaj gelir, kullanıcı okur, taşır, siler. Bu üç özellik yedekleme tasarımını doğrudan etkiler.

Birincisi, çok sayıda küçük dosya vardır. Maildir biçiminde her mesaj ayrı bir dosyadır; 100 kullanıcılık orta ölçekli bir sunucuda milyonlarca dosya olur. Bu, yedekleme süresini boyuttan çok dosya sayısının belirlemesi demektir. 50 GB'lık bir veritabanı dosyasını kopyalamak dakikalar sürer, 50 GB'lık iki milyon mail dosyasını kopyalamak saatler.

İkincisi, tutarlılık sorunu vardır. Yedek alırken bir mesaj taşınıyorsa, yedeğe hem eski hem yeni konumda ya da hiçbirinde düşebilir. Dovecot'un indeks dosyaları da posta dosyalarıyla senkron olmalıdır; birini alıp diğerini almazsan geri dönüşte tutarsız bir kutu elde edersin.

Üçüncüsü, geri dönüş genelde kısmi olur. Gerçek hayatta "tüm sunucuyu geri yükle" senaryosu nadirdir; asıl talep "Ahmet üç hafta önceki bir maili silmiş, geri getirir misin?" şeklinde gelir. Yani yedekleme sistemin tek bir posta kutusunu, hatta tek bir klasörü geri getirebilmelidir.

Neyi Yedekleyeceksin: Bileşen Envanteri#

Yedekleme planı yazan çoğu kişi /var/vmail dizinini alır ve işi bitmiş sayar. Oysa o dizin tek başına sunucuyu geri getirmez. İşte tam envanter:

Bu tablodaki DKIM özel anahtarını özellikle işaretledim çünkü en sık atlanan ve kaybı en sinsi olan öğedir. Anahtarı kaybedersen sunucu çalışmaya devam eder, mailler gider, hiçbir hata görmezsin — ama imzalar artık DNS'teki genel anahtarla doğrulanmaz ve teslimat oranın sessizce düşer. Yeni anahtar üretip DNS kaydını güncellemen ve yayılmasını beklemen gerekir.

Veritabanı yedeğini de mail dosyalarıyla aynı çalışmada almalısın; hesap tablosu ile posta kutuları arasındaki tutarsızlık, geri dönüşte "kutu var ama hesap yok" durumu yaratır:

# Sanal kullanıcı veritabanını tutarlı biçimde dök
mysqldump --single-transaction --quick --routines \
  --databases mailserver > /yedek/mailserver-$(date +%F).sql

# Yapılandırma dizinlerini tek arşivde topla
tar czf /yedek/mail-config-$(date +%F).tar.gz \
  /etc/postfix /etc/dovecot /etc/opendkim /etc/letsencrypt

3-2-1 Kuralı ve RPO/RTO Kararı#

Yedekleme planının iskeleti iki sayıdır. RPO (Recovery Point Objective), en fazla ne kadarlık veri kaybını göze aldığındır: günde bir yedek alıyorsan RPO'n 24 saattir, yani en kötü senaryoda bir günlük mail kaybolur. RTO (Recovery Time Objective) ise geri dönüşün ne kadar sürebileceğidir. Bu iki sayıyı belirlemeden yöntem seçemezsin.

Bunun üstüne klasik 3-2-1 kuralını uygula: verinin 3 kopyası olsun, 2 farklı ortamda dursun, 1 kopya fiziksel olarak başka yerde bulunsun. Mail sunucusu bağlamında pratik karşılığı şudur: canlı sunucudaki asıl veri (1), aynı veri merkezindeki yedek deposu (2) ve başka bir konumdaki uzak kopya (3). Uzak kopya olmadan, veri merkezindeki bir yangın ya da hesabının kapanması her iki kopyayı da götürür.

Bir de sık atlanan ayrım var: yedek ile yüksek erişilebilirlik aynı şey değildir. İki sunucu arasında canlı senkronizasyon kurmak kesintiye karşı korur ama silmeye karşı korumaz — bir kullanıcı maili sildiğinde silme işlemi de anında karşıya gider. Bu yüzden replikasyon varken bile zamana yayılmış, geriye dönüp bakılabilen yedeklere ihtiyacın vardır.

Yöntem 1: Dosya Sistemi Seviyesinde Yedek#

En yaygın yöntem, posta dizinini blok ya da dosya seviyesinde kopyalamaktır. Ham rsync yerine tekilleştirme ve şifreleme yapan bir araç kullanmak, milyonlarca küçük dosyada devasa fark yaratır. Borg bu iş için iyi bir seçimdir:

# Depoyu bir kez oluştur (şifreli)
borg init --encryption=repokey-blake2 /yedek/mail-repo

# Gecelik yedek — arşiv adına tarih damgası koy
borg create --stats --compression zstd,3 \
  /yedek/mail-repo::mail-{now:%Y-%m-%d} \
  /var/vmail /etc/postfix /etc/dovecot /etc/opendkim /etc/letsencrypt

# Saklama politikası: son 7 gün, 4 hafta, 6 ay
borg prune -v --list /yedek/mail-repo \
  --keep-daily=7 --keep-weekly=4 --keep-monthly=6

# Depo bütünlüğünü düzenli olarak doğrula
borg check --verify-data /yedek/mail-repo

Tutarlılık için yedeği bir anlık görüntü (snapshot) üzerinden almak en temiz yoldur. LVM kullanıyorsan:

# Anlık görüntü oluştur, bağla, yedekle, kaldır
lvcreate -L 10G -s -n vmail-snap /dev/vg0/vmail
mount -o ro /dev/vg0/vmail-snap /mnt/snap
borg create /yedek/mail-repo::mail-{now:%Y-%m-%d} /mnt/snap
umount /mnt/snap
lvremove -f /dev/vg0/vmail-snap

Anlık görüntü alamıyorsan, en azından yedeği trafiğin en düşük olduğu saatte çalıştır ve Dovecot'un indeks dosyalarını da aynı çalışmaya dahil et. Yedeği asla aynı diske yazma: aynı diskteki kopya, disk arızasına karşı hiçbir koruma sağlamaz. Uzak bir depoya kopyalamak için ayrı bir adım ekle ve o depoya yalnızca ekleme yetkisi ver; fidye yazılımı bulaşan bir sunucunun kendi yedeklerini silmesi, sahada gerçekten yaşanan bir senaryodur.

Yöntem 2: IMAP ve dsync Seviyesinde Yedek#

Dosya seviyesindeki yedek hızlıdır ama tek bir maili geri getirmek için arşivi açıp doğru dosyayı bulman gerekir. Posta kutusunun mantıksal yapısını koruyan yöntem ise Dovecot'un kendi dsync motorudur. doveadm backup komutu, kutuyu klasör yapısı, bayrakları ve UID'leriyle birlikte kopyalar:

# Tek kullanıcıyı yerel bir Maildir'e yedekle
doveadm backup -u [email protected] maildir:/yedek/kutular/ahmet

# Tüm kullanıcılar için döngü
for KULLANICI in $(doveadm user '*' 2>/dev/null); do
  doveadm backup -u "$KULLANICI" \
    "maildir:/yedek/kutular/${KULLANICI}"
done

# İki sunucu arasında çift yönlü senkron (ikincil sunucuya)
doveadm sync -u [email protected] \
  remote:[email protected]

Önemli bir uyarı: doveadm backup hedefi kaynakla aynı hâle getirir, yani kaynakta silinen mesaj hedefte de silinir. Bu, arşiv değil ayna oluşturur. Silinen maili geri getirebilmek istiyorsan bu aynanın üstüne zamana yayılmış anlık görüntüler koymalısın — örneğin ayna dizinini borg ile günlük arşivlemek. İki katmanı birlikte kullanmak, hem hızlı kısmi geri dönüş hem de geçmişe erişim sağlar.

Farklı bir sunucuya taşıma ya da harici bir hizmetten yedek alma senaryosunda imapsync daha uygundur, çünkü yalnızca IMAP protokolünü konuşur ve sunucuya kök erişimi gerektirmez:

imapsync \
  --host1 mail.firmaniz.com --user1 [email protected] --password1 'Parola1' \
  --host2 yedek.firmaniz.com --user2 [email protected] --password2 'Parola2' \
  --ssl1 --ssl2 --automap --skipcrossduplicates

Tek bir hesabın kendi yedeğini alması gereken durumlarda (kullanıcının kendi arşivi, iş değişikliği, hesap kapanışı) daha basit bir yol vardır; bunu e-posta hesabı yedekleme yazısında ayrıca anlattım.

Şifreleme, Saklama Süresi ve Erişim Kontrolü#

Posta kutuları kişisel veri içerir; yedekleri de aynı hassasiyetle ele alınmalıdır. Üç kural:

1. Yedek deposu şifreli olsun. Borg'un repokey şifrelemesi ya da depolama tarafında şifreleme kullan; şifrelemeden uzak bir depoya mail göndermek, veriyi kontrolün dışına çıkarmak demektir.
2. Anahtar yedekten ayrı dursun. Şifreleme anahtarını yedeğin yanında tutarsan şifreleme anlamsızlaşır; anahtarı ayrı ve güvenli bir yerde sakla, kaybedersen yedeğe erişemezsin.
3. Erişim yetkisi dar olsun. Yedek deposuna yazan hesap silme yetkisine sahip olmamalı; mümkünse yalnızca ekleme yapabilen bir kimlik kullan.

Saklama süresini belirlerken iki baskı çatışır: yasal saklama yükümlülükleri uzun süre saklamayı gerektirebilir, kişisel verinin gereğinden uzun tutulmaması ise aksini söyler. Pratik bir orta yol, kademeli saklamadır:

Yedek boyutunu planlarken kota üst sınırını temel al: kullanıcı sayısı × kota, deponun büyüyebileceği tavanı verir. Kota ayarlarını nasıl kuracağını Dovecot kota yönetimi yazısında bulabilirsin. Aktarım hacminin bant genişliğine etkisini kabaca görmek istersen bant genişliği hesaplayıcı aracı işini kolaylaştırır.

Geri Dönüş Tatbikatı ve Sık Yapılan Hatalar#

Bu bölüm yazının en önemli kısmı. Yedekleme sistemlerinin büyük çoğunluğu, ihtiyaç duyulduğu ilk gün çalışmadıklarını gösterir — çünkü hiç denenmemişlerdir. Üç ayda bir, takvime koyduğun bir tatbikat yap:

# 1) Arşivleri listele — beklediğin tarih aralığı var mı?
borg list /yedek/mail-repo

# 2) TEK bir kullanıcının kutusunu geçici bir dizine çıkar
mkdir -p /tmp/geri-donus && cd /tmp/geri-donus
borg extract /yedek/mail-repo::mail-2026-08-20 var/vmail/firmaniz.com/ahmet

# 3) İçeriği doğrula: mesaj sayısı ve en yeni mail tarihi
find /tmp/geri-donus -type f -name '*' | wc -l
ls -lt /tmp/geri-donus/var/vmail/firmaniz.com/ahmet/cur | head -3

# 4) Geri yükle ve izinleri düzelt (Dovecot okuyamazsa kutu boş görünür)
chown -R vmail:vmail /var/vmail/firmaniz.com/ahmet
doveadm force-resync -u [email protected] '*'

Dördüncü adımdaki force-resync komutunu atlama: dosyalar geri yüklendiğinde Dovecot'un indeksleri eskidir ve kutu istemcide eksik ya da boş görünebilir. Yeniden indeksleme bunu düzeltir. Tatbikatın sonunda ölçmen gereken tek sayı şudur: başlangıçtan doğrulanmış geri dönüşe kadar geçen süre. O sayı senin gerçek RTO'ndur; planda yazan değil.

Şimdi en sık gördüğüm hatalar. Birincisi, yalnızca posta dizinini yedeklemek; yapılandırma, veritabanı ve DKIM anahtarı olmadan sunucuyu geri getiremezsin. İkincisi, yedeği aynı sunucunun aynı diskine yazmak; disk arızasında iki kopya birden gider. Üçüncüsü, replikasyonu yedek sanmak; silinen mail anında karşıya da silinir. Dördüncüsü, yedeğin başarılı olduğunu varsayıp çıktıyı izlememek — sessizce başarısız olan bir cron işi, aylarca hiçbir yedek almadan çalışabilir; işin çıkış kodunu bir izleme sistemine bağla. Beşincisi, geri dönüşü hiç denememek. Altıncısı, şifreleme anahtarını yedekle aynı yerde saklamak. Yedincisi, kullanıcı hesabı silindiğinde posta kutusunu hemen kaldırmak; işten ayrılan bir çalışanın kutusu genelde birkaç ay daha gerekir, silmeden önce arşive al.

Sıkça Sorulan Sorular#

Mail sunucusu yedeği ne sıklıkla alınmalı#

Kabul edebileceğin veri kaybı miktarına bağlıdır. Küçük bir ofiste gecelik yedek genelde yeterlidir ve en kötü senaryoda bir günlük mail kaybedersin. Sürekli yazışma yapılan bir işte gün içinde birkaç artımlı yedek almak gerekir. Yoğun kullanımda en pratik model, gün içi sık artımlı yedeklerin üstüne gecelik tam bir arşiv koymaktır.

Sadece posta kutularını yedeklemek yeterli mi#

Hayır, yeterli değil. Sunucuyu sıfırdan ayağa kaldırabilmek için Postfix ve Dovecot yapılandırmalarını, sanal kullanıcı veritabanını, takma ad tablolarını, Sieve betiklerini ve özellikle DKIM özel anahtarını da yedeklemen gerekir. DKIM anahtarını kaybetmek en sinsi olanıdır çünkü hiçbir hata vermez; mailler gitmeye devam eder ama imza doğrulaması kırılır ve teslimat oranın sessizce düşer.

Yedekten tek bir maili nasıl geri getiririm#

Dosya seviyesinde yedek kullanıyorsan arşivden ilgili kullanıcının dizinini geçici bir yere çıkarır, aradığın mesajı bulup posta kutusuna kopyalar ve doveadm force-resync ile yeniden indeksletirsin. dsync tabanlı bir yedeğin varsa, yedek kutusunu ikinci bir hesap olarak IMAP'e bağlayıp mesajı istemciden sürükleyerek taşımak çok daha pratiktir.

Replikasyon yedekleme yerine geçer mi#

Geçmez. Replikasyon donanım arızası ve kesintiye karşı korur ama insan hatasına ve kötü niyete karşı korumaz; bir mail silindiğinde silme işlemi de anında ikinci sunucuya gider. Fidye yazılımı senaryosunda ise şifrelenen dosyalar da replike olur. Bu yüzden replikasyon varken bile zamana yayılmış, geriye dönüp bakılabilen yedeklere ihtiyaç vardır.

Yedeklerimi ne kadar süre saklamalıyım#

Kademeli bir politika en dengeli çözümdür: günlük yedekleri 7-14 gün, haftalıkları 4-8 hafta, aylıkları 6-12 ay saklamak çoğu senaryoyu karşılar. Yasal saklama yükümlülüğü olan yazışmalar için ayrı bir yıllık arşiv kademesi tanımla. Kişisel veri içeren yedeklerin gereğinden uzun tutulmaması gerektiğini de gözet; saklama süresi dolan arşivleri otomatik silen bir politika kur.

Yedekleme sunucuyu yavaşlatır mı#

Milyonlarca küçük dosyayı tararken disk giriş-çıkışını ciddi biçimde meşgul edebilir. Bunu azaltmanın üç yolu var: yedeği trafiğin en düşük olduğu saatte çalıştırmak, anlık görüntü (snapshot) üzerinden alarak canlı dizini uzun süre meşgul etmemek ve tekilleştirme yapan bir araç kullanarak her çalışmada yalnızca değişenleri işlemek. Uzak kopyalamada bant genişliği sınırı koymak da kullanıcı deneyimini korur.

Kapanış#

Mail yedeklemesi, doğru kurulduğunda hiç fark edilmeyen ama yanlış kurulduğunda şirketin hafızasını silen bir sistemdir. Aklında tutman gereken dört alışkanlık şunlar: posta kutularının yanında yapılandırma, veritabanı ve DKIM anahtarını da yedekle, 3-2-1 kuralına uyup en az bir kopyayı başka bir konumda tut, replikasyonu yedek yerine koyma ve üç ayda bir gerçek bir geri dönüş tatbikatı yapıp ölçtüğün süreyi gerçek RTO'n olarak kabul et. Yedekleme işinin çıkış kodunu bir izleme sistemine bağlamak da sessiz başarısızlıkları görünür kılar.

Yedeklerini tutacak ayrı bir alan arıyorsan yedekleme çözümlerimiz mail sunucusundan bağımsız bir konumda saklama imkânı sunar. Mail sunucunu barındıracak makine için tam root erişimli VDS ve bulut sunucu paketlerimize, Postfix ve Dovecot kurulu hâlde teslim edilen bir sistem için SMTP sunucu paketimize bakabilirsin. Yedekleme planını kurmayı ve düzenli tatbikatı bize bırakmak istersen sunucu yönetimi hizmetimiz bu işi de üstlenir.