إن رسالة Duplicati التي تفيد بأن ملفًا من نوع .dblock.zip.aes إن فقدان ملف .dblock.zip.aes يبدو كأنه تلف في النسخة الاحتياطية، لكن سلسلة النقاش الأصلية توضح سبب عدم وجوب أن يكون الإصلاح التدميري هو الاستجابة الأولى. كانت وجهة النسخ الاحتياطي موجودة على مضيف ZimaOS ومرئية عبر Samba، لكن حاوية Duplicati لم تستطع فعليًا رؤية ذلك القرص الصلب من خلال تعيينات وحدات تخزين Docker الخاصة بها.
بعد أن عيّن المستخدم محرك الأقراص الصلبة الفعلي لدى المضيف داخل الحاوية، واختار الوجهة الجديدة من جانب الحاوية، أجاب بأن الأمر يبدو ناجحًا. لذلك انتهى المصدر إلى أن الحل المؤكد كان تعيين مسار Docker، وليس تطهير نسخة احتياطية تالفة مؤكدًا.
بدا الخطأ الأولي كأنه مستودع Duplicati تالف
أبلغ Duplicati بأن الإصلاح فشل لأن وجهة تخزين النسخ الاحتياطي كانت تفتقد ملفًا مشفرًا محددًا من نوع dblock ملف. وقد عرضت الرسالة مسارين للاسترداد: إعادة بناء ملفات الكتل المفقودة من بيانات المصدر المحلية، أو تطهير إدخالات النسخ الاحتياطي التي تعذر استعادتها.
هذه الخيارات هي ميزات حقيقية في Duplicati، لكنها لا تكون منطقية إلا بعد التحقق من أن وجهة النسخ الاحتياطي التي يجري فحصها هي الوجهة الصحيحة والكاملة.
كان المستخدم ينسخ قرصًا محليًا إلى قرص محلي آخر
كان التخطيط المقصود كالتالي:
- بيانات المصدر على محرك أقراص SSD محلي؛
- وجهة النسخ الاحتياطي على محرك أقراص صلبة منفصل؛
- تم تثبيت Duplicati من متجر تطبيقات ZimaOS، ولذلك كان يعمل داخل Docker.
اختار المستخدم المسارات عبر أداة اختيار المجلدات في التطبيق، وافترض أن ذلك يعني أن الحاوية تستطيع رؤية وحدة التخزين نفسها لدى المضيف.
مسار المضيف في ZimaOS ومسار الحاوية في Duplicati ليسا الشيء نفسه
لا يرى تطبيق Docker سوى مجلدات المضيف التي تم تحميلها داخل الحاوية. يمكن لـZimaOS الوصول إلى القرص عبر «الملفات» أو Samba، بينما لا يرى Duplicati شيئًا إذا كان ذلك القرص غير موجود في إعدادات وحدات تخزين التطبيق.
ولهذا قد يكون اختبار الاتصال مضللًا: فقد يكون نوع الوجهة صالحًا، بينما لا تكون محتويات المجلد المقصود ظاهرة فعليًا ضمن مساحة أسماء الحاوية.
كشف اختبار الملف المؤقت المشكلة الحقيقية
أنشأ المستخدم ملف temp.txt في مجلد الوجهة. كان الملف مرئيًا عبر Samba، لكنه لم يكن ظاهرًا في متصفح ملفات Duplicati. وكان ذلك دليلًا قويًا على أن Duplicati لم يكن يرى محتويات محرك الأقراص الصلبة الفعلي لدى المضيف.
عندها غيّر المُجيب في المجتمع مساره صراحةً، ونصح بعدم تشغيل التطهير أو إعادة البناء بعد.
كان الحل الفعّال هو تعيين محرك الأقراص الصلبة داخل الحاوية
أرشد المُجيب المستخدم إلى فتح إعدادات تطبيق ZimaOS، وإضافة محرك الأقراص الصلبة كوحدة تخزين للمضيف، وتعيينه إلى مسار بسيط داخل الحاوية مثل /backupأعد تشغيل الحاوية، ثم اختر وجهة ضمن مسار الحاوية هذا.
أجاب صاحب المنشور الأصلي: «يبدو أنه يعمل الآن.»
أكد ذلك أن تعيين وحدة التخزين كان الحل العملي.
تحتاج محركات الأقراص المصدر الإضافية إلى تعييناتها الخاصة
ثم سأل المستخدم عمّا إذا كان بإمكان مهمة Duplicati واحدة أن تتضمن عدة مجلدات مصدر. وكانت إجابة المجتمع نعم، بشرط أن يكون كل مسار مصدر ظاهرًا أيضًا داخل الحاوية.
إذا لم يُكشَف القرص الثاني من خلال وحدات تخزين Docker الخاصة بالتطبيق، فلن يظهر بشكل صحيح في Duplicati مهما كان مسار المضيف صالحًا.
استخدم تعيين وحدات تخزين التطبيقات الحالي في ZimaOS بدلًا من تخمين المسارات الخام
يعرض ZimaOS الحالي مسارات المضيف والحاوية في إعدادات التطبيق، ويوثّق كيفية تعيين التخزين الدائم إلى تطبيقات Docker.
استخدم نموذج مسارات Docker الحالي في ZimaOS عند إضافة مصادر النسخ الاحتياطي أو وجهاته.
متى يكون إصلاح Duplicati مناسبًا؟
تنص وثائق سطر أوامر Duplicati الحالية على أن Repair يمكنه إعادة بناء قاعدة البيانات المحلية من التخزين البعيد أو محاولة إعادة إنشاء البيانات المفقودة عن بُعد عندما يظل محتوى المصدر المحلي المطلوب متاحًا.
الخيار المتقدم --rebuild-missing-dblock-files يحاول هذا الخيار تحديدًا إعادة إنشاء ملفات الكتل المفقودة من بيانات المصدر المحلية، لكن Duplicati يحذّر من أن البيانات ربما تكون قد تغيّرت وأن الاستعادة قد تكون غير مكتملة أو بطيئة.
purge-broken-files مدمّر لسجل الاستعادة
تنص وثائق Duplicati الحالية على أن purge-broken-files يزيل الملفات من إصدارات النسخ الاحتياطي التي لم تعد قابلة للاستعادة، لكي تستمر مجموعة النسخ الاحتياطي. ولا ينبغي استخدامه إلا عندما يتعذر استرداد البيانات المفقودة عن بُعد.
قبل إجراء المسح، تحقّق من أوامر استرداد Duplicati الحالية وتبعاتها. ويُعد التشغيل التجريبي أو سرد الملفات التالفة أكثر أمانًا من حذف سجل النسخ الاحتياطي بشكل أعمى.
كانت رسالة الخطأ حقيقية، لكن الوجهة الأساسية كانت خاطئة
كان Duplicati يبلّغ بشكل صحيح بأن عرض المستودع الذي يمكنه رؤيته يفتقر إلى الملفات المتوقعة. وكان الجزء المضلل هو افتراض أن عرض المستودع هذا يمثل محرك الأقراص الصلبة الحقيقي. فقد جعل تعيين مسار Docker التطبيق يشير إلى عرض غير مكتمل أو مختلف لنظام الملفات.
الأسئلة الشائعة حول dblock في Duplicati
هل ثبت أن مستودع النسخ الاحتياطي المصدر تالف؟
لا. حُلّت المشكلة في الحالة المصدرية بعد إصلاح تعيين وحدة تخزين Docker.
هل يجب أن تكون purge-broken-files الخطوة الأولى؟
لا. تحقّق من تحميل الوجهة الكاملة الصحيحة وظهورها قبل إجراء أي إصلاح تدميري.
هل يمكن لمهمة Duplicati واحدة نسخ بيانات عدة محركات أقراص في ZimaOS احتياطيًا؟
نعم، ولكن يجب تعيين كل محرك مصدر داخل حاوية Duplicati.
