Mail Sunucusu Taşıma Planı: Kesintisiz Geçiş

Web sitesi taşımak yanlış giderse birkaç dakika kesinti yaşarsın ve geri alırsın. Mail sunucusu taşımak yanlış giderse kaybolan mesajlar bir daha geri gelmez — ve bunu genellikle günler sonra "size şu tarihte mail atmıştım" cümlesiyle öğrenirsin. Bu yüzden mail sunucusu taşıma işi bir komut dizisi değil, sıralı bir plandır: hangi adımın hangi gün yapılacağı, hangi anda geri dönüş yolunun kapandığı önceden belli olmalıdır.

Bu rehberde iki IMAP sunucusu arasında kutuları kaybetmeden geçmenin gün gün planını anlatacağım: envanter çıkarma, yeni sunucuyu MX'i değiştirmeden test etme, TTL'i zamanında düşürme, imapsync ile ilk ve delta senkronizasyonları, MX kesim anı ve sonrasındaki bir haftalık gözetim dönemi. Ayrıca en çok veri kaybettiren tuzakları — POP3 kullanıcıları, sieve filtreleri, DKIM anahtarları — ayrı bir bölümde topladım.

Önce Envanter: Neyi Taşıdığını Bilmeden Başlama#

Taşımanın en sık atlanan adımı, taşınacak şeyin tam listesini çıkarmaktır. Posta kutuları listenin yalnızca bir kalemidir; yanlarında taşınmayan her şey geçiş gecesinde kaybolur. Elle bir tablo çıkar ve her satırın karşısına "taşındı / taşınmayacak" yaz.

Toplam veri boyutunu ölçmek, senkronizasyonun ne kadar süreceğini kestirmek için şart. Kaba bir hesap için hesaplamayı önceden yap: 40 GB'lık bir kutu havuzu, 100 Mbit'lik bir hatta ideal koşullarda bile bir saatin üzerinde sürer ve IMAP protokolü bunu asla ideal koşullarda yapmaz. Aktarım süresini kabaca kestirmek için bant genişliği hesaplayıcısını kullanabilirsin.

# Tüm hesapların kota ve kullanım özeti
doveadm quota get -A

# Maildir dizinlerinin gerçek disk kullanımı
du -sh /var/mail/vhosts/*/* | sort -h | tail -20

Zaman Çizelgesi: Hangi Adım Hangi Gün#

Taşımayı tek bir geceye sıkıştırmaya çalışmak en pahalı hatadır. Aşağıdaki çizelge, orta ölçekli bir kurulum (birkaç alan adı, 50-200 kutu) için gerçekçi bir dağılımdır. Küçük kurulumlarda süreleri kısaltabilirsin ama sırayı değiştirme.

1. T-14 gün — Envanter. Yukarıdaki tabloyu doldur, kullanıcılara istemci protokollerini sor, taşınmayacak hesapları belirle.
2. T-10 gün — Yeni sunucuyu kur. Postfix, Dovecot, TLS sertifikası, alan adları, kutular ve alias'lar hazır olsun. Henüz hiçbir DNS kaydına dokunma.
3. T-7 gün — Kör test. Yeni sunucuya /etc/hosts üzerinden ya da doğrudan IP ile bağlanıp gönderme ve alma testi yap. TLS, kimlik doğrulama ve LMTP teslimatını doğrula.
4. T-3 gün — TTL'i düşür. MX ve mail A kaydının TTL değerini 300 saniyeye indir. Bu adım geri dönüşü dakikalar seviyesine çeker.
5. T-2 gün — İlk tam senkronizasyon. Tüm kutuları imapsync ile kopyala. Bu en uzun süren adımdır ve arka planda çalışabilir.
6. T-0 sabah — Delta senkronizasyon. İkinci imapsync turu yalnızca aradaki farkı taşır, dakikalar sürer.
7. T-0 kesim — MX değişimi. MX kaydını yeni sunucuya çevir. Eski sunucuyu kapatma; kabul etmeye devam etsin.
8. T-0 akşam — Üçüncü tur. Eski sunucuya geçiş anında düşen son mesajları taşımak için tekrar senkronize et.
9. T+1 ile T+7 — Gözetim. Günde bir kez delta senkronizasyonu tekrarla, eski sunucunun loglarını izle, gecikmiş çözümleyicilerden gelen mesajları yakala.
10. T+30 — Kapatma. Eski sunucuda haftalardır mesaj düşmüyorsa hizmeti durdur, verinin bir kopyasını arşivle.

Kesim gününü asla cuma seçme. Bir aksilik çıkarsa hafta sonu boyunca hem sen hem kullanıcılar sorunla baş başa kalırsınız; salı ya da çarşamba sabahı en makul tercihtir.

Yeni Sunucuyu MX'e Dokunmadan Test Etmek#

Geçişin en değerli adımı, canlıya almadan önce yeni sunucunun gerçekten çalıştığını kanıtlamaktır. Bunu DNS'e dokunmadan yapabilirsin: kendi makinende /etc/hosts dosyasına yeni IP'yi yazıp istemcini o sunucuya bağlarsın.

# Yerel makinede /etc/hosts satırı (yalnızca senin bilgisayarında geçerli)
185.12.34.56    mail.firmaniz.com

# TLS ve kimlik doğrulama testi
openssl s_client -connect mail.firmaniz.com:993 -crlf
# a LOGIN [email protected] parola
# a OK Logged in.

# SMTP gönderim testi (submission portu)
openssl s_client -starttls smtp -connect mail.firmaniz.com:587 -crlf

Bu turda şunları tek tek doğrula: sertifika hostname ile eşleşiyor mu, IMAP girişi başarılı mı, gönderilen mesaj dış dünyaya ulaşıyor mu, dış dünyadan gelen mesaj doğru kutuya düşüyor mu, sieve filtreleri çalışıyor mu. Port, TLS modu ve PTR uyumunu tek ekranda görmek için SMTP test aracımızı kullanabilirsin.

imapsync ile Kutuları Taşımak#

imapsync, iki IMAP sunucusu arasında mesajları kopyalayan ve tekrar çalıştırıldığında yalnızca farkı taşıyan bir araçtır. Artımlı çalışması, çok turlu geçiş planının temelidir. Tek bir hesap için temel kullanım şöyle:

imapsync \
  --host1 eski.firmaniz.com --user1 [email protected] --password1 'eski-parola' \
  --host2 mail.firmaniz.com --user2 [email protected] --password2 'yeni-parola' \
  --ssl1 --ssl2 \
  --automap \
  --skipsize \
  --logfile /var/log/imapsync/ali.log

Toplu taşıma için hesapları bir dosyada topla ve döngüye sok. Parolaları düz metin tutmak istemiyorsan yönetici (master) parolası desteğini kullan; Dovecot'ta bir master kullanıcı tanımlayıp tüm kutulara tek parolayla erişebilirsin:

# hesaplar.txt biçimi: kullanici;eski_parola;yeni_parola
while IFS=';' read -r kullanici eski yeni; do
  imapsync --host1 eski.firmaniz.com --user1 "$kullanici" --password1 "$eski" \
           --host2 mail.firmaniz.com --user2 "$kullanici" --password2 "$yeni" \
           --ssl1 --ssl2 --automap \
           --logfile "/var/log/imapsync/${kullanici}.log" &
  # Aynı anda en fazla 4 hesap
  while [ "$(jobs -r | wc -l)" -ge 4 ]; do sleep 5; done
done < hesaplar.txt
wait

Eşzamanlılığı abartma. Aynı anda yirmi hesabı senkronize etmek diski ve IMAP sunucusunu tıkar, sonuç toplamda daha yavaş biter. Dört ile sekiz arası paralellik çoğu sunucuda en iyi dengeyi verir. Kutu aktarımının kullanıcı tarafındaki adımlarını ve tek tek hesap taşıma yöntemlerini e-postaları yeni sunucuya taşıma yazısında bulabilirsin.

Kesim Anı ve Geri Dönüş#

MX kaydını değiştirdiğin an, dünyanın bir kısmı hâlâ eski sunucuya mesaj göndermeye devam eder — çünkü eski kaydı TTL süresi boyunca önbelleğinde tutar. Bu yüzden eski sunucuyu kesim anında kapatmak, doğrudan mesaj kaybı demektir. Eski sunucu en az bir hafta, tercihen bir ay boyunca mesaj kabul etmeye devam etmelidir.

; Kesim öncesi (T-3): TTL düşürülmüş hâli
firmaniz.com.        300   IN   MX  10  eski.firmaniz.com.

; Kesim anı (T-0): yeni sunucu birincil, eski yedek MX olarak kalıyor
firmaniz.com.        300   IN   MX  10  mail.firmaniz.com.
firmaniz.com.        300   IN   MX  20  eski.firmaniz.com.

Eski sunucuyu ikincil MX olarak bırakmak yerine, gelen mesajları doğrudan yeni sunucuya aktarmasını da sağlayabilirsin. Postfix'te bu, alan adını aktarım listesine alıp transport_maps ile yönlendirmek demektir:

# Eski sunucuda /etc/postfix/main.cf
relay_domains = firmaniz.com
transport_maps = hash:/etc/postfix/transport

# /etc/postfix/transport
firmaniz.com    smtp:[mail.firmaniz.com]

Köşeli parantez, Postfix'e hedef için MX araması yapmamasını söyler; yoksa mesaj kendi kendine geri döner. Geri dönüş senaryon da net olmalı: MX'i eski değerine çevirmek TTL sayesinde dakikalar sürer, ama geçiş sonrası yeni sunucuya düşen mesajları ters yönde senkronize etmen gerekir. Bu yüzden geri dönüş kararını ilk saatler içinde ver; bir gün sonra iki sunucuda da farklı mesajlar birikmiş olur.

Sık Yapılan Hatalar ve Tuzaklar#

POP3 kullanıcılarını atlamak. POP3 ile "sunucudan sil" ayarını kullanan bir kullanıcının eski mesajları sunucuda değil, kendi bilgisayarındadır. Sen sunucuyu taşırsın, kutu boş görünür, kullanıcı da "tüm maillerim gitti" der. Taşımadan önce kimlerin POP3 kullandığını mutlaka sor; farkı bilmiyorsan IMAP ile POP3 arasındaki fark yazısı işi netleştirir.

Sieve betiklerini ve otomatik yanıtları taşımamak. imapsync yalnızca mesajları taşır; filtre kuralları ve tatil yanıtları kullanıcı dizinindeki sieve dosyalarında durur. Bunları ayrıca kopyalaman gerekir.

# Eski sunucudan sieve betiklerini al
rsync -av /var/mail/vhosts/firmaniz.com/*/sieve/ \
          [email protected]:/var/mail/vhosts/firmaniz.com/

DKIM anahtarını yeniden üretmek. Yeni sunucuda yeni bir DKIM anahtar çifti üretip DNS'i güncellersen, geçiş anında yolda olan mesajların imzası doğrulanamaz. En temiz yöntem eski özel anahtarı yeni sunucuya kopyalamak; mümkün değilse yeni bir seçici (selector) ile ikinci anahtarı önceden yayınla ve iki seçiciyi bir süre birlikte tut.

SPF kaydını geçiş boyunca güncellememek. Kesim döneminde iki sunucu da mesaj gönderiyor olabilir. SPF kaydında her iki IP'yi de listele, geçiş bittikten sonra eskisini kaldır.

TTL'i düşürmeyi unutmak. 86400 TTL'li bir MX kaydıyla kesim yaparsan, geri dönmen gerektiğinde bir gün beklersin. TTL düşürme kesim gününde değil, en az 48 saat önce yapılır.

Kullanıcıları haberdar etmemek. İstemci ayarları değişecekse (sunucu adı, port, TLS modu) kullanıcılara önceden yazılı talimat gönder. Outlook tarafındaki adımlar için e-posta istemci kurulumu yazısını paylaşabilirsin.

Sıkça Sorulan Sorular#

Mail sunucusu taşıma ne kadar sürer#

Toplam süre kutu sayısından çok toplam veri boyutuna ve IMAP sunucularının hızına bağlıdır. Kaba bir ölçek olarak, birkaç on GB'lık bir havuz için ilk tam senkronizasyon birkaç saat, sonraki delta turları ise dakikalar sürer. Planın tamamı — envanterden gözetim dönemine kadar — iki haftaya yayıldığında kesinti neredeyse sıfıra iner; asıl süreyi belirleyen kopyalama değil, DNS yayılmasını bekleme dönemidir.

Taşıma sırasında hiç mesaj kaybolur mu#

Doğru planlandığında hayır. Kaybı önleyen üç şey var: kesim anında eski sunucuyu kapatmamak, MX değişiminden sonra en az bir hafta boyunca delta senkronizasyonu tekrarlamak ve TTL'i önceden düşürmek. Mesaj kaybı neredeyse her zaman eski sunucunun erken kapatılmasından ya da tek turlu senkronizasyondan kaynaklanır.

imapsync ücretsiz mi#

imapsync açık kaynaklıdır ve kaynak kodundan derlediğinde ücretsiz kullanılır; proje sahibi ayrıca hazır derlenmiş paketler için ücretli bir dağıtım da sunar. Çoğu Linux dağıtımının depolarında ya da kaynak arşivinden kurulum yapabilirsin. Alternatif olarak Dovecot'un dsync aracı, her iki uç da Dovecot ise daha hızlı ve daha sadık bir kopyalama yapar.

MX kaydını değiştirdikten sonra ne kadar sürede yayılır#

Yayılma süresi doğrudan eski MX kaydının TTL değerine bağlıdır. TTL'i kesimden 48 saat önce 300 saniyeye indirdiysen, çoğu gönderen sunucu yeni kaydı beş dakika içinde görür. TTL'e hiç dokunmadıysan ve değer 86400 ise, bazı sunucular bir gün boyunca eski adrese göndermeye devam eder. Geçiş planındaki TTL adımının tek amacı budur.

Eski sunucuyu ne zaman kapatabilirim#

En erken 30 gün sonra. Kapatmadan önce eski sunucunun mail loglarını kontrol et: son bir haftada hiç yeni teslimat yoksa güvenle durdurabilirsin. Kapatmadan önce tüm kutuların ve veritabanının tam bir yedeğini al ve bu yedeği en az bir yıl sakla; geçmişe dönük bir mesaj talebi geldiğinde tek kaynağın bu olur.

Kullanıcı parolalarını yeni sunucuya nasıl taşırım#

Her iki sunucu da aynı hash şemasını kullanıyorsa (örneğin SHA512-CRYPT), hash değerlerini olduğu gibi kopyalayabilirsin; kullanıcılar mevcut parolalarıyla giriş yapmaya devam eder. Şemalar farklıysa ya da eski sistem parolaları geri döndürülemez biçimde tutuyorsa herkese yeni parola üretip yazılı olarak iletmen gerekir. Bu durumda geçişi kullanıcı bilgilendirmesiyle aynı güne planla, aksi halde destek trafiği ikiye katlanır.

Kapanış#

Mail taşımasını başarılı kılan şey araç değil, sıradır. Aklında kalması gereken dört alışkanlık şunlar: taşınacak her şeyin envanterini önce çıkar, TTL'i kesimden en az 48 saat önce düşür, senkronizasyonu tek turda değil en az üç turda yap ve eski sunucuyu kesim anında kapatma — bir ay boyunca mesaj kabul etmeye devam etsin. Kesim gününü de haftanın ortasına al ki bir aksilikte ekibin çalışır durumda olsun.

Bu planı tek başına yürütmek istemiyorsan Clou.TR tarafında işin büyük kısmını devralabiliriz. Kutuların ve DNS kayıtlarının aktarımı için site taşıma hizmetimiz, hazır yapılandırılmış bir hedef sunucu için SMTP sunucu paketlerimiz, hesap yönetimini tamamen bırakmak istersen kurumsal e-posta çözümlerimiz uygun başlangıç noktalarıdır. Geçiş öncesi ve sonrası kutu yedeklerini otomatikleştirmek için yedekleme hizmetimize de bakmanı öneririm.