Veeam/Datto: sähköpostit saavat palautuspäivän lähettämispäivän sijaan

Palautuksen jälkeinen aamu: tikettejä lentää

Olet juuri saanut Veeam Backup for Microsoft 365 -palautuksen valmiiksi. Toiminto onnistui, data on paikallaan, kansiot ovat ehjät. Ja sitten maanantaiaamuna käyttäjä kirjoittaa: "Kaikissa sähköposteissani on tämänpäiväinen päivämäärä. En löydä mitään."

Sähköpostit eivät ole kadonneet. Ne ovat kaikki siellä. Mutta niiden näyttämä päivämäärä vastaa palautushetkeä, ei sitä päivää, jolloin ne lähetettiin tai vastaanotettiin. Tammikuulta 2021 oleva viesti näyttää saapuneen viime yönä kello 23:47. Viestiketjut ovat sekaisin. Aikajärjestys on lukukelvoton.

Tämä ongelma koskee Veeam Backup for Microsoft 365:tä, Datto SaaS Protectionia, Synology Active Backup for Microsoft 365:tä ja AvePoint Cloud Backupia, muiden muassa. Jokainen toimii hieman eri tavalla, mutta lopputulos on sama.

Mitä teknisesti tapahtuu

Ymmärtääksesi, mistä väärä päivämäärä tulee, täytyy katsoa, miten nämä työkalut injektoivat sähköpostit takaisin Exchange Online- tai Google Workspace -postilaatikkoon.

Kun varmuuskopiointityökalu palauttaa viestin, se ei voi yksinkertaisesti "laittaa sähköpostia takaisin paikalleen" kuten siirtäisi tiedoston paikallisella levyllä. Se kirjoittaa viestistä uuden kopion postilaatikkoon IMAP-protokollan tai palveluntarjoajan API:n kautta (EWS tai Microsoft Graph Microsoftin puolella, Gmail API Googlen puolella). Kopion mukana sen täytyy kertoa postilaatikolle, minkä päivämäärän viesti kantaa.

Ja tässä ongelma alkaa. (Muuten, jos olet koskaan lukenut palautetun sähköpostin raakoja otsakkeita, olet todennäköisesti selaillut parikymmentä Received:-riviä ennen kuin löysit itse sisällön.)

IMAP APPEND ja Received:-otsake

IMAP-protokollassa on komento nimeltä APPEND. Se lisää viestin postilaatikkoon. Juuri tätä palautustyökalu käyttää: se ottaa tallennetun viestin ja injektoi sen kohdepostilaatikkoon IMAP APPEND -komennolla.

Tämä komento antaa työkalun välittää päivämäärän viestin mukana. Jos työkalu välittää viestin alkuperäisen päivämäärän, postilaatikko säilyttää sen: näin tekevät Microsoft 365, Outlook.com ja Gmail. Jos se ei välitä mitään, tai välittää palautuksen päivämäärän, postilaatikko arkistoi sähköpostin palautuspäivän alle. Ja jotkin tavat kirjoittaa viesti takaisin lisäävät yhden rivin lisää alkuun: Received:-otsakkeen, joka on päivätty kopiointipäivälle. Gmailin oma tuonti-API tekee juuri niin.

Tämä lisärivi näyttää suunnilleen tältä:

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

Tulos: alkuperäinen sähköposti on sisällöltään ehjä, sillä on alkuperäinen Date:-otsakkeensa (esim. "3 Jan 2021 09:15:00"). Mutta uusi Received:-otsake on liimattu aivan ylimmäksi, päivättynä palautushetkeen.

Miten Outlook ja Gmail lukevat päivämäärän

Sähköpostiohjelmat kuten Outlook tai Gmailin verkkoliittymä eivät aina lue Date:-otsaketta päättääkseen, mitä päivämäärää viestilistassa näytetään. Monet käyttävät IMAP-protokollan INTERNALDATE-arvoa, eli päivämäärää, jolloin viesti lisättiin postilaatikkoon, tai uusinta Received:-otsaketta.

Outlook for Windows on tähän erityisen herkkä, varsinkin vuoden 2023 loppupuolen päivityksen jälkeen. Kun se näkee tuoreen Received:-otsakkeen ketjun kärjessä, se käyttää sitä näytettävänä päivämääränä. Alkuperäinen Date: jää viestin yksityiskohtiin, näkyviin vain jos avaa sähköpostin ominaisuudet.

Käyttäjä näkee siis viestilistan, jossa kaikilla sähköposteilla on palautusyön päivämäärä. Hänelle kolmen vuoden sähköpostihistoria on litistynyt yhteen yöhön.

Tämä on eri ongelma kuin siirrossa

On tärkeää erottaa tämä klassisesta IMAP-siirron väärät päivämäärät -ongelmasta. Siirrossa työkalu siirtää sähköpostit palvelimelta A palvelimelle B, ja se, säilyttääkö sähköposti päivämääränsä, riippuu siitä, mitä työkalu kertoo palvelimelle B sitä kirjoittaessaan. Mekaniikka on sama, mutta konteksti on erilainen.

Tässä kyse on palautuksesta varmuuskopiosta. Sähköpostit eivät koskaan poistuneet organisaatiosta, ne vain tallennettiin jonnekin (Azure Blob Storage, AWS S3, Datto-laitteisto...) ja injektoitiin takaisin. Käyttäjä odottaa tilannetta vähiten: hänelle nämä ovat "hänen" sähköpostinsa, jotka palaavat, eivät tuodut viestit.

Teknisesti mekaniikka on kuitenkin identtinen. Uudelleeninjektio, joka ei välitä alkuperäistä päivämäärää, tuottaa samat artefaktit. Ja korjauskin noudattaa samaa logiikkaa.

Miten kukin työkalu käsittelee (tai jättää käsittelemättä) INTERNALDATE:n

Kaikki työkalut eivät käyttäydy täsmälleen samoin, ja tässä asiat muuttuvat mielenkiintoisiksi.

Veeam Backup for Microsoft 365

Veeam käyttää EWS-rajapintaa (Exchange Web Services) palauttaessaan Exchange Onlineen. EWS sallii viestin päivämäärän määrittämisen DateTimeReceived-kentällä, mutta tämä arvo ei aina heijastu IMAP-tason INTERNALDATE-arvoon. Tulos: lajittelupäivämäärä Outlookissa ei välttämättä vastaa alkuperäistä päivämäärää, varsinkin jos palautus tehdään eri postilaatikkoon kuin alkuperäinen (esimerkiksi yksittäinen palautus vaihtoehtoiseen postilaatikkoon).

Datto SaaS Protection

Datto palauttaa Microsoft Graph API:n tai IMAP:n kautta konfiguraatiosta riippuen. Molemmissa tapauksissa postilaatikon näyttämä päivämäärä riippuu siitä, välittääkö palautus kunkin viestin alkuperäisen päivämäärän. MSP-kumppanit, jotka käyttävät Dattoa asiakkaidensa hyväksi, törmäävät tähän ongelmaan melko säännöllisesti, varsinkin kiristysohjelmahäiriöiden jälkeen, kun satoja postilaatikoita palautetaan kiireessä kerralla. Se ei ole oikea hetki huomata, että kaikki päivämäärät ovat pielessä.

AvePoint ja Synology Active Backup

AvePoint Cloud Backup ja Synology Active Backup for Microsoft 365 noudattavat samankaltaisia mekanismeja. AvePoint on dokumentoinut tämän käyttäytymisen tietokannassaan (viesti palautetaan siten, että palautuspäivämäärä näkyy vastaanottopäivänä), tarjoamatta kuitenkaan natiivikooditasolla korjausta. Synology Active Backupilla on sama ongelma, pahennettuna sillä, että palautusliittymä ei selkeästi erota "viestin päivämäärää" "palautuspäivämäärästä".

Hyvä uutinen: alkuperäinen päivämäärä on yhä tallessa

Tilanteen pelastaa se, että viestin alkuperäinen Date:-otsake ei ole muuttunut. Se on yhä olemassa, ehjänä, jokaisen palautetun sähköpostin sisällä. Palautus muutti postilaatikon tallentaman päivämäärän, ja lisäsi joskus Received:-rivin sen päälle, mutta ei koskenut itse viestin sisältöön.

Tämä on MIME-formaatin (RFC 2822) ominaisuus: viestin sisäinen rakenne on muuttumaton. Received:-otsakkeet kasautuvat ylimmäksi kuin kerrokset, mutta alkuperäiset tiedot pysyvät niiden alla.

Joten ei, dataa ei ole menetetty. Se on vain uudelleeninjektoinnin artefaktin peittämä.

Miksi palautuksen uudelleenkäynnistäminen ei ole ratkaisu

Ensimmäinen ajatus: poista palautetut sähköpostit ja käynnistä palautus uudelleen toivoen, että tällä kertaa päivämäärät ovat oikein. Tämä on huono idea, useasta syystä.

Palautustyökalut eivät käyttäydy toisella kerralla eri tavalla. Sama työkalu, samat asetukset: sähköpostit kirjoitetaan takaisin samalla tavalla, ilman alkuperäistä päivämääräänsä. Saat täsmälleen saman tuloksen.

Lisäksi palautuksen uudelleenkäynnistäminen tuotantopostilaatikoihin vie aikaa, kaistaa ja sisältää riskejä. 50 postilaatikolla, joissa kussakin on 20 000 viestiä, kyse on useiden tuntien operaatiosta, joka kuormittaa rajapintoja ja voi laukaista Microsoftin tai Googlen nopeusrajoitukset (se kuuluisa 429 Too Many Requests kello kahden aikoihin yöllä erän aikana).

Palautus toimi. Data on paikallaan. Se mikä täytyy korjata, on päivämääräartefakti, ei itse palautus.

Itse korjaaminen: konkreettiset riskit

Ongelman ymmärtäminen on eri asia kuin 80 000 sähköpostin korjaaminen menettämättä yhtään niistä.

Python-skripti, joka käy läpi IMAP-viestit ja korjaa päivämäärät, saattaa vaikuttaa toteuttamiskelpoiselta. Viidellä kymmenellä testisähköpostilla se toimii hyvin. Tuotantoympäristössä on eri juttu. Reunatapaukset kasaantuvat: S/MIME-allekirjoitetut sähköpostit (otsakkeen muokkaaminen mitätöi salakirjoitusallekirjoituksen), PGP-salatut viestit, multipart-rakenteet epästandardeilla MIME-rajoilla, RFC 2047 -koodatut otsakkeet (muut kuin ASCII-merkit), 40 Mt liitetiedostot, jotka räjäyttävät skriptin muistin. Ja sähköpostit, joilla on useita lisättyjä Received:-otsakkeita (jos palautus on käynnistetty osittain uudelleen, mikä tapahtuu), jotka vaativat hienosyisempää tunnistuslogiikkaa.

Oikeastaan todellinen riski ei ole kaatuva skripti: se on skripti, joka ajaa näennäisesti virheettömästi mutta tuottaa korruptoituneita viestejä. Rikkinäisiä viestiketjuja. Kaksoiskappaleita. Irronneita liitetiedostoja. Joita et välttämättä huomaa vasta useita viikkoja myöhemmin, kun käyttäjä yrittää löytää tärkeän sähköpostin.

Ja miten varmistat, että jokainen korjattu sähköposti on todella ehjä muokkauksen jälkeen? Kotitekoinen skripti ei yleensä tee tätä.

Mitä Redate.io tekee eri tavalla

Redate.io analysoi jokaisen sähköpostin otsakeketjun tunnistaakseen uudelleeninjektioartefaktit, olivat ne peräisin Veeam-palautuksesta, BitTitan-siirrosta tai manuaalisesta tuonnista. Korjausmoottori ei tarvitse tietää, mikä työkalu aiheutti virheen: se etsii sähköposteja, joiden näytetty päivämäärä ei täsmää niiden alkuperäiseen päivämäärään, niin että myös tuntematon työkalu paljastuu.

Ennen minkään korjaamista Redate.io skannaa koko postilaatikon ja esittää raportin: kuinka monta sähköpostia on vaikuttunut, mikä on väärä päivämäärä, mikä on tunnistettu alkuperäinen päivämäärä. Skannaus on ilmainen. Näet ongelman laajuuden ennen kuin päätät toimia.

Jokainen sähköposti tarkistetaan yksitellen korjauksen jälkeen. Alkuperäiset säilytetään näkyvässä varmuuskopiointikansiossa, kunnes poistat ne itse, mikä tarjoaa täydellisen turvaverkon tarvittaessa.

Redate.io avaa Exchange Online- tai Google Workspace -postilaatikon suoraan käyttäjän omalla kirjautumisella, ilman että yksikään sähköposti kulkee välipalvelinten kautta. Korjaus tehdään paikan päällä postilaatikossa, ilman vientiä tai uudelleentuontia.

MSP-kumppaneille, jotka hallinnoivat useita samanaikaisesti vaikuttuneita asiakkaita, löydät lisätietoja MSP-sivulta: Redate.io mahdollistaa useiden postilaatikoiden käsittelyn rinnakkain yhdestä käyttöliittymästä.

Muut skenaariot, jotka tuottavat saman artefaktin

Varmuuskopiointityökalusta palautus ei ole ainoa tapaus. Sama päivämääräartefakti ilmenee muissakin tilanteissa:

• IMAP-tuonti Exchangesta (arkistoidut postilaatikot injektoituna takaisin Exchange Onlineen)
• Siirto Exchange Onlineen IMAP:ia kohdesuuntaan käyttävillä työkaluilla
• Yksittäinen palautus viedystä PST:stä ja sen uudelleentuonnista (katso artikkeli PST-tuonnista)
• Häiriön jälkeen koostetut jaetut postilaatikot (katso jaettujen postilaatikoiden korjaus)

Kaikissa näissä tapauksissa taustalla oleva mekaniikka on identtinen: uudelleeninjektio, joka ei välitä alkuperäistä päivämäärää (joskus uuden Received:-otsakkeen kanssa sen päällä), ja sähköpostiohjelma, joka näyttää tämän uuden päivämäärän viitteellisenä.

Sähköpostit ovat tallessa, alkuperäinen päivämäärä on säilytetty jokaisessa viestissä. Käynnistä ilmainen skannaus Redate.io:ssa nähdäksesi tarkalleen, kuinka monta sähköpostia postilaatikossasi on vaikuttunut, ja päätä sitten haluatko käynnistää korjauksen.