Veeam/Datto: رسائل مؤرخة بتاريخ الاستعادة لا الإرسال

في اليوم التالي للاستعادة، تبدأ التذاكر بالوصول

انتهيت للتو من استعادة صندوق بريد عبر Veeam Backup for Microsoft 365. سارت العملية بسلاسة، البيانات موجودة، المجلدات سليمة. ثم، صباح الاثنين، يراسلك أحد المستخدمين: «كل رسائلي تحمل تاريخ اليوم. لا أجد شيئاً.»

المشكلة ليست أن الرسائل اختفت. هي موجودة. لكن التاريخ المعروض يوافق لحظة الاستعادة بالضبط، لا التاريخ الذي أُرسلت فيه الرسائل أو استُقبلت. رسالة من يناير 2021 تظهر كأنها وصلت أمس في الساعة 23:47. التسلسل الزمني للمحادثات مكسور. الترتيب الزمني أصبح غير مقروء.

هذا السلوك يطال Veeam Backup for Microsoft 365 وDatto SaaS Protection وSynology Active Backup for Microsoft 365 وAvePoint Cloud Backup، وغيرها. كل أداة بطريقتها الخاصة، لكن النتيجة واحدة.

ما يحدث على المستوى التقني

لفهم من أين يأتي التاريخ الخاطئ، لا بد من النظر في كيفية إعادة حقن هذه الأدوات للرسائل داخل صندوق Exchange Online أو Google Workspace.

حين تستعيد أداة النسخ الاحتياطي رسالةً ما، لا تستطيع ببساطة «إعادتها إلى مكانها» كما تنقل ملفاً على قرص محلي. بل تكتب نسخة جديدة من الرسالة داخل صندوق البريد، عبر بروتوكول IMAP أو عبر واجهة برمجة المزوّد (EWS أو Microsoft Graph عند Microsoft، وواجهة Gmail عند Google). ومع تلك النسخة، على الأداة أن تُخبر صندوق البريد بالتاريخ الذي تحمله الرسالة.

وهنا تبدأ المشكلة. (بالمناسبة، إن سبق لك الاطلاع على رؤوس raw لرسالة مستعادة، فقد رأيت على الأرجح عشرين سطر Received: قبل الوصول إلى المحتوى الفعلي.)

أمر IMAP APPEND والرأس Received:

بروتوكول IMAP يحتوي على أمر يسمى APPEND، يُستخدم لإدراج رسالة في صندوق بريد. هذا تحديداً ما تستخدمه أداة الاستعادة: تأخذ الرسالة المحفوظة وتحقنها في صندوق الهدف عبر IMAP APPEND.

يتيح هذا الأمر للأداة تمرير تاريخ مع الرسالة. فإذا مرّرت الأداة التاريخ الأصلي للرسالة، يحتفظ صندوق البريد به: هذا ما تفعله Microsoft 365 وOutlook.com وGmail جميعاً. وإذا لم تمرّر شيئاً، أو مرّرت تاريخ الاستعادة، يُصنّف صندوق البريد الرسالة تحت يوم الاستعادة. وبعض طرق إعادة كتابة الرسالة تضيف سطراً آخر في الأعلى، رأس Received: مختوماً بيوم النسخ. وهذا بالضبط ما تفعله واجهة استيراد Gmail الخاصة بها.

يبدو هذا السطر الإضافي على النحو التالي:

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

النتيجة: الرسالة الأصلية سليمة في الداخل، مع رأسها Date: الأصلي (لنقل «3 Jan 2021 09:15:00»). لكن رأس Received: جديداً لُصق في الأعلى، يحمل تاريخ الاستعادة.

كيف يقرأ Outlook وGmail التاريخ

عملاء البريد كـOutlook أو الواجهة الويب لـGmail لا يقرؤون دائماً رأس Date: لتحديد التاريخ المعروض في قائمة الرسائل. كثير منها يعتمد على INTERNALDATE في بروتوكول IMAP، أي التاريخ الذي أُضيفت فيه الرسالة إلى الصندوق، أو على أحدث رأس Received:.

Outlook لنظام Windows، خاصة منذ تحديث نهاية 2023، حساس جداً لهذا الأمر. حين يرى رأس Received: حديثاً في أعلى السلسلة، يستخدمه كتاريخ للعرض. أما الرأس Date: الأصلي فيُدفن في تفاصيل الرسالة، ولا يظهر إلا عند فتح خصائصها.

المستخدم النهائي يرى قائمة رسائل كلها مؤرخة بليلة الاستعادة. بالنسبة له، سجل ثلاث سنوات انضغط في ليلة واحدة.

هذه المشكلة مختلفة عن الترحيل

لا بد من التمييز بين هذا وبين المشكلة الكلاسيكية لتواريخ الرسائل الخاطئة بعد ترحيل IMAP. في الترحيل، تنقل الأداة رسائل من خادم A إلى خادم B، وما إذا كانت كل رسالة تحتفظ بتاريخها يعتمد على ما تُخبر به الأداة الخادم B عند كتابتها. الآلية واحدة، لكن السياق مختلف.

هنا نتحدث عن استعادة من نسخة احتياطية. الرسائل لم تغادر المؤسسة أبداً، بل كانت مخزنة في مكان آمن (Azure Blob Storage أو AWS S3 أو أجهزة Datto...) ثم أُعيد حقنها. المستخدم لا يتوقع هذا أصلاً: بالنسبة له، هذه «رسائله» التي عادت، لا رسائل مستوردة.

لكن تقنياً، الآلية ذاتها. إعادة الحقن التي لا تحمل التاريخ الأصلي تنتج نفس الآثار الجانبية. والتصحيح أيضاً يتبع المنطق نفسه.

كيف تتعامل كل أداة (أو لا تتعامل) مع INTERNALDATE

ليست كل الأدوات متطابقة في سلوكها، وهنا تصبح الأمور مثيرة للاهتمام.

Veeam Backup for Microsoft 365

Veeam تستخدم واجهة EWS (Exchange Web Services) للاستعادة إلى Exchange Online. تتيح EWS تحديد تاريخ الرسالة عبر حقل DateTimeReceived، لكن هذه القيمة لا تنعكس دائماً على INTERNALDATE على مستوى IMAP. النتيجة: تاريخ الترتيب في Outlook قد لا يطابق التاريخ الأصلي، خاصة عند الاستعادة إلى صندوق مختلف عن الأصلي (استعادة دقيقة إلى صندوق بديل، مثلاً).

Datto SaaS Protection

Datto يستعيد عبر Microsoft Graph API أو IMAP حسب الإعدادات. في كلتا الحالتين، التاريخ الذي يعرضه صندوق البريد يعتمد على ما إذا كانت الاستعادة تُمرّر التاريخ الأصلي لكل رسالة. شركات MSP التي تستخدم Datto لعملائها تصطدم بهذه المشكلة بانتظام، خاصة بعد حوادث الفدية (ransomware) حين تُستعاد مئات الصناديق في آنٍ واحد على وجه السرعة. ليس هذا هو الوقت المناسب لاكتشاف أن جميع التواريخ خاطئة.

AvePoint وSynology Active Backup

AvePoint Cloud Backup وSynology Active Backup for Microsoft 365 يتبعان آليات مماثلة. AvePoint وثّقت هذا السلوك في قاعدة معرفتها (الرسالة تُستعاد بتاريخ الاستعادة كتاريخ استقبال مرئي)، دون تقديم حل أصلي لهذا. Synology Active Backup تعاني المشكلة ذاتها، مع تعقيد إضافي: واجهة الاستعادة لا تُفرّق بوضوح بين «تاريخ الرسالة» و«تاريخ الاستعادة».

البشرى السارة: التاريخ الأصلي لا يزال موجوداً

ما يجعل الوضع قابلاً للإنقاذ هو أن رأس Date: الأصلي للرسالة لم يُعدَّل. لا يزال موجوداً وسليماً داخل كل رسالة مستعادة. عملية الاستعادة غيّرت التاريخ الذي سجّله صندوق البريد، وأضافت في بعض الأحيان سطر Received: فوقه، لكنها لم تمس محتوى الرسالة ذاتها.

هذه خاصية في تنسيق MIME (RFC 2822): الرسالة ثابتة في بنيتها الداخلية. رؤوس Received: تتراكم في الأعلى كطبقات متتالية، لكن المعلومات الأصلية تبقى في الأسفل.

إذن، المعلومة لم تضع. هي مجرد مخفية خلف أثر جانبي لعملية إعادة الحقن.

لماذا إعادة الاستعادة ليست الحل

أول فكرة تتبادر إلى الذهن: حذف الرسائل المستعادة وإعادة الاستعادة من جديد، على أمل أن تكون التواريخ صحيحة هذه المرة. فكرة سيئة، لأسباب عدة.

أولاً، أدوات الاستعادة لن تتصرف بشكل مختلف في المرة الثانية. نفس الأداة، نفس الإعدادات: تُعاد كتابة الرسائل بالطريقة نفسها، من دون تاريخها الأصلي.

ثانياً، إعادة الاستعادة على صناديق في الإنتاج تعني وقتاً وحزمة نطاق وخطراً. على 50 صندوقاً بـ20,000 رسالة لكل منها، نتحدث عن عملية تستغرق ساعات وتستنزف الواجهات البرمجية وقد تُطلق حدود المعدل من جانب Microsoft أو Google (الخطأ الشهير 429 Too Many Requests في الساعة الثانية صباحاً أثناء دفعة الاستعادة).

باختصار: الاستعادة نجحت. البيانات موجودة. ما يحتاج إلى تصحيح هو أثر التاريخ الجانبي، لا عملية الاستعادة ذاتها.

التصحيح يدوياً: المخاطر الفعلية

فهم المشكلة شيء. تصحيحها على 80,000 رسالة دون خسارة رسالة واحدة شيء آخر تماماً.

سكريبت Python يتجول عبر رسائل IMAP ويصحح التواريخ قد يبدو ممكناً. وعلى 50 رسالة اختبارية سيعمل بشكل ممتاز. في بيئة الإنتاج، الأمر مختلف. تتراكم الحالات الاستثنائية: رسائل موقعة بـS/MIME (تعديل الرأس يُلغي التوقيع التشفيري)، رسائل مشفرة بـPGP، هياكل multipart بحدود MIME غير معيارية، رؤوس مشفرة بـRFC 2047 (غير ASCII)، مرفقات بحجم 40 ميغابايت تُوقف السكريبت فجأة. والرسائل التي تحمل رؤوس Received: متعددة (حين تُعاد الاستعادة جزئياً، وهو ما يحدث)، والتي تحتاج منطق كشف أكثر دقة.

في الواقع، الخطر الحقيقي ليس السكريبت الذي ينهار، بل السكريبت الذي يعمل دون خطأ ظاهر لكنه ينتج رسائل تالفة. محادثات مكسورة. نسخ مكررة. مرفقات منفصلة عن رسائلها. قد لا تكتشف هذا إلا بعد أسابيع، حين يبحث مستخدم عن رسالة مهمة.

وكيف تتحقق من أن كل رسالة مصحَّحة سليمة فعلاً بعد التعديل؟ السكريبت المنزلي لا يفعل ذلك عادةً.

ما تفعله Redate.io بشكل مختلف

Redate.io تحلل سلسلة رؤوس كل رسالة لتحديد آثار إعادة الحقن، سواء أتت من استعادة Veeam أو ترحيل BitTitan أو استيراد يدوي. محرك التصحيح الخاص لا يحتاج إلى معرفة أي أداة تسببت في الخلل، بل يبحث عن الرسائل التي لا يطابق تاريخها المعروض تاريخها الأصلي، فتُكتشف حتى الأداة التي لم يسمع بها أحد.

قبل تصحيح أي شيء، تفحص Redate.io الصندوق بأكمله وتعرض تقريراً: كم رسالة متأثرة، ما التاريخ الخاطئ، وما التاريخ الأصلي المكتشف. هذا الفحص مجاني. ترى حجم المشكلة قبل أن تقرر التصرف.

كل رسالة يُتحقق منها بشكل فردي بعد التصحيح. تُحفظ الأصول في مجلد نسخ احتياطي مرئي داخل صندوقك، ولا تُحذف إلا حين تحذفها بنفسك، مما يوفر شبكة أمان كاملة عند الحاجة.

Redate.io يتصل عبر تسجيل دخول المستخدم بحسابه في Microsoft أو Google، دون بوابة إضافية أو تطبيق يُسجَّل مسبقاً، ودون أن تمر أي رسالة عبر خوادم وسيطة. التصحيح يتم على الصندوق مباشرة، دون تصدير أو إعادة استيراد.

لشركات MSP التي تدير عدة عملاء متأثرين في آنٍ واحد، يمكن الاطلاع على الصفحة المخصصة لشركات MSP: Redate.io تتيح معالجة عدة صناديق بريد بالتوازي من واجهة واحدة.

سيناريوهات أخرى تنتج الأثر الجانبي ذاته

الاستعادة من أداة نسخ احتياطي ليست الحالة الوحيدة. الأثر الجانبي نفسه في التاريخ يظهر في سياقات أخرى:

• استيراد IMAP من Exchange (صناديق مؤرشفة مُعاد حقنها في Exchange Online)
• الترحيل إلى Exchange Online باستخدام أدوات تعتمد IMAP على جانب الوجهة
• الاستعادة الدقيقة من PST مصدَّر ثم مستورد من جديد (انظر مقالة استيراد PST)
• صناديق البريد المشتركة المُعاد بناؤها بعد حادثة (انظر تصحيح صناديق البريد المشتركة)

في جميع هذه الحالات، الآلية الجوهرية واحدة: إعادة حقن لا تحمل التاريخ الأصلي (وقد تضيف أحياناً رأس Received: جديداً فوقه)، وعميل بريد يعرض ذلك التاريخ الجديد كتاريخ مرجعي.

الرسائل موجودة، والتاريخ الأصلي محفوظ داخل كل رسالة. أطلق فحصاً مجانياً على Redate.io لترى بالضبط كم رسالة متأثرة في صندوقك، ثم قرر بعدها إن كنت تريد المضي في التصحيح.