Veeam/Datto: e-kirjad kuvatakse taastamiskuupäevaga

Taastamise järgmisel hommikul tulevad piletid

Veeam Backup for Microsoft 365 abil on postkasti taastamine lõpetatud. Operatsioon läks hästi, andmed on kohal, kaustad on puutumatud. Ja siis, esmaspäeva hommikul, kirjutab kasutaja: "Kõikidel minu e-kirjadel on tänane kuupäev. Ma ei leia midagi üles."

Probleem ei ole selles, et e-kirjad on kadunud. Nad on seal. Kuid nende kuvatud kuupäev vastab taastamise täpsele ajale, mitte sellele, millal need saadeti või vastu võeti. Jaanuari 2021 e-kiri ilmub justkui eile õhtul kell 23:47 saaduna. Vestluslõim on katki. Kronoloogia on loetamatu.

See käitumine puudutab Veeam Backup for Microsoft 365, Datto SaaS Protection, Synology Active Backup for Microsoft 365 ja AvePoint Cloud Backupit, teiste hulgas. Igaüks omal moel, kuid tulemus on sama.

Mis toimub tehniliselt

Et mõista, kust vale kuupäev pärineb, tuleb vaadata, kuidas need tööriistad e-kirju Exchange Online'i või Google Workspace'i postkasti tagasi süstivad.

Kui varundustööriist taastab sõnumi, ei saa ta lihtsalt e-kirja "tagasi panna" nagu faili kohalikus kettas nihutades. Tööriist kirjutab sõnumi uue koopia postkasti, kasutades IMAP-protokolli või teenusepakkuja API-t (Microsofti poolel EWS või Microsoft Graph, Google'i poolel Gmaili API). Ja koos selle koopiaga peab ta postkastile ütlema, millise kuupäeva sõnum kannab.

Ja siin algab probleem. (Muide, kui olete kunagi taastatud e-kirja toorpäiseid lugenud, olete tõenäoliselt näinud kahtkümmend rida Received: päiseid enne kasulikku sisu.)

IMAP APPEND ja Received: päis

IMAP-protokollil on käsk nimega APPEND. Seda kasutatakse sõnumi postkasti sisestamiseks. Täpselt seda kasutab taastamistööriist: võtab salvestatud sõnumi ja süstib selle sihtkohta IMAP APPEND kaudu.

See käsk lubab tööriistal sõnumiga kaasa anda kuupäeva. Kui tööriist annab kaasa sõnumi algse kuupäeva, jääb see postkastis alles: nii Microsoft 365, Outlook.com kui ka Gmail säilitavad selle. Kui tööriist ei anna kuupäeva kaasa või annab kaasa taastamise kuupäeva, järjestab postkast e-kirja taastamise päeva alla. Ja mõned tagasikirjutamise viisid lisavad veel ühe rea sõnumi ülaossa: Received: päise, mis on dateeritud koopia tegemise päevaga. Täpselt seda teeb Gmaili oma impordi API.

See lisatud rida näeb välja umbes selline:

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

Tulemus: algne e-kiri on seest puutumatu, oma originaalse Date: päisega (ütleme "3 Jan 2021 09:15:00"). Kuid ülaossa on kleebitud uus Received: päis, mis on kuupäevastatud taastamise hetkele.

Kuidas Outlook ja Gmail kuupäeva loevad

Meilikliendid nagu Outlook või Gmaili veebiliides ei loe alati Date: päist sõnumiloendis kuvatava kuupäeva määramiseks. Paljud kasutavad IMAP-protokolli INTERNALDATE väärtust, see tähendab kuupäeva, mil sõnum postkasti lisati, või uusimat Received: päist.

Outlook Windowsi jaoks, eriti alates 2023. aasta lõpu uuendusest, on selle suhtes eriti tundlik. Kui see näeb päiste ahela ülaosas uut Received: päist, kasutab ta seda kuvamiskuupäevana. Algne Date: jääb sõnumi detailidesse, nähtav ainult siis, kui avada e-kirja atribuudid.

Lõppkasutaja näeb seega sõnumiloendit, kus kõik e-kirjad on kuupäevastatud taastamisöö ajale. Tema jaoks on kolme aasta ajalugu kokkuvolditud üheks ööks.

See probleem erineb migratsioonist

Tuleb teha vahet klassikalisel probleemil vale kuupäevadega pärast IMAP-migratsiooni. Migratsioonil liigutab tööriist e-kirju serverist A serverisse B ning see, kas e-kiri säilitab oma kuupäeva, sõltub sellest, mida tööriist serverile B selle kirjutamisel ütleb. Mehhanism on sama, kuid kontekst on erinev.

Siin räägime taastamisest varukoopiast. E-kirjad ei lahkunud organisatsioonist kunagi, neid hoiti lihtsalt kusagil turvaliselt (Azure Blob Storage, AWS S3, Datto seade...) ja seejärel süstiti tagasi. Kasutaja ei oodanud seda kõige vähem: tema jaoks tulevad tagasi "tema" e-kirjad, mitte imporditud sõnumid.

Kuid tehniliselt on mehhanism sama. Tagasisüstimine, mis ei kanna kaasa algset kuupäeva, tekitab samu artefakte. Ja parandus järgib sama loogikat.

Kuidas iga tööriist INTERNALDATE käsitleb (või ei käsitle)

Kõik tööriistad ei käitu täpselt ühtmoodi, ja siin muutuvad asjad huvitavaks.

Veeam Backup for Microsoft 365

Veeam kasutab Exchange Online'i taastamiseks EWS (Exchange Web Services) API-t. EWS lubab sõnumi kuupäeva määrata välja DateTimeReceived kaudu, kuid see väärtus ei kajastu alati IMAP-tasemel INTERNALDATE väärtuses. Tulemus: sortimiskuupäev Outlookis ei pruugi vastata originaalkuupäevale, eriti kui taastamine toimub teise postkasti (näiteks granuleeritud taastamine alternatiivsesse postkasti).

Datto SaaS Protection

Datto taastab Microsoft Graph API või IMAP kaudu, sõltuvalt konfiguratsioonist. Mõlemal juhul sõltub postkastis kuvatav kuupäev sellest, kas taastamine annab kaasa sõnumi algse kuupäeva. MSP-d, kes kasutavad klientide jaoks Dattot, kohtavad seda probleemi üsna regulaarselt, eriti lunavararünnakute järgselt, kus taastatakse kiiresti mitu sadat postkasti korraga. See pole hetk, mil avastada, et kõik kuupäevad on valed.

AvePoint ja Synology Active Backup

AvePoint Cloud Backup ja Synology Active Backup for Microsoft 365 järgivad sarnaseid mehhanisme. AvePoint on selle käitumise oma teadmistebaasis dokumenteerinud (sõnum taastatakse taastamiskuupäevaga nähtava vastuvõtukuupäevana), ilma natiivset parandust pakkumata. Synology Active Backup esitab sama probleemi, mida võimendab asjaolu, et taastamisliides ei erista selgelt "sõnumi kuupäeva" ja "taastamiskuupäeva".

Hea uudis: originaalkuupäev on alles

See, mis teeb olukorra parandatavaks, on see, et sõnumi algne Date: päis ei ole muutunud. See on endiselt olemas, puutumatu, iga taastatud e-kirja sees. Taastamine muutis postkasti salvestatud kuupäeva ja mõnikord lisas peale Received: rea, kuid ei puudutanud sõnumi sisu ennast.

See on MIME-vormingu omadus (RFC 2822): sõnum on oma sisemises struktuuris muutumatu. Received: päised kogunevad ülaossa kihtide kaupa, kuid originaalteave jääb alla.

Tegelikult, te pole teavet kaotanud. See on lihtsalt varjatud tagasisüstimise artefakti taha.

Miks taastamise kordumine ei ole lahendus

Esimene mõte: kustutada taastatud e-kirjad ja käivitada taastamine uuesti, lootes et seekord on kuupäevad õiged. See on halb idee, mitmel põhjusel.

Esiteks, taastamistööriistad ei käitu teisel käivitusel erinevalt. Sama tööriist, samad seaded: e-kirjad kirjutatakse tagasi samal viisil, ilma nende algse kuupäevata. Saate täpselt sama tulemuse.

Teiseks, taastamise uuesti käivitamine tootmispostkastidel tähendab aega, ribalaiust ja riski. 50 postkastiga, millest igaühel on 20 000 sõnumit, räägime mitme tunni pikkusest operatsioonist, mis monopoliseerib API-d ja võib käivitada Microsofti või Google'i poolseid kiirusepiiranguid (kuulus 429 Too Many Requests kell 2 öösel partii ajal).

Lühidalt. Taastamine töötas. Andmed on kohal. Parandada tuleb kuupäeva artefakt, mitte taastamine ise.

Ise parandamine: konkreetsed riskid

Probleemi mõistmine on üks asi. Selle parandamine 80 000 e-kirjal ilma ühtegi kaotamata on hoopis teine lugu.

Python-skript, mis läbib IMAP-sõnumeid ja parandab kuupäevi, võib tunduda teostatav. Ja 50 testmeilil töötab see suurepäraselt. Tootmiskeskkonnas on teisiti. Piirjuhtumid kuhjuvad: S/MIME allkirjastatud e-kirjad (päise muutmine muudab krüptograafilise allkirja kehtetuks), PGP-krüpteeritud sõnumid, mitmeosalised struktuurid mittestandardsete MIME-piiridega, RFC 2047-s kodeeritud päised (mitte-ASCII), 40 MB manused, mis lasevad skripti mälu lõhkeda. Ja e-kirjad, millele on lisatud mitu Received: päist (kui taastamine käivitati osaliselt uuesti, mis juhtub), mis nõuavad peenemat tuvastamisloogikat.

Täpsemalt öeldes, tegelik risk ei ole skript, mis crashib: see on skript, mis töötab ilma nähtava veata, kuid toodab rikutud sõnumeid. Katkised vestluslõimed. Duplikaadid. Eraldunud manused. Mida te ei pruugi märgata enne mitut nädalat hiljem, kui kasutaja üritab leida olulist e-kirja.

Ja kuidas kontrollida, et iga parandatud e-kiri on pärast muutmist tõesti terviklik? Kodutehtud skript seda üldjuhul ei tee.

Mida Redate.io teeb teisiti

Redate.io analüüsib iga e-kirja päiste ahelat tagasisüstimise artefaktide tuvastamiseks, olgu need pärit Veeam-taastamisest, BitTitani migratsioonist või käsitsi impordist. Redate'i välja töötatud parandusmotor ei pea teadma, milline tööriist kahju tekitas: see otsib e-kirju, mille kuvatav kuupäev ei vasta nende algsele kuupäevale, nii et tabatakse ka tööriist, millest kunagi kuulnud ei ole.

Enne millegi parandamist skanneerib Redate.io kogu postkasti ja esitab aruande: mitu e-kirja on mõjutatud, mis on vale kuupäev, mis on tuvastatud originaalkuupäev. See skaneerimine on tasuta. Näete probleemi ulatust enne tegutsemise otsustamist.

Iga e-kiri kontrollitakse individuaalselt pärast parandamist. Originaalid säilitatakse nähtavas varukausta, kuni te need ise kustutate.

Redate.io avab postkasti otse kasutaja Microsofti või Google'i kontoga sisselogimise kaudu, ilma et ükski e-kiri läbiks vahendavaid servereid. Parandamine toimub kohapeal, postkastis, ilma ekspordi ega reimpordi ta.

MSP-dele, kes haldavad mitut samaaegselt mõjutatud klienti, vaadake MSP-dele pühendatud lehekülge: Redate.io võib töödelda mitut postkasti paralleelselt ühest liidesest.

Muud stsenaariumid, mis tekitavad sama artefakti

Varundustööriistast taastamine ei ole ainus juhtum. Sama kuupäeva artefakt ilmub muudes olukordades:

• IMAP-import Exchange'ist (arhiveeritud postkastid, mis süstitakse tagasi Exchange Online'i)
• Exchange Online'i migreerimine tööriistadega, mis kasutavad sihtkohal IMAP-i
• Granuleeritud taastamine eksporditud ja uuesti imporditud PST-st (vt PST-impordi artiklit)
• Jagatud postkastid, mis on pärast intsidenti rekonstrueeritud (vt jagatud postkastide parandamist)

Kõigil neil juhtudel on alusmehhanism identne: tagasisüstimine, mis ei kanna kaasa algset kuupäeva (mõnikord koos uue Received: päisega peal), ja meiliklient, kes kuvab seda uut kuupäeva viitena.

E-kirjad on olemas, originaalkuupäev on igas sõnumis säilinud. Käivitage tasuta skaneerimine Redate.io-s, et näha täpselt, mitu e-kirja on teie postkastis mõjutatud, ja otsustage seejärel, kas soovite parandamise käivitada.