حلّ المجتمع

تعذّر إكمال حساب النسخ الاحتياطي لـ ZimaOS في جذر OneDrive: أخطاء المصدر مقابل الوجهة

A beta tester found that a 400 GB OneDrive root could take a long time to calculate, while choosing local Zima Storage as the destination triggered a separate UI problem that did not occur with an attached USB NVMe or Google Drive.

هذا الموضوع مفيد لأنه فصل في النهاية بين عرضين بدوا وكأنهما فشل واحد في تطبيق النسخ الاحتياطي: ظل جذر OneDrive كبيرًا في حالة جارٍ الحساب لفترة طويلة، بينما أدى اختيار Zima Storage المحلي كوجهة إلى مشكلة منفصلة في أداة الاختيار وواجهة المستخدم.

توقف تطبيق النسخ الاحتياطي في ZimaOS أثناء حساب مصدر جذر OneDrive في الإصدار التجريبي 1.5.1
أظهر البلاغ الأصلي بقاء مصدر جذر OneDrive في حالة الحساب.
فشل أداة اختيار وجهة تطبيق النسخ الاحتياطي في ZimaOS في فتح Zima Storage أثناء حساب OneDrive
ظهرت مشكلة أداة اختيار الوجهة عندما حاول المستخدم اختيار Zima Storage المحلي.
اختبار تطبيق النسخ الاحتياطي في ZimaOS باستخدام مجلد OneDrive أصغر لعزل ما إذا كان حجم مجموعة البيانات هو سبب المشكلة
تم حساب مصدر أصغر بنجاح، مما ساعد على الفصل بين وقت الحساب ومشكلة اختيار الوجهة.
تطبيق النسخ الاحتياطي في ZimaOS يعرض فشل واجهة وجهة Zima Storage المحلية أثناء الاختيار
أعاد الموضوع الأصلي إنتاج مشكلة اختيار الوجهة مع Zima Storage المحلي.
اختيار وجهة NVMe عبر USB متصلة بنجاح في تطبيق النسخ الاحتياطي في ZimaOS أثناء اختبار المقارنة
لم تُعِد وجهة NVMe عبر USB المتصلة إنتاج مشكلة أداة اختيار Zima Storage المحلية نفسها.

قد يكون حصر جذور السحابة الكبيرة مكلفًا من حيث الوقت والموارد

كان المستخدم يختبر نحو 400 جيجابايت في جذر OneDrive. يوضح سرد محرك Microsoft Graph أن محتويات الجذر تُحصر باعتبارها DriveItems، وقد تتطلب تقسيم النتائج إلى صفحات. لذلك يجب على تطبيق النسخ الاحتياطي اكتشاف عدد كبير من العناصر وحسابه قبل أن يتمكن من عرض حجم دقيق للمصدر.

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

اختبار المجلد الصغير هو أداة التشخيص الأكثر فائدة

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

تساعد الوجهات البديلة على فصل سبب الفشل

لم تُعِد وجهة NVMe عبر USB المتصلة ولا وجهة Google Drive إنتاج سلوك أداة اختيار Zima Storage المحلية نفسه. ولذلك بدت مشكلة واجهة الوجهة أكثر ترجيحًا من كونها فشلًا عامًا في محرك النسخ الاحتياطي.

يُفيد نظرة عامة على Zima Client عند تحديد ما إذا كان النسخ الاحتياطي من جهة محطة العمل أو النسخ الاحتياطي من ZimaOS إلى السحابة هو البنية الأنسب لمجموعة بيانات معينة.

لا تنسخ أوامر تصحيح الإصدار التجريبي إلى الأنظمة الحالية

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

أما بالنسبة إلى مصادقة OneDrive نفسها، فيشرح إعداد rclone لـ OneDrive كيفية عمل التفويض عبر المتصفح وإعداد الموقع البعيد على الطبقة الأدنى. فالتأخر في حصر المصدر ومشكلة OAuth مشكلتان مختلفتان.

الخلاصة

لا تشخّص حالة «متوقف أثناء الحساب» ومشكلة «تعذر اختيار Zima Storage» على أنهما عطل واحد. اختبر مجلدًا سحابيًا أصغر، واختبر وجهة أخرى، وحدد المرحلة التي تفشل فعليًا. كان الموضوع مرتبطًا بالإصدار التجريبي ZimaOS 1.5.1، لذلك ينبغي للأنظمة الحالية استخدام أحدث سلوك للنسخ الاحتياطي وتكامل السحابة قبل إعادة تطبيق الحلول القديمة.