بدأ هذا النقاش في أبريل 2026 بمنشور عام عن «مستخدم جديد غارق في تعقيدات ZimaOS» تناول النسخ الاحتياطي والبريد الإلكتروني المستضاف ذاتيًا. وأصبحت مشكلة البريد ثانوية في النهاية؛ إذ نجح المستخدم في تشغيل Mailcow بما يكفي لتلبية احتياجاته. أما القصة التقنية غير المحسومة فكانت النسخ الاحتياطي في ZimaOS، حيث كانت الأحجام المعروضة غير متسقة، وكانت الجولة الأولى تكتمل عادةً، بينما قد تتجمد الجولات اللاحقة دون أي نشاط إضافي على القرص.
يُعد المصدر مفيدًا خصوصًا لأن المستخدم اختبر أكثر من ZimaBoard 2 واحدة، والعديد من محركات الأقراص الداخلية والخارجية، ووجهة شبكية من Synology، ثم ZimaOS 1.6.1 لاحقًا. لذلك لا ينبغي تلخيص المشكلة على أنها مجرد قرص USB تالف أو مسار شبكي واحد غير صحيح.
أراد المستخدم نسخة احتياطية بسيطة للتعافي من الكوارث، لا تنسيق أرشيف
كان سير العمل المطلوب بسيطًا: بدء نسخة احتياطية يدويًا بنمط 1:1، والحفاظ على بنية المجلدات المألوفة، وتجنب التشفير أو الحزم غير الواضحة، والتمكن من الاسترداد بسرعة إذا تعطلت ZimaBoard 2 بالكامل.
يختلف هذا التوقع عن برامج النسخ الاحتياطي ذات الإصدارات التي تحتفظ عمدًا بنسخ تاريخية. عند تفعيل الاحتفاظ بالإصدارات، يمكن أن يتجاوز الاستخدام في الوجهة حجم مجموعة البيانات الحالية في المصدر بشكل مشروع.
فُصلت مشكلة جانب خادم البريد في النهاية
ذكر المنشور الأصلي أيضًا صعوبة استبدال Synology Mail Plus. اقترح Zima-Jerry استخدام Stalwart، لكن المستخدم كان يحتاج تحديدًا إلى استرداد البريد عبر POP3. وبحلول 16 أبريل، أفاد المستخدم بأن Mailcow أصبح يعمل وأن التطبيقات الأخرى كانت مناسبة.
يجدر الاحتفاظ بهذه النتيجة لأنها تمنع إساءة فهم نقاش النسخ الاحتياطي اللاحق باعتباره دليلًا على أن Mailcow نفسه تسبب في مشكلة التخزين.
أحجام وجهة النسخ الاحتياطي لم تتطابق مع الواقع
في أحد اللوحات، كان نحو 800 غيغابايت في المصدر يقابله نحو 2.7 تيرابايت في دليل الوجهة. وفي لوحة أخرى، بدا أن نحو 105 غيغابايت في المصدر يقابله نقص يبلغ قرابة 2 غيغابايت في الوجهة.
يمكن للاحتفاظ بالإصدارات تفسير بعض الزيادة، لكنه لا يفسر تجمّد التشغيل الثاني
سأل Zima-Jerry عما إذا كانت وظيفة «الإصدار المحجوز» مفعّلة. فمن الطبيعي أن يؤدي الاحتفاظ بالإصدارات السابقة إلى جعل وجهة النسخ الاحتياطي أكبر من المصدر المباشر الحالي.
لكن المستخدم المصدر أعاد ضبط الاختبار لاحقًا باستخدام قرص USB خارجي مهيأ حديثًا، ووثّق فشلًا مختلفًا: اكتملت عملية النسخ الاحتياطي الأولى، بينما نسخت الثانية بعض البيانات ثم توقفت عن إحراز تقدم.
اختبار USB النظيف أعاد إنتاج فشل التشغيل الثاني
حذف المستخدم المهام القديمة، وأعاد تشغيل ZimaBoard 2، وهيّأ محرك أقراص خارجيًا، وأنشأ نسخة احتياطية يدوية جديدة مع تفعيل الإصدارات. استغرق التشغيل الأول قرابة يومين ونسخ بنجاح نحو 1.25 تيرابايت.
بعد فصل محرك الأقراص وإعادة توصيله عبر «الملفات»، نسخ التشغيل الثاني بعض التغييرات، ثم تجمّد شريط التقدم وتوقف مؤشر نشاط USB. وكان السلوك نفسه قد حدث مع وجهة Synology.
صعّدت IceWhale مشكلة سلوك النسخ الاحتياطي
شكر Zima-Jerry المستخدم على الاختبارات المنضبطة، وقال إن المشكلة ستُحال إلى فريق التطوير للتحقيق فيها.
فصل رد لاحق متعلق بـ IceWhale بين مجالين معروفين للمشكلات: النسخ الاحتياطي لكل /media/ZimaOS-HD كان يتضمن سابقًا محتوى أنابيب ومقابس Docker، كما كانت دقة عرض تقدم النسخ الاحتياطي لا تزال بحاجة إلى تحسين.
النسخ الاحتياطي لمحرك النظام بالكامل لا يساوي صورة نظام قابلة للاستعادة
تحوّل النقاش لاحقًا إلى التعافي من الكوارث. أوضح رد من الفريق أن النسخ الاحتياطي الأعمى للقرص الكامل للنظام يتضمن ملفات Docker وبيئة التشغيل القابلة للتخلص منها، ولا يوفر تلقائيًا سير عمل مدعومًا من نوع «استعد هذا المجلد وسيعود نظام ZimaOS بالكامل كما كان تمامًا».
عند التخطيط للتعافي من الكوارث، ميّز بين بيانات المستخدم وبيانات التطبيقات وقواعد البيانات والإعدادات وصور الحاويات القابلة للاستبدال.
غيّر ZimaOS 1.6.0 بيانات التعريف الخاصة باسترداد التخزين
ذكر رد رسمي لاحق أنه، بدءًا من ZimaOS 1.6.0، أصبحت المعلومات التي توضّح كيفية تركيب جهاز تخزين تُكتب أيضًا على جهاز التخزين نفسه. وكان الهدف تسهيل التعرّف على تخزين RAID أو القرص الفردي مجددًا بعد حدوث مشكلة في قرص النظام.
يحسّن هذا استعادة المصفوفة، لكنه لا يحوّل RAID إلى نسخة احتياطية ولا يصلح بمفرده مشكلة تعليق النسخ الاحتياطي في التشغيل الثاني لدى المستخدم الأصلي.
ما زال المستخدم يعيد إنتاج المشكلة على ZimaOS 1.6.1
في 27 أبريل، أفاد صاحب المنشور الأصلي بأن النسخة الاحتياطية الأولى ما زالت تعمل، لكن عمليات التشغيل الثانية واللاحقة علقت لأكثر من ست ساعات دون أي نشاط كتابة إضافي. وكان إغلاق تطبيق النسخ الاحتياطي وإعادة فتحه قد يُظهر الوجهة بسعة 0 B.
ذكروا أن هذا النمط اختُبر باستخدام أربعة محركات أقراص داخلية، ومحركي USB خارجيين، وثلاثة أنظمة ZimaBoard 2.
تطوّر سير عمل النسخ الاحتياطي الحالي
تصف وثائق ZimaOS الحالية الآن مهام النسخ الاحتياطي المجدولة عبر الوجهات المحلية وUSB وNAS والسحابية كجزء من استراتيجية 3-2-1.
استخدم سير عمل النسخ الاحتياطي الحالي في ZimaOS وخيارات الوجهة بدلًا من افتراض أن واجهة 1.5.x/1.6.1 تعمل بالطريقة نفسها اليوم.
لا يثبت الدليل الحالي بمفرده إصلاح كل أخطاء التشغيل الثاني السابقة الواردة في هذا الموضوع، لذا تحقّق من سلوك الاستعادة الفعلي على الإصدار الذي تستخدمه.
تحقّق من النسخ الاحتياطي خارج شريط التقدّم
- قارن بين عدد الملفات في المصدر والوجهة حيثما كان ذلك عمليًا؛
- افحص السعة الفعلية للوجهة بدلًا من الاعتماد على واجهة النسخ الاحتياطي فقط؛
- اختبر عملية تشغيل تزايدية أو بإصدارات ثانية وثالثة؛
- استعد ملفات نموذجية إلى موقع آخر؛
- وثّق قواعد بيانات التطبيقات والإعدادات التي يجب نسخها احتياطيًا بشكل منفصل.
الأسئلة الشائعة حول النسخ الاحتياطي في ZimaOS
هل حدثت مشكلة المصدر مع وحدة تخزين Synology NAS فقط؟
لا. أعاد المستخدم إنتاج حالات تجمّد مشابهة باستخدام محرك أقراص USB خارجي.
هل فشلت أول عملية نسخ احتياطي؟
اكتملت عملية التشغيل الأولى الخاضعة للرقابة؛ وظهرت المشكلة المتكررة في عمليات التشغيل اللاحقة.
هل اختفت المشكلة في ZimaOS 1.6.1؟
لا. ذكر صاحب المنشور الأصلي صراحةً أن المشكلة ما زالت تتكرر هناك.
هل يمكن أن تكون وجهة النسخ الاحتياطي أكبر من المصدر الحالي بشكل مشروع؟
نعم، عند تفعيل الاحتفاظ بالإصدارات، لكن ذلك لا يفسّر كل أعراض العرض أو تجمّد المهام الواردة في الموضوع.
