Veeam/Datto: Email Bertanggal Saat Restore, Bukan Saat Dikirim

Keesokan hari setelah restore, tiket mulai masuk

Anda baru saja menyelesaikan restore kotak surat melalui Veeam Backup for Microsoft 365. Prosesnya berjalan lancar, data sudah ada, folder-folder utuh. Lalu, Senin pagi, seorang pengguna mengirim pesan: "Semua email saya bertanggal hari ini. Saya tidak bisa menemukan apa pun."

Masalahnya bukan email yang hilang. Semuanya ada. Tapi tanggal yang ditampilkan sesuai dengan waktu restore, bukan tanggal email tersebut dikirim atau diterima. Email dari Januari 2021 muncul seolah baru diterima semalam pukul 23:47. Rangkaian percakapan hancur. Kronologi tidak terbaca.

Perilaku ini muncul pada Veeam Backup for Microsoft 365, Datto SaaS Protection, Synology Active Backup for Microsoft 365, dan AvePoint Cloud Backup, antara lain. Masing-masing dengan caranya sendiri, tapi hasilnya selalu sama.

Apa yang terjadi secara teknis

Untuk memahami dari mana asal tanggal yang salah, perlu dilihat bagaimana alat-alat ini menyuntikkan ulang email ke dalam kotak Exchange Online atau Google Workspace.

Ketika alat backup melakukan restore sebuah pesan, ia tidak bisa begitu saja "mengembalikan" email seperti memindahkan file di disk lokal. Alat tersebut menulis salinan baru pesan ke dalam kotak surat, melalui protokol IMAP atau melalui API penyedia (EWS atau Microsoft Graph di sisi Microsoft, API Gmail di sisi Google). Dan bersama salinan itu, alat harus memberi tahu kotak surat tanggal berapa yang dibawa pesan tersebut.

Dan di sinilah masalah dimulai. (Ngomong-ngomong, jika Anda pernah membaca header mentah email yang di-restore, Anda pasti pernah melihat dua puluhan baris Received: sebelum menemukan konten yang berguna.)

IMAP APPEND dan header Received:

Protokol IMAP memiliki perintah bernama APPEND. Perintah ini digunakan untuk menyisipkan pesan ke dalam kotak surat. Inilah yang digunakan alat restore: mengambil pesan yang tersimpan, lalu menyuntikkannya ke kotak tujuan.

Ketika Exchange Online atau Google Workspace menerima pesan melalui perintah ini, perintah ini memungkinkan alat menyertakan tanggal bersama pesan. Jika alat menyertakan tanggal asli pesan, kotak surat akan mempertahankannya: Microsoft 365, Outlook.com, dan Gmail semuanya berlaku demikian. Jika tanggal tidak disertakan, atau yang disertakan adalah tanggal restore, kotak surat akan mencatat email pada tanggal restore itu. Dan beberapa cara penulisan ulang pesan menambahkan satu baris lagi di bagian atas: header Received: dengan stempel waktu hari penyalinan. API impor Gmail sendiri melakukan hal ini.

Baris tambahan ini terlihat seperti ini:

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

Hasilnya: email asli tetap utuh di dalamnya, dengan header Date: asli (misalnya "3 Jan 2021 09:15:00"). Tapi header Received: baru telah ditempel di bagian paling atas, bertanggal saat restore dilakukan.

Cara Outlook dan Gmail membaca tanggal

Klien email seperti Outlook atau antarmuka web Gmail tidak selalu membaca header Date: untuk menentukan tanggal yang ditampilkan di daftar pesan. Banyak yang menggunakan INTERNALDATE protokol IMAP, yaitu tanggal pesan ditambahkan ke kotak surat, atau header Received: yang paling baru.

Outlook untuk Windows, terutama sejak pembaruan akhir 2023, sangat sensitif terhadap hal ini. Ketika melihat header Received: terbaru di bagian atas rantai header, Outlook menggunakannya sebagai tanggal tampilan. Header Date: asli tersisih ke detail pesan, hanya terlihat jika membuka properti email secara manual.

Pengguna akhir pun melihat daftar pesan yang semuanya bertanggal malam saat restore dilakukan. Bagi mereka, riwayat tiga tahun email seolah runtuh menjadi satu malam.

Masalah ini berbeda dari migrasi

Perlu dibedakan dari masalah klasik tanggal salah setelah migrasi IMAP. Dalam migrasi, alat memindahkan email dari server A ke server B, dan apakah setiap email mempertahankan tanggalnya bergantung pada apa yang disampaikan alat kepada server B saat menulisnya. Mekanismenya sama, tapi konteksnya berbeda.

Di sini, kita berbicara tentang restore dari backup. Email tidak pernah meninggalkan organisasi, hanya diamankan di suatu tempat (Azure Blob Storage, AWS S3, appliance Datto...) lalu disuntikkan kembali. Pengguna semakin tidak menduganya: bagi mereka, ini adalah email "milik mereka" yang kembali, bukan email yang diimpor.

Tapi secara teknis, mekanismenya sama. Penyuntikan ulang yang tidak menyertakan tanggal asli menghasilkan artefak yang sama. Dan solusinya pun mengikuti logika yang sama.

Bagaimana setiap alat menangani (atau tidak menangani) INTERNALDATE

Tidak semua alat berperilaku persis sama, dan inilah yang membuat situasinya menarik.

Veeam Backup for Microsoft 365

Veeam menggunakan API EWS (Exchange Web Services) untuk restore ke Exchange Online. EWS memungkinkan penentuan tanggal pesan melalui field DateTimeReceived, tapi nilai ini tidak selalu tercermin pada INTERNALDATE di level IMAP. Hasilnya: tanggal urutan di Outlook bisa tidak sesuai dengan tanggal asli, terutama jika restore dilakukan ke kotak yang berbeda dari kotak asal (restore granular ke kotak alternatif, misalnya).

Datto SaaS Protection

Datto melakukan restore via Microsoft Graph API atau IMAP tergantung konfigurasi. Dalam kedua kasus, tanggal yang ditampilkan kotak surat bergantung pada apakah restore menyertakan tanggal asli setiap pesan. MSP yang menggunakan Datto untuk klien mereka cukup sering menghadapi masalah ini, terutama setelah insiden ransomware ketika harus merestore ratusan kotak surat sekaligus dalam keadaan darurat. Bukan saat yang tepat untuk menemukan bahwa semua tanggal salah.

AvePoint dan Synology Active Backup

AvePoint Cloud Backup dan Synology Active Backup for Microsoft 365 mengikuti mekanisme serupa. AvePoint mendokumentasikan perilaku ini di basis pengetahuannya (pesan di-restore dengan tanggal restore sebagai tanggal penerimaan yang terlihat), tanpa menawarkan solusi bawaan. Synology Active Backup menunjukkan masalah yang sama, diperparah oleh antarmuka restore yang tidak membedakan dengan jelas antara "tanggal pesan" dan "tanggal restore".

Kabar baik: tanggal asli masih ada

Yang membuat situasi ini bisa diperbaiki adalah bahwa header Date: asli pesan tidak dimodifikasi. Header tersebut masih ada, utuh, di dalam setiap email yang di-restore. Restore mengubah tanggal yang dicatat kotak surat, dan terkadang menambahkan baris header Received: di atasnya, tapi tidak menyentuh konten pesan itu sendiri.

Ini adalah sifat format MIME (RFC 2822): sebuah pesan bersifat tak berubah dalam struktur internalnya. Header Received: menumpuk di bagian atas seperti lapisan-lapisan, tapi informasi asli tetap ada di bawahnya.

Jadi tidak, Anda tidak kehilangan informasinya. Informasi itu hanya tersembunyi oleh artefak penyuntikan ulang.

Mengapa menjalankan ulang restore bukan solusinya

Ide pertama yang muncul: hapus email yang di-restore dan jalankan ulang restore, berharap kali ini tanggalnya benar. Ini ide yang kurang tepat, karena beberapa alasan.

Pertama, alat restore tidak akan berperilaku berbeda pada percobaan kedua. Alat yang sama, pengaturan yang sama: email akan ditulis ulang dengan cara yang sama, tanpa tanggal aslinya. Hasilnya akan persis sama.

Selain itu, menjalankan ulang restore pada kotak produksi berarti membuang waktu, bandwidth, dan membawa risiko tersendiri. Pada 50 kotak surat dengan 20.000 pesan masing-masing, ini adalah operasi berjam-jam yang memonopoli API dan berpotensi memicu rate limit dari Microsoft atau Google (yang terkenal dengan error 429 Too Many Requests pukul 2 pagi saat batch berjalan).

Singkatnya, restore sudah berhasil. Data sudah ada. Yang perlu diperbaiki adalah artefak tanggal, bukan restore itu sendiri.

Memperbaiki sendiri: risiko nyata

Memahami masalahnya adalah satu hal. Memperbaikinya pada 80.000 email tanpa kehilangan satu pun adalah hal yang berbeda sama sekali.

Skrip Python yang menelusuri pesan IMAP dan memperbaiki tanggal mungkin terlihat bisa dilakukan. Dan pada 50 email uji coba, skrip itu akan bekerja dengan baik. Dalam produksi, ceritanya lain. Kasus tepi terus bertambah: email bertanda tangan S/MIME (memodifikasi header membatalkan tanda tangan kriptografi), pesan PGP terenkripsi, struktur multipart dengan batas MIME yang tidak standar, header yang dikodekan RFC 2047 (non-ASCII), lampiran berukuran 40 MB yang menghabiskan memori skrip. Ditambah email dengan beberapa header Received: yang ditambahkan (jika restore dijalankan sebagian, yang memang kadang terjadi), yang membutuhkan logika deteksi lebih halus.

Sebenarnya, risiko terbesar bukan skrip yang crash: melainkan skrip yang berjalan tanpa error tampak tapi menghasilkan pesan yang rusak. Rangkaian percakapan yang terputus. Duplikat. Lampiran yang terlepas. Yang mungkin baru Anda sadari beberapa minggu kemudian, saat pengguna mencoba menemukan email penting.

Dan bagaimana Anda memverifikasi bahwa setiap email yang diperbaiki benar-benar utuh setelah modifikasi? Skrip buatan sendiri umumnya tidak melakukan ini.

Apa yang Redate.io lakukan secara berbeda

Redate.io menganalisis rantai header setiap email untuk mengidentifikasi artefak penyuntikan ulang, baik yang berasal dari restore Veeam, migrasi BitTitan, maupun impor manual. Mesin koreksi proprietary tidak perlu mengetahui alat mana yang menyebabkan masalah: mesin ini mencari email yang tanggal tampilannya tidak sesuai dengan tanggal aslinya, sehingga alat yang belum pernah didengar sekalipun tetap terdeteksi.

Sebelum memperbaiki apa pun, Redate.io memindai seluruh kotak surat dan menyajikan laporan: berapa banyak email yang terpengaruh, apa tanggal yang salah, apa tanggal asli yang terdeteksi. Pemindaian ini gratis. Anda melihat cakupan masalahnya sebelum memutuskan untuk bertindak.

Setiap email diverifikasi satu per satu setelah koreksi. Aslinya tidak pernah dihapus oleh Redate.io: pesan tersebut tetap ada dalam folder yang terlihat di kotak surat Anda sendiri, sampai Anda menghapusnya sendiri.

Setiap pengguna masuk dengan akun Microsoft atau Google miliknya sendiri, dan Redate.io hanya membuka kotak surat itu dengan akses yang diberikan saat masuk, tanpa email apa pun yang melewati server perantara. Koreksi dilakukan di tempat, di dalam kotak surat, tanpa ekspor atau reimport.

Untuk MSP yang mengelola beberapa klien yang terdampak sekaligus, lihat halaman khusus untuk MSP: Redate.io memungkinkan pemrosesan beberapa kotak surat secara paralel dari satu antarmuka tunggal.

Skenario lain yang menghasilkan artefak yang sama

Restore dari alat backup bukan satu-satunya kasusnya. Artefak tanggal yang sama muncul dalam situasi lain:

• Import IMAP dari Exchange (kotak surat yang diarsipkan dan disuntikkan kembali ke Exchange Online)
• Migrasi ke Exchange Online dengan alat yang menggunakan IMAP di sisi tujuan
• Restore granular dari PST yang diekspor lalu diimpor ulang (lihat artikel tentang impor PST)
• Kotak surat bersama yang direkonstruksi setelah insiden (lihat perbaikan kotak surat bersama)

Dalam semua kasus ini, mekanisme yang mendasarinya identik: penyuntikan ulang yang tidak menyertakan tanggal asli (terkadang dengan header Received: baru di atasnya), dan klien email yang menampilkan tanggal baru itu sebagai referensi.

Email Anda ada, tanggal asli tersimpan di setiap pesan. Jalankan pemindaian gratis di Redate.io untuk melihat persis berapa banyak email yang terpengaruh di kotak surat Anda, lalu putuskan apakah Anda ingin melanjutkan koreksi.