حلّ المجتمع

هل ينبغي استنساخ قرص نظام ZimaOS أم إجراء نسخ احتياطي للبيانات أولًا؟ أولويات الاسترداد الأكثر أمانًا من البرنامج التعليمي عبر USB

Page 2 of the USB system-backup tutorial discusses a user whose live NVMe was too large for convenient dd cloning. gelbuilding advised against repartitioning the live boot NVMe, prioritized DATA/AppData backups, suggested a larger USB target if a raw clone was still desired, and recommended eventually moving ZimaOS to a small dedicated boot disk. The discussion also explains that reinstalling the OS is possible, while a clone mainly saves setup/recovery time.

تغيّر الصفحة الثانية من هذا الدليل المجتمعي القرار من «كيف أشغّل dd؟» إلى «ما الذي يستحق الحماية فعلًا؟». كان لدى المستخدم قرص NVMe كبير قيد التشغيل، وكان يهتم بخسارة DATA بدرجة أكبر بكثير من خسارة نظام التشغيل القابل للإقلاع. وكانت نصيحة gelbuilding هي تجنّب إعادة تقسيم قرص NVMe المستخدم للإقلاع حاليًا، وحماية DATA وAppData أولًا، والاحتفاظ فقط بنسخة خام من النظام إذا كانت فائدة تقليل وقت الاسترداد تبرر مساحة النسخ الاحتياطي الإضافية.

ينسجم هذا الترتيب مع بنية ZimaOS الحالية. إذ يحتوي النظام على فتحتي نظام A/B للاسترداد السريع، بينما توجد بيانات المستخدم غير القابلة للاستبدال وAppData والبيانات الوصفية للتخزين خارج صور النظام غير القابلة للتغيير. يمكن لنسخة كاملة من القرص إعادة الجهاز بسرعة إلى نقطة زمنية مطابقة، لكنها لا تغني عن نسخ DATA احتياطية مستقلة ومُدارة بالإصدارات.

ينسخ dd الجهاز بالكامل، وليس فتحات النظام الصغيرة فقط

يستخدم الدليل الأصلي مفهومًا للأمر يشبه:

dd if=/dev/NVME_DEVICE | gzip > USB_BACKUP.img.gz

إذا كان النظام موجودًا على قرص NVMe بسعة 1 تيرابايت، فستظل عملية التصوير الخام تقرأ جهاز الكتل بالكامل. قد يؤدي الضغط إلى تقليل حجم الملف، لكن وجهة النسخ الاحتياطي والعملية تظلان مرتبطتين بتخطيط القرص الفعلي، لا بالغيغابايتات القليلة المستخدمة من أقسام نظام ZimaOS فقط.

لا تعِد تقسيم نظام سليم قيد التشغيل لمجرد تصغير نسخة dd

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

احمِ DATA وAppData قبل نسخة النظام

إذا كانت أولويتك هي قابلية الاسترداد، فانسخ احتياطيًا ما يلي:

  • ملفات المستخدم ومجمّعات التخزين؛
  • AppData وقواعد البيانات والإعدادات التي يصعب إعادة إنشائها؛
  • عمليات التصدير المهمة الخاصة بالتطبيقات؛
  • البيانات الوصفية لتخزين ZimaOS مثل local-storage.db عند الحاجة؛
  • ثم، اختياريًا، قرص النظام بالكامل.

تدعم إرشادات ZimaOS الحالية لقاعدة 3-2-1 إجراء نسخ احتياطية مجدولة إلى وجهات مستقلة ونقاط استعادة متعددة الإصدارات.

استخدم نموذج النسخ الاحتياطي الحالي 3-2-1 في ZimaOS.

يحتوي ZimaOS حاليًا على استرداد للنظام بنظام A/B

يستخدم ZimaOS فتحتي نظام تبلغ سعة كل منهما نحو 6 غيغابايت. إذا تعطلت إحدى الفتحتين، يتيح دليل الاسترداد الحالي للمستخدم الإقلاع من الفتحة البديلة عبر GRUB.

استخدم مسار استرداد النظام الحالي A/B.

يمكن لإعادة التثبيت النظيفة إعادة إنشاء نظام التشغيل، لكنها لا تعيد إعدادك المطابق تلقائيًا

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

كلتا الطريقتين صالحة للاسترداد؛ فكل منهما تحسّن جانبًا مختلفًا.

يسهّل قرص إقلاع مخصص وصغير استنساخ القرص بالكامل

أوصى gelbuilding بنقل ZimaOS في النهاية إلى جهاز مخصص صغير بسعة 32-64 غيغابايت، مع إبقاء مساحة تخزين NVMe/RAID الكبيرة مخصصة لـ DATA وAppData. الحد الأدنى الدقيق لتثبيت ZimaOS الحالي هو 25 غيغابايت على الأقل.

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

أوامر الاستعادة الخام مدمّرة

تكتب استعادة صورة dd مباشرة فوق القرص الوجهة. وقد يؤدي اختيار هدف /dev/... الخطأ إلى تدمير قرص آخر. وقد نُشر الدليل الأصلي صراحةً لأغراض الاختبار، ولا ينبغي استخدام هذه الأوامر إلا بعد تحديد الأقراص حسب الطراز والرقم التسلسلي، مع حفظ DATA في مكان آخر.

اختبر مسار الاسترداد، لا إنشاء النسخة الاحتياطية فقط

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

الأسئلة الشائعة حول استنساخ ZimaOS والنسخ الاحتياطي

هل يلزم استنساخ قرص النظام بالكامل لحماية بيانات ZimaOS؟

لا. تنفصل نسخ DATA وAppData الاحتياطية والبيانات الوصفية للتخزين عن أقسام نظام A/B، وهي الأولوية الأعلى للمعلومات غير القابلة للاستبدال.

لماذا أحتفظ بنسخة خام من نظام التشغيل على أي حال؟

يمكنها تقليل وقت الاسترداد من خلال استعادة إعداد النظام والتطبيقات المطابق لما التُقط، بدلًا من إعادة بنائه يدويًا.

هل ينبغي أن أعيد تقسيم قرص NVMe قيد التشغيل لمجرد تصغير النسخة؟

كانت التوصية الأصلية هي لا؛ انسخ DATA احتياطيًا أولًا وتجنّب تغييرات تقسيم الأقسام أثناء التشغيل من دون حاجة.