Veeam/Datto: emailek a visszaállítás dátumával

Másnap reggel jönnek a panaszok

Befejezte a postafiók-visszaállítást a Veeam Backup for Microsoft 365-tel. Az operáció simán ment, az adatok megvannak, a mappák érintetlenek. Aztán hétfő reggel érkezik az első üzenet az egyik felhasználótól: "Minden emailem mai dátumú. Semmit nem találok."

Nem az a probléma, hogy eltűntek az emailek. Ott vannak. De a megjelenített dátumuk a visszaállítás pontos időpontja, nem az, amikor küldték vagy megkapták őket. Egy 2021 januári email úgy szerepel, mintha tegnap este 23:47-kor érkezett volna. A levelezési szál széttöredezik. Az időrend olvashatatlan lesz.

Ez a viselkedés érinti a Veeam Backup for Microsoft 365-öt, a Datto SaaS Protectiont, a Synology Active Backup for Microsoft 365-öt és az AvePoint Cloud Backupot is, hogy csak a legismertebbeket említsük. Mindegyik kicsit másképp csinálja, de az eredmény ugyanaz.

Mi történik technikai szinten

Ahhoz, hogy megértsük, honnan ered a hibás dátum, meg kell néznünk, hogyan injektálják vissza ezek az eszközök az emaileket egy Exchange Online vagy Google Workspace postafiókba.

Amikor egy backup eszköz visszaállít egy üzenetet, nem tudja egyszerűen "visszahelyezni" az emailt, ahogy egy fájlt áthelyeznénk egy helyi lemezen. Az eszköz egy új másolatot ír az üzenetről a postafiókba, IMAP-on keresztül, vagy a szolgáltató API-ján keresztül (EWS vagy Microsoft Graph a Microsoft oldalán, a Gmail API a Google oldalán). És ezzel a másolattal együtt közölnie kell a postafiókkal, milyen dátumot visel az üzenet.

És itt kezdődik a baj. (Ha egyébként már olvasott visszaállított email nyers fejléceit, valószínűleg látott húsz sor Received: fejlécet, mielőtt eljutott az érdemi tartalomig.)

IMAP APPEND és a Received: fejléc

Az IMAP protokollban van egy APPEND nevű parancs. Arra való, hogy üzenetet szúrjunk be egy postafiókba. Pontosan ezt használja egy visszaállító eszköz: fogja a mentett üzenetet, és az IMAP APPEND paranccsal injektálja be a célpostafiókba.

Amikor az Exchange Online vagy a Google Workspace fogadja az üzenetet ezen a parancs útján, ez a parancs lehetővé teszi, hogy az eszköz dátumot adjon át az üzenettel együtt. Ha az eszköz átadja az üzenet eredeti dátumát, a postafiók megtartja azt: a Microsoft 365, az Outlook.com és a Gmail is így tesz. Ha nem ad át semmit, vagy a visszaállítás napját adja meg, a postafiók a visszaállítás napjára teszi az e-mailt. És némelyik visszaírási mód még hozzáad egy sort az üzenet tetejéhez: egy Received: fejlécet, amely a másolás napjára van datálva. A Gmail saját importáló API-ja pontosan ezt teszi.

Ez a plusz sor valahogy így néz ki:

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

Eredmény: az eredeti email belül érintetlen, megvan az eredeti Date: fejléce (mondjuk "3 Jan 2021 09:15:00"). De a tetejére ragasztottak egy új Received: fejlécet, a visszaállítás időpontjával.

Hogyan olvassa az Outlook és a Gmail a dátumot

Az olyan levelezőkliensek, mint az Outlook vagy a Gmail webes felülete, nem mindig a Date: fejlécből veszik az üzenetlistában megjelenített dátumot. Sokan az IMAP protokoll INTERNALDATE értékét használják, vagyis azt az időpontot, amikor az üzenetet a postafiókba helyezték, vagy a legfrissebb Received: fejlécet.

A Windows-os Outlook, különösen a 2023 végén megjelent frissítés óta, különösen érzékeny erre. Ha a fejlécláncban legfelül egy friss Received: fejlécet talál, azt használja megjelenítési dátumként. Az eredeti Date: fejléc az üzenet részleteibe szorul, csak akkor látható, ha valaki megnyitja az email tulajdonságait.

A végfelhasználó tehát egy üzenetlistát lát, ahol minden a visszaállítás éjszakájának dátumát mutatja. Számára háromévnyi levélváltás összesűrűsödött egyetlen éjszakába.

Ez más, mint egy migrációs probléma

Érdemes megkülönböztetni ezt az IMAP-migráció utáni hibás dátumok klasszikus esetétől. Migrációnál az eszköz áthelyezi az emaileket az A szerverről a B szerverre, és hogy minden email megtartja-e a dátumát, az attól függ, mit közöl az eszköz a B szerverrel az írás során. A mechanizmus ugyanaz, de a kontextus más.

Itt visszaállításról van szó egy biztonsági mentésből. Az emailek soha nem hagyták el a szervezetet, csak biztonságba kerültek valahol (Azure Blob Storage, AWS S3, Datto appliance...), majd visszainjektálták őket. A felhasználó ezt különösen nem várja: számára "az ő" emailjei térnek vissza, nem importált levelek.

Technikai szempontból azonban a mechanizmus azonos. Az eredeti dátumot át nem adó visszainjektálás ugyanolyan mellékterméket produkál. A javítás logikája is ugyanaz.

Hogyan kezeli (vagy nem kezeli) az egyes eszközök az INTERNALDATE-et

Nem minden eszköz viselkedik teljesen egyformán, és itt válik érdekessé a dolog.

Veeam Backup for Microsoft 365

A Veeam EWS (Exchange Web Services) API-t használ az Exchange Online-ba való visszaállításhoz. Az EWS lehetővé teszi az üzenet dátumának megadását a DateTimeReceived mezőn keresztül, de ez az érték nem mindig tükröződik az IMAP-szintű INTERNALDATE-ben. Eredmény: az Outlookban megjelenő rendezési dátum nem feltétlenül egyezik az eredeti dátummal, különösen ha a visszaállítás egy másik postafiókba történik (például részleges visszaállítás alternatív postafiókba).

Datto SaaS Protection

A Datto Microsoft Graph API-n vagy IMAP-on keresztül állít vissza, a konfigurációtól függően. Mindkét esetben az, hogy a postafiók milyen dátumot jelenít meg, attól függ, hogy a visszaállítás átadja-e az egyes üzenetek eredeti dátumát. Az MSP-k, akik a Dattót ügyfeleik számára használják, elég rendszeresen találkoznak ezzel a problémával, főleg zsarolóvírus-incidensek utáni sürgős visszaállításoknál, amikor egyszerre több száz postafiókot kell visszaállítani. Ilyen pillanatban nem jó felfedezni, hogy minden dátum helytelen.

AvePoint és Synology Active Backup

Az AvePoint Cloud Backup és a Synology Active Backup for Microsoft 365 hasonló mechanizmusokat követ. Az AvePoint dokumentálta ezt a viselkedést a tudásbázisában (az üzenet a visszaállítás dátumával jelenik meg látható fogadási dátumként), anélkül azonban, hogy natív javítást kínálna. A Synology Active Backup ugyanezt a problémát mutatja, tovább tetézve azzal, hogy a visszaállítási felület nem tesz egyértelműen különbséget az "üzenet dátuma" és a "visszaállítás dátuma" között.

Jó hír: az eredeti dátum még mindig ott van

Ami a helyzetet megmenthetővé teszi: az üzenet eredeti Date: fejléce nem módosult. Minden visszaállított emailben ott van, érintetlenül. A visszaállítás megváltoztatta a postafiók által rögzített dátumot, és néha rárakott egy Received: sort is, de magát az üzenet tartalmát nem nyúlt hozzá.

Ez a MIME formátum (RFC 2822) egyik tulajdonsága: az üzenet belső szerkezete megváltoztathatatlan. A Received: fejlécek rétegként halmozódnak fel a tetején, de az eredeti információk alattuk maradnak.

Tehát nem veszett el az adat. Csak el van takarva egy visszainjektálási melléktermék által.

Miért nem megoldás a visszaállítás megismétlése

Az első gondolat általában: törölni a visszaállított emaileket és újraindítani a visszaállítást, hátha most jók lesznek a dátumok. Ez rossz ötlet, több okból is.

Először is, a visszaállító eszközök másodszorra sem fognak másképp viselkedni. Ugyanaz az eszköz, ugyanazok a beállítások: az e-maileket ugyanúgy írja vissza, az eredeti dátumuk nélkül. Pontosan ugyanazt az eredményt kapja.

Másrészt, éles üzemű postafiókokba való visszaállítás újraindítása időt, sávszélességet és kockázatot jelent. 50 postafiók, egyenként 20 000 üzenettel: ez több órás művelet, amely lefoglalja az API-kat, és Microsoft- vagy Google-oldali sebességkorlátozásokat válthat ki (a jól ismert 429 Too Many Requests hiba hajnali 2-kor, a batch közepén).

Röviden: a visszaállítás sikerült. Az adatok megvannak. Amit javítani kell, az a dátum-mellékterméke, nem maga a visszaállítás.

Saját javítás: a konkrét kockázatok

A problémát megérteni egy dolog. 80 000 emailen egyetlen elvesztett üzenet nélkül kijavítani, az egészen más lapra tartozik.

Egy Python-szkript, amely végigmegy az IMAP-üzeneteken és javítja a dátumokat, megvalósíthatónak tűnhet. 50 tesztemailen remekül is fog működni. Éles környezetben más a helyzet. A szélső esetek felhalmozódnak: S/MIME-mel aláírt emailek (a fejléc módosítása érvényteleníti a kriptográfiai aláírást), PGP-titkosított üzenetek, nem szabványos MIME-határokat tartalmazó multipart struktúrák, RFC 2047 szerint kódolt fejlécek (nem ASCII), 40 MB-os mellékletek, amelyek szétrobbantják a szkript memóriáját. Aztán ott vannak az emailek több hozzáadott Received: fejléccel (ha a visszaállítást részlegesen újraindították, ami előfordul), amelyek finomabb detektálási logikát igényelnek.

Az igazi kockázat pontosabban fogalmazva nem a szkript, amelyik elszáll: hanem az, amelyik hiba nélkül fut, de sérült üzeneteket produkál. Összetört levelezési szálak. Duplikátumok. Leváló mellékletek. Amelyeket talán csak hetek múlva vesz észre valaki, amikor egy felhasználó megpróbál visszakeresni egy fontos emailt.

És hogyan ellenőrzi, hogy minden javított email valóban épségben van módosítás után? Egy házilagos szkript ezt általában nem teszi meg.

Mit csinál másképp a Redate.io

Redate.io elemzi minden email fejlécláncát, hogy azonosítsa a visszainjektálási mellékterméket, legyen szó Veeam-visszaállításról, BitTitan-migrációról vagy kézi importról. A saját fejlesztésű javítómotornak nincs szüksége arra, hogy tudja, melyik eszköz okozta a hibát: azokat az e-maileket keresi, amelyeknek a megjelenített dátuma nem egyezik az eredeti dátumukkal, így egy addig ismeretlen eszköz is felismerhető.

Mielőtt bármit javítana, Redate.io átvizsgálja a teljes postafiókot, és egy jelentést mutat: hány email érintett, mi a helytelen dátum, és mi az azonosított eredeti dátum. Ez a szkennelés ingyenes. Látja a probléma teljes mértékét, mielőtt dönt a továbbiakról.

Minden egyes emailt egyenként ellenőriz a javítás után. Az eredetik egy látható biztonsági mentési mappában maradnak, és a Redate.io soha nem törli őket, amíg Ön maga nem dönt erről.

Redate.io a saját Microsoft- vagy Google-fiókjával történő bejelentkezésen keresztül nyitja meg a postafiókot, egyetlen email sem halad át köztes szervereken. A javítás helyben, a postafiókban történik, exportálás és reimportálás nélkül.

MSP-k számára, akik egyszerre több érintett ügyfelet kezelnek, hasznos lehet a MSP-knek szóló oldal: Redate.io lehetővé teszi több postafiók párhuzamos kezelését egyetlen felületről.

Más esetek, amelyek ugyanolyan mellékterméket produkálnak

A backup eszközből való visszaállítás nem az egyetlen eset. Ugyanez a dátum-mellékterméke más helyzetekben is megjelenik:

• IMAP-import Exchange-ből (archivált postafiókokat injektálnak vissza Exchange Online-ba)
• Migráció Exchange Online-ra IMAP-ot céloldalon használó eszközökkel
• Részleges visszaállítás exportált és visszaimportált PST-ből (lásd a PST-import cikket)
• Incident után rekonstruált megosztott postafiókra vonatkozóan lásd a megosztott postafiókokra vonatkozó javítási útmutatót

Minden ilyen esetben az alapmechanizmus azonos: egy visszainjektálás, amely nem adja át az eredeti dátumot (néha egy új Received: fejléccel a tetején), és egy levelezőkliens, amely ezt az új dátumot tekinti referenciának.

Az emailek megvannak, az eredeti dátum megőrződött minden egyes üzenetben. Indítson el egy ingyenes szkennelést a Redate.io-n, hogy pontosan lássa, hány email érintett a postafiókjában, és döntse el, szeretné-e elindítani a javítást.