Veeam/Datto: emails με ημερομηνία αποκατάστασης, όχι αποστολής

Την επόμενη μέρα της αποκατάστασης, τα tickets αρχίζουν

Μόλις ολοκληρώσατε μια αποκατάσταση γραμματοκιβωτίου μέσω Veeam Backup for Microsoft 365. Η διαδικασία πήγε καλά, τα δεδομένα είναι εκεί, οι φάκελοι είναι άθικτοι. Και έπειτα, Δευτέρα πρωί, ένας χρήστης σας γράφει: "Όλα τα emails μου έχουν σημερινή ημερομηνία. Δεν βρίσκω τίποτα."

Το πρόβλημα δεν είναι ότι τα emails εξαφανίστηκαν. Είναι εκεί. Αλλά η ημερομηνία που εμφανίζεται αντιστοιχεί στην ακριβή ώρα της αποκατάστασης, όχι στην ημερομηνία αποστολής ή παραλαβής τους. Ένα email του Ιανουαρίου 2021 εμφανίζεται ως παραληφθέν χθες το βράδυ στις 23:47. Το νήμα συνομιλίας είναι σπασμένο. Η χρονολογική σειρά είναι αδύνατο να διαβαστεί.

Αυτή η συμπεριφορά αφορά το Veeam Backup for Microsoft 365, το Datto SaaS Protection, το Synology Active Backup for Microsoft 365 και το AvePoint Cloud Backup, μεταξύ άλλων. Ο καθένας με τον τρόπο του, αλλά το αποτέλεσμα είναι ίδιο.

Τι συμβαίνει τεχνικά

Για να κατανοήσουμε από πού προέρχεται η λάθος ημερομηνία, πρέπει να δούμε πώς αυτά τα εργαλεία επανεισάγουν τα emails σε ένα γραμματοκιβώτιο Exchange Online ή Google Workspace.

Όταν ένα εργαλείο backup αποκαθιστά ένα μήνυμα, δεν μπορεί απλώς να το "επαναφέρει στη θέση του" όπως θα μετακινούσε ένα αρχείο σε τοπικό δίσκο. Γράφει ένα νέο αντίγραφο του μηνύματος στο γραμματοκιβώτιο, μέσω IMAP ή μέσω του API του παρόχου (EWS ή Microsoft Graph στη Microsoft, το Gmail API στη Google). Και μαζί με αυτό το αντίγραφο, πρέπει να δηλώσει στο γραμματοκιβώτιο ποια ημερομηνία φέρει το μήνυμα.

Και εκεί αρχίζει το πρόβλημα. (Αν έχετε διαβάσει ποτέ τα raw headers ενός αποκατεστημένου email, πιθανότατα είδατε να ξεδιπλώνονται είκοσι γραμμές Received: πριν φτάσετε στο πραγματικό περιεχόμενο.)

IMAP APPEND και το header Received:

Το πρωτόκολλο IMAP διαθέτει μια εντολή που ονομάζεται APPEND. Χρησιμεύει για την εισαγωγή ενός μηνύματος σε ένα γραμματοκιβώτιο. Αυτό ακριβώς χρησιμοποιεί ένα εργαλείο αποκατάστασης: παίρνει το αποθηκευμένο μήνυμα και το εισάγει στο γραμματοκιβώτιο-στόχο μέσω IMAP APPEND.

Αυτή η εντολή επιτρέπει στο εργαλείο να περάσει μια ημερομηνία μαζί με το μήνυμα. Αν το εργαλείο περάσει την αρχική ημερομηνία του μηνύματος, το γραμματοκιβώτιο την κρατάει: το Microsoft 365, το Outlook.com και το Gmail το κάνουν όλα. Αν δεν περάσει τίποτα, ή περάσει την ημερομηνία της αποκατάστασης, το γραμματοκιβώτιο ταξινομεί το email στην ημέρα της αποκατάστασης. Και ορισμένοι τρόποι επανεγγραφής ενός μηνύματος προσθέτουν μία ακόμα γραμμή στην κορυφή: ένα header Received: με ημερομηνία την ημέρα της αντιγραφής. Το ίδιο το API εισαγωγής του Gmail κάνει ακριβώς αυτό.

Αυτή η επιπλέον γραμμή μοιάζει κάπως έτσι:

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

Αποτέλεσμα: το αρχικό email είναι άθικτο μέσα, με το αρχικό header Date: του (ας πούμε "3 Jan 2021 09:15:00"). Αλλά ένα νέο header Received: έχει κολληθεί στην κορυφή, με ημερομηνία τη στιγμή της αποκατάστασης.

Πώς διαβάζουν την ημερομηνία το Outlook και το Gmail

Τα προγράμματα-πελάτες email όπως το Outlook ή η web διεπαφή του Gmail δεν διαβάζουν πάντα το header Date: για να αποφασίσουν ποια ημερομηνία να εμφανίσουν στη λίστα μηνυμάτων. Πολλά χρησιμοποιούν το INTERNALDATE του πρωτοκόλλου IMAP, δηλαδή την ημερομηνία κατά την οποία το μήνυμα προστέθηκε στο γραμματοκιβώτιο, ή το πιο πρόσφατο header Received:.

Το Outlook για Windows, ειδικά μετά την ενημέρωσή του στα τέλη του 2023, είναι ιδιαίτερα ευαίσθητο σε αυτό. Όταν βλέπει ένα πρόσφατο header Received: στην κορυφή της αλυσίδας, το χρησιμοποιεί ως ημερομηνία εμφάνισης. Το αρχικό Date: υποβιβάζεται στις λεπτομέρειες του μηνύματος, ορατό μόνο αν ανοίξετε τις ιδιότητες του email.

Ο τελικός χρήστης βλέπει λοιπόν μια λίστα μηνυμάτων που φέρουν όλα την ημερομηνία της νύχτας της αποκατάστασης. Για αυτόν, το ιστορικό τριών χρόνων μόλις συμπτύχθηκε σε μια και μόνη νύχτα.

Αυτό το πρόβλημα διαφέρει από μια μετεγκατάσταση

Πρέπει να γίνει διάκριση από το κλασικό πρόβλημα λανθασμένων ημερομηνιών μετά από μετεγκατάσταση IMAP. Σε μια μετεγκατάσταση, το εργαλείο μεταφέρει emails από έναν διακομιστή Α σε έναν διακομιστή Β, και το αν κάθε email κρατάει την ημερομηνία του εξαρτάται από το τι δηλώνει το εργαλείο στον διακομιστή Β καθώς το γράφει. Ο μηχανισμός είναι ο ίδιος, αλλά το πλαίσιο διαφέρει.

Εδώ μιλάμε για αποκατάσταση από αντίγραφο ασφαλείας. Τα emails δεν άφησαν ποτέ τον οργανισμό, απλώς αποθηκεύτηκαν κάπου (Azure Blob Storage, AWS S3, Datto appliance...) και στη συνέχεια επανεισήχθησαν. Ο χρήστης το περιμένει ακόμα λιγότερο: για αυτόν, είναι "τα δικά του" emails που επιστρέφουν, όχι εισαγόμενα emails.

Τεχνικά όμως, ο μηχανισμός είναι ο ίδιος. Μια επανεισαγωγή που δεν μεταφέρει την αρχική ημερομηνία παράγει τα ίδια artifacts. Και η διόρθωση ακολουθεί την ίδια λογική.

Πώς χειρίζεται (ή δεν χειρίζεται) κάθε εργαλείο το INTERNALDATE

Δεν συμπεριφέρονται όλα τα εργαλεία με τον ίδιο τρόπο, και εδώ τα πράγματα γίνονται ενδιαφέροντα.

Veeam Backup for Microsoft 365

Το Veeam χρησιμοποιεί το API EWS (Exchange Web Services) για την αποκατάσταση στο Exchange Online. Το EWS επιτρέπει τον ορισμό της ημερομηνίας του μηνύματος μέσω του πεδίου DateTimeReceived, αλλά αυτή η τιμή δεν αντικατοπτρίζεται πάντα στο INTERNALDATE σε επίπεδο IMAP. Αποτέλεσμα: η ημερομηνία ταξινόμησης στο Outlook μπορεί να μην αντιστοιχεί στην αρχική ημερομηνία, ειδικά αν η αποκατάσταση γίνεται σε διαφορετικό γραμματοκιβώτιο από το αρχικό (κοκκομερής αποκατάσταση σε εναλλακτικό γραμματοκιβώτιο, για παράδειγμα).

Datto SaaS Protection

Το Datto αποκαθιστά μέσω Microsoft Graph API ή IMAP ανάλογα με τη διαμόρφωση. Και στις δύο περιπτώσεις, η ημερομηνία που εμφανίζει το γραμματοκιβώτιο εξαρτάται από το αν η αποκατάσταση περνάει την αρχική ημερομηνία κάθε μηνύματος. Οι MSPs που χρησιμοποιούν Datto για τους πελάτες τους συναντούν αυτό το πρόβλημα αρκετά συχνά, ειδικά μετά από περιστατικά ransomware όπου αποκαθίστανται εκατοντάδες γραμματοκιβώτια εκτάκτως. Δεν είναι η κατάλληλη στιγμή να ανακαλύψεις ότι όλες οι ημερομηνίες είναι λάθος.

AvePoint και Synology Active Backup

Το AvePoint Cloud Backup και το Synology Active Backup for Microsoft 365 ακολουθούν παρόμοιους μηχανισμούς. Η AvePoint έχει τεκμηριώσει αυτή τη συμπεριφορά στη βάση γνώσεων της (το μήνυμα αποκαθίσταται με την ημερομηνία αποκατάστασης ως ορατή ημερομηνία παραλαβής), χωρίς ωστόσο να προτείνει εγγενή διόρθωση. Το Synology Active Backup παρουσιάζει το ίδιο πρόβλημα, ενισχυμένο από το γεγονός ότι η διεπαφή αποκατάστασης δεν διακρίνει σαφώς την "ημερομηνία μηνύματος" από την "ημερομηνία αποκατάστασης".

Καλά νέα: η αρχική ημερομηνία είναι ακόμα εκεί

Αυτό που κάνει την κατάσταση ανακτήσιμη είναι ότι το αρχικό header Date: του μηνύματος δεν έχει τροποποιηθεί. Είναι ακόμα παρόν, άθικτο, μέσα σε κάθε αποκατεστημένο email. Η αποκατάσταση άλλαξε την ημερομηνία που καταχώρησε το γραμματοκιβώτιο και, σε ορισμένες περιπτώσεις, πρόσθεσε από πάνω μια γραμμή Received:, αλλά δεν άγγιξε το περιεχόμενο του ίδιου του μηνύματος.

Αυτή είναι ιδιότητα της μορφής MIME (RFC 2822): ένα μήνυμα είναι αναλλοίωτο στην εσωτερική του δομή. Τα headers Received: συσσωρεύονται στην κορυφή σαν στρώματα, αλλά οι αρχικές πληροφορίες παραμένουν από κάτω.

Δηλαδή, δεν χάσατε την πληροφορία. Απλώς είναι κρυμμένη από ένα artifact επανεισαγωγής.

Γιατί η επανάληψη της αποκατάστασης δεν είναι λύση

Η πρώτη ιδέα που έρχεται στο μυαλό: διαγραφή των αποκατεστημένων emails και επανεκκίνηση της αποκατάστασης με την ελπίδα ότι αυτή τη φορά οι ημερομηνίες θα είναι σωστές. Αυτό είναι κακή ιδέα, για πολλούς λόγους.

Πρώτον, τα εργαλεία αποκατάστασης δεν πρόκειται να συμπεριφερθούν διαφορετικά στη δεύτερη εκτέλεση. Ίδιο εργαλείο, ίδιες ρυθμίσεις: τα emails γράφονται πίσω με τον ίδιο τρόπο, χωρίς την αρχική τους ημερομηνία. Θα πάρετε ακριβώς το ίδιο αποτέλεσμα.

Επιπλέον, η επανεκκίνηση μιας αποκατάστασης σε γραμματοκιβώτια παραγωγής σημαίνει χρόνο, εύρος ζώνης και κίνδυνο. Για 50 γραμματοκιβώτια με 20.000 μηνύματα το καθένα, μιλάμε για μια επέμβαση αρκετών ωρών που δεσμεύει τα APIs και μπορεί να ενεργοποιήσει όρια ρυθμού από την πλευρά της Microsoft ή της Google (το γνωστό 429 Too Many Requests στις 2 τη νύχτα κατά τη διάρκεια της παρτίδας).

Εν ολίγοις. Η αποκατάσταση λειτούργησε. Τα δεδομένα είναι εκεί. Αυτό που πρέπει να διορθωθεί είναι το artifact ημερομηνίας, όχι η ίδια η αποκατάσταση.

Αυτόματη διόρθωση: οι συγκεκριμένοι κίνδυνοι

Να κατανοείς το πρόβλημα είναι ένα πράγμα. Να το διορθώσεις σε 80.000 emails χωρίς να χάσεις ούτε ένα, είναι τελείως άλλο.

Ένα Python script που διασχίζει τα μηνύματα IMAP και διορθώνει τις ημερομηνίες μπορεί να φαίνεται εφικτό. Και σε 50 test emails, θα λειτουργεί μια χαρά. Στην παραγωγή, τα πράγματα είναι διαφορετικά. Τα edge cases συσσωρεύονται: emails υπογεγραμμένα S/MIME (η τροποποίηση του header ακυρώνει την κρυπτογραφική υπογραφή), κρυπτογραφημένα μηνύματα PGP, δομές multipart με μη τυπικά MIME boundaries, headers κωδικοποιημένα σε RFC 2047 (non-ASCII), συνημμένα 40 MB που υπερφορτώνουν τη μνήμη του script. Και emails με πολλαπλά headers Received: που προστέθηκαν (αν η αποκατάσταση επαναλήφθηκε μερικώς, κάτι που συμβαίνει), τα οποία απαιτούν πιο λεπτή λογική ανίχνευσης.

Για να είμαστε ακριβείς, ο πραγματικός κίνδυνος δεν είναι το script που κολλάει: είναι το script που τρέχει χωρίς εμφανές σφάλμα αλλά παράγει κατεστραμμένα μηνύματα. Σπασμένα νήματα συνομιλίας. Διπλότυπα. Αποσπασμένα συνημμένα. Που ίσως να τα ανακαλύψετε αρκετές εβδομάδες αργότερα, όταν ένας χρήστης προσπαθεί να βρει ένα σημαντικό email.

Και πώς επαληθεύετε ότι κάθε διορθωμένο email είναι πραγματικά άθικτο μετά την τροποποίηση; Ένα self-made script συνήθως δεν το κάνει.

Τι κάνει διαφορετικά το Redate.io

Το Redate.io αναλύει την αλυσίδα των headers κάθε email για να εντοπίσει τα artifacts επανεισαγωγής, είτε προέρχονται από αποκατάσταση Veeam, είτε από μετεγκατάσταση BitTitan, είτε από χειροκίνητη εισαγωγή. Ο ιδιόκτητος κινητήρας διόρθωσης δεν χρειάζεται να ξέρει ποιο εργαλείο προκάλεσε το πρόβλημα: εντοπίζει τα emails των οποίων η εμφανιζόμενη ημερομηνία δεν αντιστοιχεί στην αρχική τους ημερομηνία, οπότε εντοπίζεται και ένα εργαλείο που κανείς δεν έχει ξανακούσει.

Πριν διορθώσει οτιδήποτε, το Redate.io σαρώνει ολόκληρο το γραμματοκιβώτιο και παρουσιάζει μια αναφορά: πόσα emails επηρεάζονται, ποια είναι η λανθασμένη ημερομηνία, ποια είναι η αρχική ημερομηνία που εντοπίστηκε. Αυτή η σάρωση είναι δωρεάν. Βλέπετε την έκταση του προβλήματος πριν αποφασίσετε αν θέλετε να προχωρήσετε.

Κάθε email επαληθεύεται μεμονωμένα μετά τη διόρθωση. Τα πρωτότυπα διατηρούνται σε έναν ορατό φάκελο αντιγράφων ασφαλείας μέσα στο δικό σας γραμματοκιβώτιο, μέχρι να τα διαγράψετε εσείς οι ίδιοι, προσφέροντας ένα πλήρες δίχτυ ασφαλείας σε περίπτωση ανάγκης.

Κάθε χρήστης συνδέεται με τον προσωπικό του λογαριασμό Microsoft ή Google, και το Redate.io ανοίγει μόνο εκείνο το γραμματοκιβώτιο με την πρόσβαση που δίνει αυτή η σύνδεση, χωρίς κανένα email να διέρχεται από ενδιάμεσους διακομιστές. Η διόρθωση γίνεται επί τόπου, μέσα στο γραμματοκιβώτιο, χωρίς export ή reimport.

Για τους MSPs που διαχειρίζονται πολλαπλούς πελάτες που επηρεάζονται ταυτόχρονα, δείτε τη σελίδα αφιερωμένη στους MSPs: το Redate.io επιτρέπει την επεξεργασία πολλαπλών γραμματοκιβωτίων παράλληλα από μια ενιαία διεπαφή.

Άλλα σενάρια που παράγουν το ίδιο artifact

Η αποκατάσταση από εργαλείο backup δεν είναι η μόνη περίπτωση. Το ίδιο artifact ημερομηνίας εμφανίζεται και σε άλλες καταστάσεις:

• Εισαγωγή IMAP από Exchange (αρχειοθετημένα γραμματοκιβώτια που επανεισάγονται στο Exchange Online)
• Μετεγκατάσταση στο Exchange Online με εργαλεία που χρησιμοποιούν IMAP στην πλευρά του προορισμού
• Κοκκομερής αποκατάσταση από PST που εξήχθη και στη συνέχεια επανεισήχθη (δείτε το άρθρο για την εισαγωγή PST)
• Κοινόχρηστα γραμματοκιβώτια που ανακατασκευάστηκαν μετά από περιστατικό (δείτε τη διόρθωση κοινόχρηστων γραμματοκιβωτίων)

Σε όλες αυτές τις περιπτώσεις, ο υποκείμενος μηχανισμός είναι ίδιος: μια επανεισαγωγή που δεν μεταφέρει την αρχική ημερομηνία (μερικές φορές με ένα νέο header Received: από πάνω), και ένα πρόγραμμα-πελάτης email που εμφανίζει αυτή τη νέα ημερομηνία ως ημερομηνία αναφοράς.

Τα emails είναι εκεί, η αρχική ημερομηνία είναι διατηρημένη μέσα σε κάθε μήνυμα. Εκκινήστε μια δωρεάν σάρωση στο Redate.io για να δείτε ακριβώς πόσα emails επηρεάζονται στο γραμματοκιβώτιό σας, και μετά αποφασίστε αν θέλετε να προχωρήσετε με τη διόρθωση.