أراد المستخدم الأصلي إعادة قرص NVMe تجريبي إلى حالة غير مُدارة بعد تجربة ZimaOS 1.5.3. ولم تكن بيانات الاختبار مهمة بالنسبة إليه. تمثلت استجابة 777-Spider الرسمية/فريق المجتمع في فتح تفاصيل القرص، واختيار تعطيل، وتأكيد مربع الحوار تهيئة وتعطيل، والانتظار حتى اكتمال العملية، ثم إزالة القرص فعليًا. وأكد صاحب المنشور الأصلي نجاح هذا الإجراء.
هناك ملاحظة مهمة تتعلق بالإصدار: أظهر تقرير منفصل عن ZimaOS 1.5.4 لاحقًا أن تأكيد التعطيل قد ينص على تهيئة القرص، بينما تبقى البيانات فعليًا بعد إعادة تفعيله. لذلك لا ينبغي اعتبار نص مربع الحوار من عام 2025 ضمانًا دقيقًا لما يفعله التعطيل الحالي بالبيانات. إذا كانت البيانات مهمة، فانسخها احتياطيًا قبل تنفيذ أي عملية تعطيل/تهيئة.
افتح تفاصيل القرص بدلًا من الانتقال إلى SSH أولًا
فكر المستخدم في البداية في إلغاء تركيب الأقسام يدويًا أو حذفها عبر SSH، لأن صفحة التخزين بدت وكأنها لا تحتوي على عنصر تحكم للإزالة. لكن الإجراء المفقود كان موجودًا ببساطة خلف السهم الصغير في صف القرص.
تم تأكيد نجاح إجراء التعطيل المذكور في المصدر
أوصى 777-Spider بما يلي:
- افتح القرص المستهدف؛
- اختر تعطيل؛
- أكد مربع الحوار الذي يبدو تحذيريًا ومدمرًا للبيانات؛
- انتظر حتى تتم إزالة القرص من التخزين المُدار؛
- أزله فعليًا بعد ذلك.
وردّ Carolus64 بأن العملية نجحت كما هو متوقع.
ذكر مربع الحوار في الإصدار 1.5.3 صراحةً التهيئة والتعطيل
ذكر تقرير لاحق عن الإصدار 1.5.4 أن التعطيل لم يمسح البيانات فعليًا
في فبراير 2026، أوضح مستخدم آخر أنه بعد تعطيل قرص تخزين تجريبي ثم إعادة تفعيله، ظل مجلد الاختبار موجودًا. ووصف مربع الحوار بأنه مضلل، واقترح الفصل بين التعطيل والتهيئة الاختيارية.
تعني هذه الأدلة اللاحقة أن صياغة الواجهة وسلوك المسح الفعلي لم يكونا متوافقين باستمرار بين تلك الإصدارات.
تعامل مع التعطيل والتهيئة على أنهما عمليتان قد تكونان مدمرتين للبيانات إلى أن تتحقق من سلوكهما
بالنسبة إلى ZimaOS الحالي، القاعدة الأكثر أمانًا هي:
- انسخ البيانات المهمة احتياطيًا؛
- حدّد القرص الدقيق باستخدام الطراز/الرقم التسلسلي/السعة؛
- تأكد مما إذا كان مستقلًا أو جزءًا من مصفوفة؛
- اقرأ مربع التأكيد الحالي؛
- لا تعتمد على منشور قديم لضمان الحفاظ على البيانات أو محوها.
إزالة قرص مستقل ليست مثل إزالة عضو من RAID
كان القرص المذكور في المصدر وحدة تخزين تجريبية مستقلة. أما إزالة عضو من RAID 1/5/6 أو من تخطيط مجمّع آخر، فلها آثار مختلفة تمامًا على التكرار وإعادة البناء.
لا تستخدم تسلسل التعطيل هذا كإجراء عام لتقليص مصفوفة RAID.
انقل بيانات التطبيقات قبل تعطيل قرص يستضيف تطبيقات
كان المستخدم قد ثبّت تطبيق WebDAV ثم أزاله. وفي النظام الحقيقي، قد يظل القرص المستهدف يستضيف بيانات التطبيقات، أو قواعد البيانات، أو وحدات Docker، أو وجهات النسخ الاحتياطي، أو نقاط ربط مخصصة.
استخدم إجراء ترحيل البيانات الحالي في ZimaOS قبل فصل وحدة تخزين تحتوي على بيانات تطبيقات مُدارة.
واجه المستخدم الأصلي أيضًا مشكلة في عرض النوافذ المنبثقة في Firefox
إذا بدا مربع تأكيد حالي فارغًا أو مقصوصًا، فجرّب الإصدار المستقر الحالي من ZimaOS ومتصفحًا آخر قبل تنفيذ إجراءات التخزين بشكل أعمى.
الأسئلة الشائعة حول إزالة الأقراص
هل نجح المستخدم الأصلي في إزالة قرص NVMe المستقل باستخدام التعطيل؟
نعم. أكد نجاح إجراء الواجهة المُدارة.
هل تثبت صياغة «التهيئة والتعطيل» التاريخية أن القرص مُسح بأمان؟
لا. أظهر تقرير لاحق عن الإصدار 1.5.4 بقاء البيانات بعد التعطيل، لذا تحقّق من السلوك الحالي بشكل منفصل.
هل يمكن استخدام الإجراء نفسه لإزالة عضو من RAID؟
لا تفترض ذلك. فإزالة عضو من مصفوفة لها متطلبات مختلفة للبيانات والتكرار.
