حلّ المجتمع

الانتقال من JBOD بقرص واحد إلى RAID على ZimaOS: النسخ الاحتياطي وإعادة البناء والاستعادة

A February 2026 beginner thread asking how to start with one NVMe JBOD now and migrate later to RAID 1 or RAID 5. The community answer recommended backup, create a fresh RAID, restore, and verify before repurposing the original disk. Current ZimaOS also provides built-in Data Migration for Docker images, app data, and user databases.

إن البدء اليوم بمحرك NVMe واحد والانتقال إلى RAID لاحقًا يُعد خطة معقولة لخادم منزلي، لكن مسار الترحيل الآمن ليس «النقر على تحويل JBOD إلى RAID». أوصى موضوع المصدر في فبراير 2026 بسير عمل منضبط يتضمن النسخ الاحتياطي ← إنشاء مصفوفة جديدة ← الاستعادة ← التحقق، بدلًا من افتراض قدرة ZimaOS على تحويل مساحة التخزين الحالية ذات القرص الواحد مباشرةً.

حسّنت ZimaOS الحالية أدوات الترحيل منذ نشر ذلك الموضوع. إذ تتيح الإعدادات > ترحيل البيانات الآن نقل صور Docker وبيانات تطبيقات Docker وقواعد بيانات مستخدمي ZimaOS بين مساحات التخزين. وهذا يسهّل ترحيل حالة التطبيقات، لكنه لا يحوّل قرصًا واحدًا مستخدمًا بالفعل إلى تخطيط RAID 1/5 متكرر من دون مصفوفة وجهة منفصلة.

بدأ المستخدم في المصدر بمحرك NVMe واحد وقرص USB للنسخ الاحتياطي

استخدم النظام ذاكرة eMMC المدمجة لتشغيل ZimaOS، وقرص NVMe SSD واحدًا مهيأً كتخزين JBOD، ومحرك أقراص ثابت USB للنسخ الاحتياطي. أراد المستخدم إضافة المزيد من وحدات تخزين NVMe لاحقًا ونقل كل شيء إلى RAID 1 أو RAID 5.

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

لا تفترض إمكانية تحويل JBOD ذي القرص الواحد مباشرةً

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

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

انسخ أكثر من مجلدات المشاركة الواضحة

قبل تغيير التخزين، احمِ ما يلي:

  • الملفات العادية المشتركة؛
  • بيانات تطبيقات Docker؛
  • المجلدات المخصصة المرتبطة؛
  • قواعد بيانات التطبيقات؛
  • تعريفات Compose/YAML للتطبيقات المخصصة؛
  • الإعدادات المهمة التي لا يُعاد إنشاؤها تلقائيًا.

ينبغي التحقق من النسخة الاحتياطية بفتح ملفات نموذجية فعلًا أو بإجراء اختبار استعادة، لا بمجرد رؤية حالة مهمة مكتملة.

أنشئ RAID الجديدة قبل محو القرص القديم

تتمثل بنية الترحيل الأكثر أمانًا في ترك محرك NVMe الأصلي دون تغيير أثناء إنشاء RAID الجديدة على الأقراص المضافة حديثًا. وبذلك يظل التخزين الأصلي مصدرًا آخر للاسترداد إلى أن يتم التحقق من المصفوفة الجديدة.

تتعامل ZimaOS الحالية مع إنشاء المصفوفات عبر الإعدادات > التخزين. استخدم سير عمل إعداد التخزين الحالي في ZimaOS بدلًا من إعادة تطبيق إجراءات mdadm اليدوية القديمة.

اختر RAID 1 أو RAID 5 بناءً على عدد الأقراص وخطة التوسع

RAID 1 هي النسخة المتطابقة المباشرة لمحركين. وتبدأ RAID 5 بثلاثة أقراص، وتضحي بسعة تعادل قرصًا واحدًا مقابل تحمل تعطل قرص واحد.

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

يمكن لميزة ترحيل البيانات الحالية نقل بيانات ZimaOS المُدارة

تذكر وثائق IceWhale الحالية أن الإعدادات > ترحيل البيانات يمكنها نقل ما يلي:

  • صور Docker؛
  • بيانات تطبيقات Docker؛
  • قواعد بيانات المستخدم مثل المعرض والتنزيلات والمستندات والوسائط والنسخ الاحتياطي.

استخدم سير عمل ترحيل البيانات الحالي في ZimaOS بعد إنشاء التخزين المستهدف.

لا تزال نقاط الربط المخصصة بحاجة إلى تحقق يدوي

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

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

تحقق من RAID الجديدة قبل إعادة تخصيص محرك NVMe الأصلي

تأكد مما يلي:

  • أن RAID تعرض حالة سليمة؛
  • أن المشاركات المهمة تحتوي على الملفات المتوقعة؛
  • أن تطبيقات Docker تبدأ وأن قواعد بياناتها سليمة؛
  • أن الأذونات تعمل من العملاء العاديين؛
  • أن مهام النسخ الاحتياطي تشير إلى المصدر والوجهة المقصودين.

عندها فقط ينبغي محو محرك NVMe الأصلي أو إعادة استخدامه.

احتفظ بالنسخة الاحتياطية على USB بعد الانتقال إلى RAID

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

تظل النسخة الاحتياطية على USB من الخطة الأصلية مفيدة بعد الترحيل إلى RAID، ويمكن أن تصبح جزءًا من استراتيجية 3-2-1 أوسع.

الأسئلة الشائعة حول الانتقال من JBOD إلى RAID

هل تستطيع ZimaOS الحالية نقل AppData بين مساحات التخزين؟

نعم. تتضمن أداة ترحيل البيانات الحالية بيانات تطبيقات Docker وصور Docker.

هل يعني ذلك إمكانية تحويل قرص JBOD واحد إلى RAID 1 مباشرةً؟

لا. فنقل البيانات وتغيير بنية التخزين عمليتان منفصلتان.

متى ينبغي محو القرص الأصلي؟

فقط بعد التحقق من المصفوفة الجديدة والملفات وحالة التطبيقات والأذونات والنسخ الاحتياطية.