Large migrations · Verification · الدليل وراء شريط التقدم

نقل مئات الجيجابايت بين السحب: كيف تعرف وصول كل ملف؟

عند سعة 500 جيجابايت، فإن عبارة "يبدو أن التحميل قد انتهى" ليس دليلاً. يحتاج الترحيل الذي يمكن الاعتماد عليه إلى مخزون دائم، وانتقال حالة لكل كائن، واسترداد قابل للتكرار بعد الانقطاعات، وإثبات من الوجهة نفسها.

آخر تحديث ; 16 دقيقة للقراءة.

الإجابة المختصرة

يقوم FileArk بتقسيم المكتبة إلى سجلات لكل ملف ورسائل قائمة انتظار دائمة. يقوم العامل بنسخ تسليم واحد، ويخزن معرف الوجهة الذي تم إرجاعه، ويتحقق من صحة الحجم، ويقرأ هذا الكائن بالضبط مرة أخرى، ويقارن SHA-256 مع الحمولة النافعة المصدر. يتم التحقق من السجل — ويتم الإقرار بالرسالة — فقط بعد نجاح عمليات التحقق هذه وتحديث قاعدة البيانات.

لماذا يغير المقياس معنى "العمل"

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

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

وحدة الحقيقة المفيدة هي مهمة الملف: أي كائن مصدر تمت قراءته، وأي كائن وجهة تم إنشاؤه، وما هي البايتات التي تمت مقارنتها، ومتى تم التحقق من الصحة، وما إذا كانت أي محاولة ظلت دون حل.

دورة حياة FileArk الكاملة، مشروحة

دورة حياة مشروحة توضح قاعدة بيانات الماسح الضوئي لإعداد متصفح FileArk وعامل قائمة الانتظار الدائم والتحقق من SHA-256
يبدأ المتصفح تدفق التحكم؛ يقوم الماسح الضوئي وقائمة الانتظار المستمرة وقاعدة البيانات والعامل بتنفيذ عملية الترحيل طويلة الأمد.

عند قبول البدء، تكتب واجهة برمجة التطبيقات (API) أولاً مهمة مسح إلى MongoDB ثم تنشر رسالة فحص مستمر إلى قائمة انتظار RabbitMQ دائمة مع تمكين تأكيد الناشر. إذا فشل النشر، يتم وضع علامة على المهمة بأنها "فشلت" وتبلغ واجهة برمجة التطبيقات (API) بأنها لا تستطيع وضع عملية الفحص في قائمة الانتظار بأمان.

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

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

صف قاعدة البيانات هو عنصر قائمة مرجعية، وليس مسك الدفاتر القابل للتصرف

يبدأ كل سجل ملف في "معلق"، وينتقل إلى InProgress أثناء المحاولة، ويصل إلى "محمل" فقط بعد التحقق. يظل عدد المحاولات، ووقت المحاولة الأخيرة، وتفاصيل الخطأ، ومعرف كائن الوجهة، وملخصات SHA-256، وطريقة التحقق، وVerifiedAt مرفقة بالسجل.

تبقى السجلات المكتملة في قاعدة البيانات كمسار التقدم والتدقيق. "شطب ملف" يعني تغيير الحالة بشكل متحكم فيه، وليس حذف الأدلة. تقوم عمليات تسليم قائمة الانتظار المكررة بفحص تلك الحالة والإقرار على الفور بالسجل الذي تم وضع علامة "تم التحميل عليه" بـ VerifiedAt على الفور.

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

بوابة الإنجاز لملف واحد
Pending
  → InProgress (attempt recorded)
  → destination ID stored
  → destination size matches
  → exact destination object re-downloaded
  → source SHA-256 == destination SHA-256
  → Uploaded + VerifiedAt persisted
  → queue message acknowledged

لماذا قد يتم تسليم الملف أكثر من مرة

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

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

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

يتم فحص السعة في الوجهة وعلى العامل

قبل نشر المهام لكل ملف، يقوم الماسح الضوئي بإجمالي أحجام بيانات تعريف المصدر غير السالبة ويقارن المتطلبات مع مساحة التخزين المتبقية المبلغ عنها للوجهة عندما يوفر الموفر حصة محدودة. تفشل وجهة صغيرة الحجم في إجراء الفحص بدلاً من توجيه العمل إلى طريق مسدود معروف.

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

لا يتم استخدام قرص الكمبيوتر الخاص بك للتدريج. في عامل الترحيل، يتم وضع الملفات التي تزيد عن حد الذاكرة في دليل مؤقت معزول فقط بعد أن تحتوي وحدة التخزين على مساحة للكائن المتوقع بالإضافة إلى احتياطي يبلغ 2 جيجابايت. تتم إزالة المحتوى المؤقت أثناء عملية التنظيف سواء نجحت المحاولة أو فشلت.

لماذا يهم معرف الوجهة بالإضافة إلى SHA-256

اسم الملف ليس هوية فريدة. قد تحتوي الوجهة بالفعل على ملفين بنفس الاسم المرئي، أو قد تستغرق قائمة بيانات التعريف بعض الوقت حتى تتم تسويتها. توفر استجابة التحميل معرف كائن الموفر، ويقوم FileArk بتخزين هذا المعرف قبل مرحلة التحقق النهائية.

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

تتم تغطية تمثيل الملف المنقول فقط. لا يمكن للملخص التحقق من صحة قواعد المشاركة أو التعليقات أو الإصدارات أو التصنيفات أو الاختصارات أو إعدادات الاحتفاظ أو كيفية عرض مستند Google المُصدَّر للمستخدم. وتظل تلك مهام القبول.

يتم حذف المصدر عن عمد خارج مسار النجاح الطبيعي

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

إذا قمت بتمكين الحذف بعد النقل عمدًا، فسيظل العامل ينتظر معرف الوجهة والحجم والتحقق من صحة SHA-256 قبل استدعاء عملية الحذف الخاصة بموفر المصدر. لا يزال الخيار التشغيلي الأقوى للمكتبات الكبيرة جدًا أو التي لا يمكن استبدالها هو إبقاء الخيار متوقفًا واستخدام فترة تداخل معتمدة من قبل الإنسان.

الهجرة تجيب “هل وصلت النسخة المؤكدة؟” يجيب الاحتفاظ "متى يمكن إزالة النسخة القديمة؟" تعامل معها كقرارات منفصلة بأدلة منفصلة.

نفس نموذج التحكم يعمل في كلا الاتجاهين

بالنسبة إلى OneDrive إلى Google Drive، تتم قراءة الحمولة المصدر من Microsoft Graph ويتم التحقق من كائن الوجهة من خلال Google Drive من خلال معرفه الذي تم إرجاعه. بالنسبة إلى Google Drive إلى OneDrive، يتم تنزيل المصدر أو تصديره من خلال Google Drive وتتم قراءة عنصر OneDrive الجديد مرة أخرى من خلال Microsoft Graph.

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

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

استخدم خطة قبول مكونة من أربعة أجزاء

  1. التوفيق بين سجل النظام

    مراجعة الأعداد المكتملة والمعلقة والقيدية والفاشلة. لا ينبغي التلويح بأي عنصر فاشل لأن النسبة الإجمالية مرتفعة.

  2. عينة حسب المخاطر

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

  3. التحقق من صحة سلوك الوجهة

    اختبار الوصول من الأجهزة والمستخدمين الحقيقيين. أعد إنشاء المشاركة المطلوبة وتأكد من فتح ملفات Office أو ملفات Google المصدرة كما هو متوقع.

  4. عقد فترة تداخل

    حافظ على المصدر متاحًا ومستقرًا أثناء الاستخدام العادي لتحديد الوجهة. اتخذ أي قرار بالإلغاء أو الحذف لاحقًا.

الأسئلة الشائعة

هل يستخدم FileArk قائمة انتظار لكل ملف؟

نعم. يقوم الماسح الضوئي بإنشاء سجل قاعدة بيانات أو إعادة استخدامه لكل ملف مصدر وينشر رسالة ترحيل مستمرة. يقوم العمال بسحب تلك الرسائل بالاعتراف اليدوي.

متى يتم الاعتراف برسالة قائمة الانتظار؟

بعد التحقق من معرف الكائن الوجهة وحجمه وSHA-256 واستمرار حالة التحميل والتحقق. يمكن إعادة تسليم عمليات التسليم غير المكتملة.

هل يتم حذف سجلات الملفات المكتملة من قاعدة البيانات؟

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

هل يمكن لـ SHA-256 إثبات الأذونات والإصدارات المنقولة؟

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

هل تم التحقق من OneDrive إلى Google Drive بنفس الطريقة العكسية؟

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

المصادر الرسمية المستخدمة في هذا الدليل

اقرأ الدليل