Veeam/Datto: emaile datowane przywróceniem, nie wysyłką

Dzień po przywróceniu danych zaczynają się zgłoszenia

Właśnie zakończono przywracanie skrzynki pocztowej za pomocą Veeam Backup for Microsoft 365. Operacja przebiegła pomyślnie, dane są na miejscu, foldery nienaruszone. A w poniedziałek rano użytkownik pisze: „Wszystkie moje emaile mają dzisiejszą datę. Nie mogę nic znaleźć."

Problem nie polega na tym, że emaile zniknęły. Są. Ale wyświetlana data odpowiada dokładnej godzinie przywrócenia, nie dacie, kiedy wiadomości zostały wysłane lub odebrane. Email ze stycznia 2021 roku pojawia się jako odebrany wczoraj wieczorem o 23:47. Wątek rozmowy jest zepsuty. Chronologia nieczytelna.

To zachowanie dotyczy Veeam Backup for Microsoft 365, Datto SaaS Protection, Synology Active Backup for Microsoft 365 i AvePoint Cloud Backup, między innymi. Każde z tych narzędzi działa nieco inaczej, ale efekt jest identyczny.

Co się dzieje od strony technicznej

Żeby zrozumieć, skąd bierze się błędna data, trzeba przyjrzeć się temu, jak te narzędzia ponownie wstrzykują emaile do skrzynki Exchange Online lub Google Workspace.

Kiedy narzędzie backupowe przywraca wiadomość, nie może po prostu „wstawić jej z powrotem" jak przenoszenia pliku na lokalnym dysku. Zapisuje nową kopię wiadomości w skrzynce, przez IMAP albo przez API dostawcy (EWS lub Microsoft Graph po stronie Microsoftu, API Gmaila po stronie Google). Wraz z tą kopią musi przekazać skrzynce, jaką datę niesie wiadomość.

I tu zaczyna się problem. (Swoją drogą, jeśli kiedykolwiek przeglądano surowe nagłówki przywróconego emaila, pewnie można było zobaczyć kilkanaście linii Received: zanim w ogóle dotarto do treści wiadomości.)

Polecenie IMAP APPEND i nagłówek Received:

Protokół IMAP dysponuje poleceniem APPEND, służącym do wstawiania wiadomości do skrzynki pocztowej. Dokładnie z tego korzysta narzędzie do przywracania: pobiera zapisaną wiadomość i wstrzykuje ją do docelowej skrzynki przez IMAP APPEND.

To polecenie pozwala narzędziu przekazać datę wraz z wiadomością. Jeśli narzędzie przekaże oryginalną datę wiadomości, skrzynka ją zachowuje: tak działają Microsoft 365, Outlook.com i Gmail. Jeśli nie przekaże żadnej daty, albo przekaże datę przywrócenia, email trafia do skrzynki z datą przywrócenia. A niektóre sposoby zapisu wiadomości dodają jeszcze jedną linię na górze: nagłówek Received: datowany dniem kopii. Dokładnie to robi własne API importu Gmaila.

Ta dodatkowa linia wygląda mniej więcej tak:

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

Efekt: oryginalny email jest nienaruszony w środku, z oryginalnym nagłówkiem Date: (powiedzmy „3 Jan 2021 09:15:00"). Ale nowy nagłówek Received: został przyklejony na samej górze, datowany na moment przywrócenia.

Jak Outlook i Gmail odczytują datę

Klienty pocztowe takie jak Outlook czy webowy interfejs Gmaila nie zawsze korzystają z nagłówka Date: przy decydowaniu, jaką datę wyświetlić na liście wiadomości. Wiele z nich używa INTERNALDATE protokołu IMAP, czyli daty, w której wiadomość została dodana do skrzynki, albo najnowszego nagłówka Received:.

Outlook dla Windows, szczególnie po aktualizacji z końca 2023 roku, jest na to wyjątkowo wrażliwy. Gdy widzi świeży nagłówek Received: na szczycie łańcucha, używa go jako daty wyświetlania. Oryginalny Date: trafia do szczegółów wiadomości, widocznych dopiero po otwarciu właściwości emaila.

Użytkownik końcowy widzi więc listę wiadomości, gdzie wszystkie są datowane na noc przywrócenia. Jego trzyletnia historia korespondencji spłaszczyła się do jednej nocy.

Ten problem różni się od migracji

Warto odróżnić tę sytuację od klasycznego problemu błędnych dat po migracji IMAP. Przy migracji narzędzie przenosi emaile z serwera A na serwer B, a to, czy każdy email zachowa swoją datę, zależy od tego, co narzędzie przekaże serwerowi B podczas zapisu. Mechanizm jest ten sam, ale kontekst inny.

Tu mowa o przywróceniu z kopii zapasowej. Emaile nigdy nie opuściły organizacji, zostały tylko zabezpieczone gdzieś (Azure Blob Storage, AWS S3, urządzenie Datto...) i ponownie wstrzyknięte. Użytkownik tym bardziej tego nie oczekuje: dla niego wracają „jego" emaile, nie jakieś zaimportowane wiadomości.

Ale technicznie mechanizm jest identyczny. Ponowne wstrzyknięcie, które nie przenosi oryginalnej daty, produkuje te same artefakty. I naprawa też przebiega według tej samej logiki.

Jak poszczególne narzędzia obsługują (lub nie) INTERNALDATE

Poszczególne narzędzia nie zachowują się dokładnie tak samo i tu zaczyna się robić ciekawie.

Veeam Backup for Microsoft 365

Veeam korzysta z API EWS (Exchange Web Services) do przywracania do Exchange Online. EWS pozwala na podanie daty wiadomości przez pole DateTimeReceived, ale ta wartość nie zawsze jest przenoszona na INTERNALDATE na poziomie IMAP. Efekt: data sortowania w Outlooku może nie odpowiadać oryginalnej dacie, szczególnie gdy przywrócenie odbywa się do skrzynki innej niż oryginalna (granularne przywracanie do alternatywnej skrzynki).

Datto SaaS Protection

Datto przywraca przez Microsoft Graph API lub IMAP, w zależności od konfiguracji. W obu przypadkach to, jaką datę pokaże skrzynka, zależy od tego, czy przywrócenie przekazuje oryginalną datę każdej wiadomości. MSP korzystający z Datto dla swoich klientów napotykają na ten problem dość regularnie, zwłaszcza po incydentach ransomware, gdy w trybie awaryjnym przywraca się kilkaset skrzynek naraz. To nie jest moment na odkrycie, że wszystkie daty są błędne.

AvePoint i Synology Active Backup

AvePoint Cloud Backup i Synology Active Backup for Microsoft 365 działają według podobnych mechanizmów. AvePoint opisało to zachowanie w swojej bazie wiedzy (wiadomość jest przywracana z datą przywrócenia jako widoczną datą odbioru), nie oferując jednak natywnego rozwiązania. Synology Active Backup ma ten sam problem, potęgowany przez to, że interfejs przywracania nie rozróżnia wyraźnie „daty wiadomości" od „daty przywrócenia".

Dobra wiadomość: oryginalna data jest nadal obecna

To, co sprawia, że sytuacja jest do naprawienia, to fakt, że oryginalny nagłówek Date: wiadomości nie został zmieniony. Nadal jest obecny, nienaruszony, w każdym przywróconym emailu. Przywrócenie zmieniło datę zapisaną przez skrzynkę, a czasem dodało też nagłówek Received: na wierzchu, ale nie dotknęło samej treści wiadomości.

To właściwość formatu MIME (RFC 2822): wiadomość jest niezmutowalna w swojej wewnętrznej strukturze. Nagłówki Received: nawarstwiają się na górze jak kolejne warstwy, ale oryginalne informacje pozostają poniżej.

Dane nie zniknęły. Są po prostu zasłonięte artefaktem ponownego wstrzyknięcia.

Dlaczego ponowne przywrócenie to nie rozwiązanie

Pierwszy pomysł, który przychodzi do głowy: usunąć przywrócone emaile i uruchomić przywracanie jeszcze raz, licząc, że tym razem daty będą poprawne. To zły pomysł, z kilku powodów.

Po pierwsze, narzędzia do przywracania nie zachowają się inaczej przy drugim podejściu. To samo narzędzie, te same ustawienia: emaile zostaną zapisane w ten sam sposób, bez swojej oryginalnej daty. Efekt będzie identyczny.

Po drugie, ponowne uruchamianie przywrócenia na skrzynkach produkcyjnych to czas, przepustowość i ryzyko. Przy 50 skrzynkach z 20 000 wiadomości każda mowa o operacji trwającej wiele godzin, która monopolizuje API i może wywołać limity po stronie Microsoftu lub Google (słynne 429 Too Many Requests o drugiej w nocy podczas przetwarzania wsadowego).

Przywrócenie zadziałało. Dane są na miejscu. Do naprawienia jest artefakt daty, nie samo przywrócenie.

Samodzielna naprawa: konkretne ryzyka

Zrozumienie problemu to jedno. Naprawienie go na 80 000 emailach bez utraty ani jednego to zupełnie co innego.

Skrypt w Pythonie, który przegląda wiadomości IMAP i poprawia daty, może wydawać się wykonalny. Na 50 testowych emailach będzie działał świetnie. W środowisku produkcyjnym to inna historia. Przypadki brzegowe się mnożą: emaile podpisane S/MIME (modyfikacja nagłówka unieważnia podpis kryptograficzny), wiadomości zaszyfrowane PGP, struktury multipart z niestandardowymi granicami MIME, nagłówki zakodowane zgodnie z RFC 2047 (znaki spoza ASCII), załączniki o rozmiarze 40 MB wysadzające pamięć skryptu. No i emaile z wieloma nagłówkami Received: (gdy przywrócenie było uruchamiane częściowo kilka razy), wymagające bardziej zaawansowanej logiki wykrywania.

Właściwie największe ryzyko to nie skrypt, który się zawiesza: to skrypt, który działa bez widocznych błędów, ale produkuje błędne wiadomości. Zepsute wątki konwersacji. Duplikaty. Odłączone załączniki. Które można wykryć dopiero kilka tygodni później, gdy użytkownik próbuje odnaleźć ważny email.

Jak zweryfikować, że każdy poprawiony email jest rzeczywiście nienaruszony po modyfikacji? Domowy skrypt zazwyczaj tego nie robi.

Co Redate.io robi inaczej

Redate.io analizuje łańcuch nagłówków każdego emaila, żeby zidentyfikować artefakty ponownego wstrzyknięcia, niezależnie od tego, czy pochodzą z przywrócenia Veeam, migracji BitTitan, czy ręcznego importu. Autorski silnik korekcji nie musi wiedzieć, które narzędzie spowodowało problem: wyszukuje emaile, których wyświetlana data nie zgadza się z ich oryginalną datą, dzięki czemu wykrywa nawet narzędzie, o którym nikt wcześniej nie słyszał.

Zanim cokolwiek zostanie poprawione, Redate.io skanuje całą skrzynkę i przedstawia raport: ile emaili jest dotkniętych problemem, jaka jest błędna data, jaka oryginalna data została wykryta. Ten skan jest bezpłatny. Widać skalę problemu przed podjęciem decyzji o działaniu.

Każdy email jest weryfikowany indywidualnie po korekcji. Oryginały są zachowywane w widocznym folderze kopii zapasowej aż do momentu, gdy użytkownik sam je usunie, co daje pełną siatkę bezpieczeństwa w razie potrzeby.

Redate.io otwiera skrzynkę bezpośrednio po zalogowaniu się użytkownika własnym kontem Microsoft lub Google, bez przesyłania emaili przez serwery pośrednie. Korekcja odbywa się na miejscu, w skrzynce, bez eksportu ani reimportu.

MSP obsługujące wielu klientów dotkniętych problemem jednocześnie mogą zapoznać się z dedykowaną stroną dla MSP: Redate.io pozwala przetwarzać kilka skrzynek równolegle z jednego interfejsu.

Inne scenariusze prowadzące do tego samego artefaktu

Przywrócenie z narzędzia backupowego to nie jedyny przypadek. Ten sam artefakt daty pojawia się w innych sytuacjach:

• Import IMAP z Exchange (zarchiwizowane skrzynki ponownie wstrzyknięte do Exchange Online)
• Migracja do Exchange Online z narzędziami korzystającymi z IMAP po stronie docelowej
• Granularne przywrócenie z PST wyeksportowanego i ponownie zaimportowanego (patrz artykuł o imporcie PST)
• Skrzynki współdzielone odtworzone po incydencie (patrz naprawa dat w skrzynkach współdzielonych)

We wszystkich tych przypadkach mechanizm jest identyczny: ponowne wstrzyknięcie nie przenosi oryginalnej daty (czasem dodając na wierzchu nowy nagłówek Received:), a klient pocztowy pokazuje tę nową datę jako referencyjną.

Emaile są na miejscu, oryginalna data jest zachowana w każdej wiadomości. Uruchom bezpłatny skan na Redate.io i sprawdź dokładnie, ile emaili jest dotkniętych problemem w Twojej skrzynce, a następnie zdecyduj, czy uruchomić korekcję.