Veeam/Datto: E-postalar Gönderim Değil Geri Yükleme Tarihini Gösteriyor

Geri yüklemenin ertesi sabahı destek talepleri başlıyor

Veeam Backup for Microsoft 365 ile bir posta kutusu geri yüklemesini yeni tamamladınız. İşlem sorunsuz geçti, veriler yerli yerinde, klasörler eksiksiz. Sonra pazartesi sabahı bir kullanıcıdan mesaj geliyor: "Tüm e-postalarım bugünün tarihini gösteriyor. Hiçbir şeyi bulamıyorum."

Sorun e-postaların kaybolması değil. Hepsi orada. Ama görüntülenen tarihler, e-postaların gönderildiği veya alındığı tarihi değil, geri yüklemenin yapıldığı anı gösteriyor. Ocak 2021'den bir e-posta, dün gece 23:47'de alınmış gibi görünüyor. Konuşma dizisi dağılmış, kronoloji okunamaz hale gelmiş durumda.

Bu davranış Veeam Backup for Microsoft 365, Datto SaaS Protection, Synology Active Backup for Microsoft 365 ve AvePoint Cloud Backup'ta görülüyor. Her biri biraz farklı bir yol izliyor ama sonuç aynı.

Teknik olarak ne oluyor

Yanlış tarihin nereden geldiğini anlamak için bu araçların e-postaları Exchange Online veya Google Workspace'e nasıl yeniden enjekte ettiğine bakmak gerekiyor.

Bir yedekleme aracı bir mesajı geri yüklediğinde, e-postayı yerel diskteki bir dosya gibi "yerine koyamaz". Araç, IMAP üzerinden ya da sağlayıcının API'si üzerinden (Microsoft tarafında EWS veya Microsoft Graph, Google tarafında Gmail API'si) posta kutusuna mesajın yeni bir kopyasını yazıyor. Bu kopyayla birlikte, mesajın hangi tarihi taşıdığını da posta kutusuna bildirmesi gerekiyor.

Sorun tam burada başlıyor. (Bir geri yüklenmiş e-postanın ham başlıklarını okumayı denediniz mi? İçeriğe ulaşmadan önce yirmi satır Received: başlığı geçtiğiniz oluyor.)

IMAP APPEND ve Received: başlığı

IMAP protokolünde APPEND adlı bir komut var. Bu komut bir posta kutusuna mesaj eklemek için kullanılıyor. Geri yükleme araçlarının yaptığı da tam olarak bu: yedeklenen mesajı alıp IMAP APPEND komutuyla hedef kutuya enjekte ediyorlar.

Bu komut, aracın mesajla birlikte bir tarih iletmesine izin veriyor. Araç mesajın özgün tarihini iletirse posta kutusu bu tarihi koruyor: Microsoft 365, Outlook.com ve Gmail'in hepsi böyle yapıyor. Hiçbir tarih iletmezse veya geri yükleme tarihini iletirse, posta kutusu e-postayı geri yükleme gününe kaydediyor. Mesajı yeniden yazmanın bazı yolları ise en üste bir satır daha ekliyor: kopyalama gününe damgalı bir Received: başlığı. Gmail'in kendi içe aktarma API'si tam olarak bunu yapıyor.

Bu ek satır şuna benziyor:

Received: by gmailapi.google.com
  with HTTPREST; Mon, 14 Apr 2025 23:47:12 +0000

Sonuç: özgün Date: başlığı (diyelim ki "3 Jan 2021 09:15:00") mesajın içinde sağlam duruyor. Ama en üste, geri yükleme anının tarihini taşıyan yeni bir Received: başlığı yapıştırılmış.

Outlook ve Gmail tarihi nasıl okuyor

Outlook veya Gmail web arayüzü gibi e-posta istemcileri, mesaj listesinde gösterilecek tarihi belirlemek için her zaman Date: başlığını kullanmıyor. Büyük çoğunluğu IMAP protokolünün INTERNALDATE değerini (mesajın kutuya eklendiği tarihi) ya da en son Received: başlığını esas alıyor.

Özellikle 2023 sonu güncellemesinden itibaren Outlook, başlık zincirinin tepesinde yakın tarihli bir Received: başlığı gördüğünde bunu görüntüleme tarihi olarak kullanıyor. Özgün Date: başlığı mesaj özelliklerinde kalmaya devam ediyor ama bunu görmek için e-postanın özelliklerini elle açmak gerekiyor.

Kullanıcı, mesaj listesinde hepsini geri yüklemenin yapıldığı gece tarihli olarak görüyor. Üç yıllık e-posta geçmişi tek bir geceye sıkışmış gibi görünüyor.

Bu sorun migrasyondan farklı

IMAP migrasyonundan sonra yaşanan klasik tarih sorunundan ayırt etmek gerekiyor. Migrasyonda araç, e-postaları A sunucusundan B sunucusuna taşıyor ve her e-postanın tarihini koruyup korumaması, aracın yazarken B sunucusuna ne söylediğine bağlı. Mekanizma aynı, bağlam farklı.

Burada bir yedekten geri yükleme söz konusu. E-postalar hiç organizasyonu terk etmedi, yalnızca bir yerde güvende tutuldu (Azure Blob Storage, AWS S3, Datto appliance...) ve sonra yeniden enjekte edildi. Kullanıcı bunu daha az bekliyor: ona göre "kendi" e-postaları geri geliyor, içe aktarılan e-postalar değil.

Ama teknik açıdan mekanizma aynı. Özgün tarihi taşımayan bir yeniden enjeksiyon, aynı artefaktları üretiyor. Düzeltme de aynı mantığı takip ediyor.

Her araç INTERNALDATE'i nasıl yönetiyor (ya da yönetemiyor)

Tüm araçlar tam olarak aynı şekilde davranmıyor, asıl ilginç olan da bu.

Veeam Backup for Microsoft 365

Veeam, Exchange Online'a geri yükleme için EWS (Exchange Web Services) API'sini kullanıyor. EWS, DateTimeReceived alanı aracılığıyla mesaj tarihinin belirtilmesine olanak tanıyor; ancak bu değer her zaman IMAP katmanındaki INTERNALDATE'e yansımıyor. Sonuç: geri yükleme farklı bir kutuya yapıldığında (örneğin alternatif bir kutuya granüler geri yükleme) Outlook'taki sıralama tarihi özgün tarihle örtüşmeyebiliyor.

Datto SaaS Protection

Datto, yapılandırmaya göre Microsoft Graph API veya IMAP üzerinden geri yükleme yapıyor. Her iki durumda da posta kutusunun gösterdiği tarih, geri yüklemenin her mesajın özgün tarihini iletip iletmediğine bağlı. Datto kullanan MSP'ler bu sorunla oldukça sık karşılaşıyor, özellikle yüzlerce kutunun acil olarak geri yüklendiği fidye yazılımı olaylarının ardından. Ve tam o anda tüm tarihlerin yanlış olduğunu keşfetmek istemezsiniz.

AvePoint ve Synology Active Backup

AvePoint Cloud Backup ve Synology Active Backup for Microsoft 365 benzer mekanizmaları izliyor. AvePoint bu davranışı bilgi tabanında belgelemiş (mesaj geri yükleme tarihi, görünen alım tarihi olarak atanıyor) ama yerel bir düzeltme sunmuyor. Synology Active Backup'ta da aynı sorun var ve geri yükleme arayüzünün "mesaj tarihi" ile "geri yükleme tarihi" arasında net bir ayrım yapmadığı düşünüldüğünde, durum daha da kafa karıştırıcı hale gelebiliyor.

İyi haber: özgün tarih hâlâ orada

Durumu kurtarılabilir kılan şey, mesajın özgün Date: başlığının değiştirilmemiş olması. Geri yüklenen her e-postada, başlığın içinde, dokunulmadan duruyor. Geri yükleme, posta kutusunun kaydettiği tarihi değiştirdi ve bazen üstüne bir Received: satırı ekledi, ama mesajın içeriğine dokunmadı.

Bu, MIME formatının (RFC 2822) bir özelliği: bir mesajın iç yapısı değişmez. Received: başlıkları üst üste katman olarak birikir ama özgün bilgiler altta sağlam kalır.

Yani bilgiyi kaybetmediniz. Sadece bir yeniden enjeksiyon artefaktının arkasında gizlenmiş durumda.

Geri yüklemeyi yeniden çalıştırmak neden çözüm değil

Akla gelen ilk fikir: geri yüklenen e-postaları silip, bu sefer tarihlerin doğru geleceği umuduyla geri yüklemeyi yeniden başlatmak. Bu iyi bir fikir değil, birkaç nedenden dolayı.

Her şeyden önce, geri yükleme araçları ikinci seferde farklı davranmayacak. Aynı araç, aynı ayarlar: e-postalar özgün tarihleri olmadan aynı şekilde geri yazılıyor. Tamamen aynı sonucu alırsınız.

Üstelik üretim kutularında geri yüklemeyi yeniden çalıştırmak zaman, bant genişliği ve risk demek. Her birinde 20.000 mesaj olan 50 kutuda, bu birkaç saatlik bir işlem oluyor; API'ler meşgul kalıyor, Microsoft veya Google tarafında hız sınırı tetikleyebiliyor (sabah 2'de batch sırasında gelen o meşhur 429 Too Many Requests hatası).

Kısacası: geri yükleme çalıştı. Veriler yerinde. Düzeltilmesi gereken tarih artefaktı, geri yüklemenin kendisi değil.

Kendiniz düzeltmeye çalışmanın somut riskleri

Sorunu anlamak bir şey. 80.000 e-postayı tek bir kayıp olmadan düzeltmek bambaşka bir şey.

IMAP mesajlarını gezip tarihleri düzelten bir Python scripti yazılabilir gibi görünüyor. 50 test e-postasında gayet iyi çalışır. Üretimde iş değişiyor. Uç durumlar birikmeye başlıyor: S/MIME ile imzalanmış e-postalar (başlığı değiştirmek kriptografik imzayı geçersiz kılıyor), PGP şifreli mesajlar, standart dışı MIME sınırları olan çok parçalı yapılar, RFC 2047 ile kodlanmış başlıklar (ASCII dışı karakterler), scriptin belleğini taşıran 40 MB'lık ekler. Bir de kısmen yeniden çalıştırılan geri yüklemelerde olduğu gibi birden fazla Received: başlığı eklenmiş mesajlar var, bunlar daha ince bir tespit mantığı gerektiriyor.

Açıkçası, asıl risk çöken script değil: hatasız çalışıyor gibi görünen ama bozuk mesajlar üreten script. Dağılmış konuşma dizileri. Yinelenmiş e-postalar. Ayrılan ekler. Belki bunu ancak haftalar sonra, bir kullanıcı önemli bir e-postayı bulmaya çalışırken fark edersiniz.

Peki değişiklikten sonra düzeltilen her e-postanın gerçekten sağlam olduğunu nasıl doğrularsınız? Ev yapımı bir script bunu genellikle yapmıyor.

Redate.io'nun farkı ne

Redate.io, yeniden enjeksiyon artefaktlarını tespit etmek için her e-postanın başlık zincirini analiz ediyor; ister Veeam geri yüklemesinden, ister BitTitan migrasyonundan, ister manuel içe aktarmadan kaynaklansın. Özel düzeltme motorunun hasarı hangi aracın verdiğini bilmesine gerek yok: görüntülenen tarihi özgün tarihiyle uyuşmayan e-postaları arıyor, böylece kimsenin adını bile duymadığı bir araç bile yakalanıyor.

Herhangi bir şeyi düzeltmeden önce Redate.io tüm kutuyu tarayıp bir rapor sunuyor: kaç e-posta etkilenmiş, yanlış tarih ne, tespit edilen özgün tarih ne. Bu tarama ücretsiz. Harekete geçmeye karar vermeden önce sorunun boyutunu görüyorsunuz.

Her e-posta düzeltmeden sonra tek tek doğrulanıyor. Özgünler, gerektiğinde tam güvenlik ağı sunmak üzere görünür bir yedekleme klasöründe tutuluyor; siz silmediğiniz sürece Redate.io onları kaldırmıyor.

Redate.io, her kullanıcının kendi Microsoft veya Google hesabıyla oturum açmasıyla ilgili kutuyu açıyor; Azure portalına gidip bir uygulama kaydetmeye gerek yok. Hiçbir e-posta ara sunuculardan geçmiyor. Düzeltme yerinde, kutunun içinde gerçekleşiyor; dışa veya içe aktarma yok.

Aynı anda birden fazla etkilenmiş müşteriyi yöneten MSP'ler için MSP'lere özel sayfaya bakabilirsiniz: Redate.io, tek bir arayüzden birden fazla kutuyu paralel olarak işlemeyi mümkün kılıyor.

Aynı artefaktı üreten diğer senaryolar

Yedekleme aracından geri yükleme tek durum değil. Aynı tarih artefaktı başka koşullarda da ortaya çıkıyor:

• Exchange'den IMAP içe aktarma (arşivlenmiş kutular Exchange Online'a yeniden enjekte edildiğinde)
• Exchange Online'a migrasyon - hedef tarafta IMAP kullanan araçlarla yapıldığında
• Dışa aktarılan ve sonra yeniden içe aktarılan bir PST'den granüler geri yükleme (bkz. PST içe aktarma makalesi)
• Olay sonrasında yeniden oluşturulan paylaşımlı posta kutuları (bkz. paylaşımlı kutu tarih düzeltmesi)

Tüm bu durumlarda altta yatan mekanizma aynı: özgün tarihi taşımayan bir yeniden enjeksiyon (bazen üstüne yeni bir Received: başlığı ekleyerek) ve e-posta istemcisi bu yeni tarihi referans olarak gösteriyor.

E-postalar yerinde, özgün tarih her mesajın içinde korunuyor. Redate.io'da ücretsiz bir tarama başlatın ve kutunuzdaki kaç e-postanın etkilendiğini tam olarak görün; ardından düzeltmeyi başlatıp başlatmamaya karar verin.