Veeam/Datto: имейли с дата на възстановяване, не на изпращане

На следващия ден след възстановяването тикетите започват да валят

Току-що завършихте възстановяване на пощенска кутия чрез Veeam Backup for Microsoft 365. Операцията мина добре, данните са налице, папките са непокътнати. И тогава, в понеделник сутринта, потребител ви пише: "Всички мои имейли имат днешна дата. Не мога да намеря нищо."

Проблемът не е, че имейлите са изчезнали. Те са там. Но показваната дата съответства на точния час на възстановяването, не на датата, на която са изпратени или получени. Имейл от януари 2021 г. се появява като получен снощи в 23:47. Нишката на разговора е счупена. Хронологията е нечетима.

Това поведение засяга Veeam Backup for Microsoft 365, Datto SaaS Protection, Synology Active Backup for Microsoft 365 и AvePoint Cloud Backup, наред с други инструменти. Всеки по своя начин, но резултатът е идентичен.

Какво се случва технически

За да разберем откъде идва грешната дата, трябва да погледнем как тези инструменти реинжектират имейлите в пощенска кутия на Exchange Online или Google Workspace.

Когато инструмент за архивиране възстановява съобщение, той не може просто да "върне на място" имейла, както би преместил файл на локален диск. Той записва ново копие на съобщението в пощенската кутия чрез IMAP или чрез API на доставчика (EWS или Microsoft Graph от страна на Microsoft, Gmail API от страна на Google). И заедно с това копие трябва да съобщи на пощенската кутия коя дата носи съобщението.

И точно тук започва проблемът. (Между другото, ако някога сте разглеждали суровите заглавни полета на възстановен имейл, вероятно сте виждали двайсетина реда Received:, преди да стигнете до полезното съдържание.)

IMAP APPEND и заглавното поле Received:

Протоколът IMAP разполага с команда, наречена APPEND. Тя служи за вмъкване на съобщение в пощенска кутия. Именно това използва инструментът за възстановяване: взима архивираното съобщение и го инжектира в целевата кутия чрез IMAP APPEND.

Тази команда позволява на инструмента да подаде дата заедно със съобщението. Ако инструментът подаде оригиналната дата на съобщението, пощенската кутия я запазва: Microsoft 365, Outlook.com и Gmail го правят. Ако не подаде нищо, или подаде датата на възстановяването, пощенската кутия записва имейла под датата на възстановяването. А някои начини на записване на съобщението добавят още един ред отгоре: заглавно поле Received:, датирано с деня на копието. Точно това прави API-то за импортиране на Gmail.

Този допълнителен ред изглежда приблизително така:

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

Резултатът: оригиналният имейл е непокътнат вътре, с оригиналното си заглавно поле Date: (да речем "3 Jan 2021 09:15:00"). Но ново заглавно поле Received: е залепено най-отгоре, датирано от момента на възстановяването.

Как Outlook и Gmail четат датата

Имейл клиентите като Outlook или уеб интерфейса на Gmail не четат винаги заглавното поле Date:, за да определят коя дата да покажат в списъка със съобщения. Много от тях използват INTERNALDATE на протокола IMAP, тоест датата, на която съобщението е добавено в кутията, или най-скорошното заглавно поле Received:.

Outlook за Windows, особено след актуализацията от края на 2023 г., е особено чувствителен към това. Когато види скорошно заглавно поле Received: в началото на веригата, го използва като дата на показване. Оригиналното Date: е изтласкано в детайлите на съобщението, видимо само ако отворите свойствата на имейла.

Крайният потребител вижда списък от съобщения, всички датирани от нощта на възстановяването. За него тригодишната история се е сгромолясала в една единствена нощ.

Този проблем е различен от миграция

Трябва да се прави разлика с класическия проблем с грешни дати след IMAP миграция. При миграция инструментът мести имейли от сървър A към сървър B, а дали всеки имейл запазва датата си, зависи от това какво инструментът съобщава на сървър B при записването му. Механиката е същата, но контекстът е различен.

Тук говорим за възстановяване от архив. Имейлите никога не са напускали организацията, просто са били съхранени някъде (Azure Blob Storage, AWS S3, Datto appliance...) и след това реинжектирани. Потребителят го очаква още по-малко: за него това са "неговите" имейли, които се връщат, не импортирани такива.

Но технически механизмът е същият. Реинжектиране, което не носи оригиналната дата, произвежда същите артефакти. И корекцията следва същата логика.

Как всеки инструмент обработва (или не обработва) INTERNALDATE

Не всички инструменти се държат по абсолютно същия начин, и точно тук нещата стават интересни.

Veeam Backup for Microsoft 365

Veeam използва EWS (Exchange Web Services) API за възстановяване към Exchange Online. EWS позволява задаване на датата на съобщението чрез полето DateTimeReceived, но тази стойност не винаги се отразява на INTERNALDATE на ниво IMAP. Резултат: датата за сортиране в Outlook може да не съответства на оригиналната дата, особено ако възстановяването е към различна кутия от оригиналната (гранулярно възстановяване към алтернативна кутия, например).

Datto SaaS Protection

Datto възстановява чрез Microsoft Graph API или IMAP в зависимост от конфигурацията. И в двата случая датата, която пощенската кутия показва, зависи от това дали възстановяването подава оригиналната дата на всяко съобщение. MSP-тата, които използват Datto за клиентите си, срещат този проблем доста редовно, особено след ransomware инциденти, при които спешно се възстановяват по няколкостотин кутии наведнъж. Това не е моментът да откривате, че всички дати са грешни.

AvePoint и Synology Active Backup

AvePoint Cloud Backup и Synology Active Backup for Microsoft 365 следват подобни механизми. AvePoint е документирал това поведение в своята база знания (съобщението се възстановява с датата на възстановяването като видима дата на получаване), без обаче да предлага собствена корекция. Synology Active Backup показва същия проблем, усилен от факта, че интерфейсът за възстановяване не прави ясно разграничение между "дата на съобщението" и "дата на възстановяването".

Добра новина: оригиналната дата е все още там

Това, което прави ситуацията поправима, е фактът, че оригиналното заглавно поле Date: на съобщението не е променено. То е все още налице, непокътнато, в тялото на всеки възстановен имейл. Възстановяването е променило датата, записана от пощенската кутия, а понякога е добавило и ред Received: отгоре, но не е докоснало самото съдържание на съобщението.

Това е свойство на формата MIME (RFC 2822): съобщението е неизменно в своята вътрешна структура. Заглавните полета Received: се натрупват отгоре като слоеве, но оригиналната информация остава под тях.

Така че не, не сте загубили информацията. Тя е просто скрита зад артефакт от реинжектирането.

Защо повторното възстановяване не е решението

Първата идея, която идва наум: изтрийте възстановените имейли и пуснете отново възстановяването с надеждата, че този път датите ще бъдат верни. Това е лоша идея, по няколко причини.

На първо място, инструментите за възстановяване няма да се държат различно при втория опит. Един и същ инструмент, едни и същи настройки: имейлите се записват обратно по същия начин, без оригиналната им дата. Ще получите абсолютно същия резултат.

Освен това, повторното възстановяване върху продукционни кутии отнема време, честотна лента и носи рискове. При 50 кутии с по 20 000 съобщения говорим за операция от няколко часа, която монополизира API-тата и може да предизвика ограничения на скоростта от страна на Microsoft или Google (известният 429 Too Many Requests в 2 часа сутринта по време на batch-а).

Накратко: възстановяването е работило. Данните са там. Това, което трябва да се коригира, е артефактът на датата, не самото възстановяване.

Самостоятелна корекция: конкретните рискове

Да разберете проблема е едно. Да го коригирате на 80 000 имейла без да изгубите нито един е съвсем друго.

Python скрипт, който обхожда IMAP съобщенията и коригира датите, може да изглежда осъществимо. На 50 тестови имейла ще работи отлично. В продукция е различно. Граничните случаи се натрупват: имейли, подписани с S/MIME (промяната на заглавното поле инвалидира криптографския подпис), PGP криптирани съобщения, multipart структури с нестандартни MIME граници, заглавни полета, кодирани по RFC 2047 (non-ASCII), прикачени файлове от 40 МБ, които взривяват паметта на скрипта. И имейли с няколко добавени заглавни полета Received: (ако възстановяването е пуснато частично повторно, което се случва), изискващи по-фина логика за разпознаване.

За да сме точни: истинският риск не е скриптът, който се срива. Истинският риск е скриптът, който върви без видима грешка, но произвежда повредени съобщения. Счупени нишки на разговори. Дублирания. Откачени прикачени файлове. Неща, които може да забележите едва седмици по-късно, когато потребител се опита да намери важен имейл.

И как ще проверите дали всеки коригиран имейл е наистина непокътнат след промяната? Домашно направен скрипт обикновено не прави това.

Какво прави Redate.io по различен начин

Redate.io анализира веригата от заглавни полета на всеки имейл, за да идентифицира артефактите от реинжектирането, независимо дали идват от възстановяване с Veeam, миграция с BitTitan, или ръчен импорт. Собственият двигател за корекция не се нуждае да знае кой инструмент е причинил проблема: той търси имейли, чиято показана дата не съответства на оригиналната им дата, така че дори непознат инструмент бива засечен.

Преди да коригира каквото и да е, Redate.io сканира цялата пощенска кутия и представя отчет: колко имейла са засегнати, каква е грешната дата, каква е оригиналната разпозната дата. Това сканиране е безплатно. Виждате обхвата на проблема, преди да решите дали да предприемете действие.

Всеки имейл е проверен индивидуално след корекцията. Оригиналите се съхраняват във видима папка в собствената ви пощенска кутия, докато сами решите да ги изтриете, което осигурява пълна предпазна мрежа при нужда.

Всеки потребител се вписва със собствения си акаунт в Microsoft или Google, и Redate.io отваря само тази пощенска кутия, с достъпа, който вписването дава. Няма портал, няма приложение за регистриране. Корекцията се извършва на място, в кутията, без експорт или реимпорт.

За MSP-та, управляващи няколко засегнати клиента едновременно, вижте специалната страница за MSP: Redate.io позволява обработка на множество кутии паралелно от единен интерфейс.

Други сценарии, които произвеждат същия артефакт

Възстановяването от инструмент за архивиране не е единственият случай. Същият артефакт на датата се появява и в други ситуации:

• IMAP импорт от Exchange (архивирани кутии, реинжектирани в Exchange Online)
• Миграция към Exchange Online с инструменти, използващи IMAP от страна на дестинацията
• Гранулярно възстановяване от PST, експортиран и след това реимпортиран (вижте статията за PST импорт)
• Споделени пощенски кутии, реконструирани след инцидент (вижте корекцията на споделени кутии)

Във всички тези случаи основният механизъм е идентичен: реинжектиране, което не носи оригиналната дата (понякога с ново заглавно поле Received: отгоре), и имейл клиент, който показва тази нова дата като референтна.

Имейлите са там, оригиналната дата е запазена във всяко съобщение. Стартирайте безплатно сканиране в Redate.io, за да видите точно колко имейла са засегнати в пощенската ви кутия, и след това решете дали искате да стартирате корекцията.