قد يحصل قرص USB الاحتياطي المُدار بالتناوب على مسار تثبيت بلاحقة عندما يكون الدليل المفضّل المستند إلى التسمية مشغولًا أو مكررًا أو مُعيّنًا بواسطة أداة تثبيت تلقائي أخرى.
غالبًا ما تستخدم عملية تدوير النسخ الاحتياطية عدة أقراص متشابهة، وقد يستنسخ المسؤولون أنظمة الملفات أو يعيدون استخدام تسمية وحدة التخزين نفسها لتسهيل الإدارة. بعد إعادة التشغيل، قد يؤدي ترتيب الاكتشاف، أو التثبيت التلقائي لسطح المكتب، أو أدلة التثبيت القديمة، أو التسميات المكررة، أو إدخال متعارض في fstab إلى ظهور أحد الأقراص في مسار مثل BACKUP_1 بدلًا من BACKUP. قد يكون القرص سليمًا، بينما تستهدف مهمة النسخ الاحتياطي الآن الدليل الخطأ. تحقّق من الهوية قبل نقل الملفات أو تعديل المسارات.
تحديد نظام الملفات الموجود خلف المسار غير المتوقع
سجّل الجهاز الفعلي، ومعرّف UUID لنظام الملفات، والتسمية، والرقم التسلسلي أو مسار by-id، ومصدر التثبيت، والهدف، ونوع نظام الملفات، والخيارات لكل قرص تدوير متصل.
يعمل أمر findmnt في Linux على ربط الهدف بمصدره النشط، مما يمنع الخلط بين اسم مجلد مضلل وقرص النسخ الاحتياطي المقصود.
إذا كان الدليل ذو اللاحقة يعود إلى UUID الصحيح، فالمشكلة تتعلق بتعيين المسار. أما إذا كان يعود إلى قرص آخر، فأوقف النسخ الاحتياطي قبل أن يكتب في مجموعة التدوير الخطأ.
التحقق من تكرار تسميات أنظمة الملفات أو معرّفات UUID
قارن بين UUID والتسمية وPARTUUID والرقم التسلسلي وأسماء by-id عبر جميع الأقراص المُدارة بالتناوب، بما في ذلك الأقراص غير المتصلة حاليًا إذا كانت السجلات متاحة.
توضح ArchWiki أن تكرار التسميات أسهل من تكرار UUID، مما يجعل التثبيت التلقائي المستند إلى التسمية وحدها محفوفًا بالمخاطر عندما تشترك عدة أقراص نسخ احتياطي عمدًا في اسم وصفي واحد.
يمكن أن يؤدي استنساخ نظام الملفات أيضًا إلى استنساخ UUID الخاص به. عيّن هوية فريدة لنظام الملفات قبل الاعتماد على التدوير غير المراقب، ووثّق القرص الفعلي الذي يملك كل معرّف.
فهم سبب إضافة أدوات التثبيت التلقائي لاحقة
تحقق مما إذا كانت جلسة سطح المكتب أو خدمة NAS أو مساعد UDisks أو مدير الوسائط القابلة للإزالة قد ثبّت القرص قبل أن يتصرف fstab أو برنامج النسخ الاحتياطي.
يسمح معيار التسلسل الهرمي لنظام الملفات بإضافة أرقام إلى أدلة تثبيت الوسائط القابلة للإزالة عندما يحتاج أكثر من جهاز إلى موقع تثبيت مشابه.
تختلف سياسة اللاحقة الدقيقة باختلاف أداة التثبيت التلقائي، لكن مبدأ التشخيص واحد: كان المسار المفضّل غير متاح أو ملتبسًا عند وصول الجهاز.
التحقق مما إذا كان دليل التثبيت المفضّل مشغولًا مسبقًا
افحص الدليل المتوقع قبل توصيل القرص. حدّد ما إذا كان يحتوي على تثبيت آخر، أو ملفات متروكة كُتبت أثناء غياب القرص، أو تثبيت bind، أو عملية قديمة لا تزال تستخدم الدليل الحالي.
تشير إرشادات Oracle الخاصة بالوسائط القابلة للإزالة إلى أن تسميات الوسائط تُستخدم لتسمية مسارات التثبيت، مما يؤدي إلى تصادم عندما تعرض عدة وسائط المسار نفسه المشتق من التسمية.
لا تحذف دليلًا مشغولًا قبل التحقق مما إذا كان يحتوي على نسخ احتياطية كُتبت بالخطأ إلى نظام الملفات الجذر. انقل البيانات المتروكة التي تم التحقق منها عبر إجراء استرداد مضبوط.
تحديد نقطة تثبيت ثابتة في fstab لكل قرص تدوير
اختر سياسة مستقرة: إما أن يحصل كل قرص فعلي على دليله الثابت، أو يثبّت برنامج التدوير UUID المحدد حاليًا في مسار نسخ احتياطي واحد مضبوط بعد التحقق من الهوية.
توثّق Red Hat التثبيت الدائم عبر fstab باستخدام UUID ونقطة تثبيت ثابتة، مما يزيل تأثير ترتيب الاكتشاف وتصادمات التسميات الوصفية من المسار غير المراقب.
لا تنشئ عدة إدخالات نشطة في fstab تتنافس على دليل الهدف نفسه. يجب أن يتأكد سير عمل التدوير من إلغاء تثبيت القرص القديم قبل توصيل القرص التالي.
جعل بدء النسخ الاحتياطي يعتمد على التثبيت الذي تم التحقق منه
تحقق مما إذا كان المجدول يبدأ قبل اكتمال اكتشاف USB والتثبيت. أضف فحصًا تمهيديًا للتحقق من UUID ونقطة التثبيت وحالة الكتابة وملف العلامة المتوقع.
توضح وثائق تثبيت systemd في Debian أن إدخالات fstab تصبح تبعيات تثبيت في systemd، مما يتيح لخدمات النسخ الاحتياطي الانتظار حتى تثبيت محدد بدلًا من دليل عشوائي.
لا يكفي التحقق من وجود الدليل، لأن الدليل الأساسي موجود حتى عند غياب القرص. تحقّق من هوية نظام الملفات المثبّت.
اختبار عملية التدوير كاملة بعد إعادة التشغيل وتبديل الأقراص
لكل قرص، نفّذ إلغاء تثبيت نظيفًا، وافصل القرص، وأعد التشغيل، ثم أعد التوصيل، وتحقق من الهوية، ونفّذ عملية كتابة تجريبية، ومحاكاة للنسخ الاحتياطي، والتحقق من القراءة. سجّل المسار المتوقع وUUID.
تتناول مقالة ZimaSpace حول تثبيت UUID والمسارات الثابتة للتطبيقات تصميم المسار الثابت بصورة أوسع؛ بينما تركز هذه المقالة على التصادمات التي ينشئها تدوير عدة أقراص نسخ احتياطي قابلة للإزالة.
تُحل المشكلة عندما يرتبط كل قرص تدوير بمساره الموثق بعد اختبارات متكررة لإعادة التشغيل والتبديل، ويرفض النسخ الاحتياطي العمل عند فقدان UUID المتوقع أو تثبيته في مكان آخر.
الدعم والنصائح
المزيد للقراءة

لماذا تؤدي استعادة وحدة تخزين Docker إلى إعادة إنشاء محتويات الملفات مع فقدان السمات الموسّعة؟
تشخيص لاستعادة وحدة تخزين يغطي جرد السمات الموسَّعة (xattr)، وخيارات tar وRsync، ومساحات الأسماء، ودعم الوجهة، والامتيازات، والتسميات، والبيانات الوصفية للتطبيق، والاختبارات.

لماذا يحتفظ الحاوي قيد التشغيل بحد الذاكرة القديم بعد تغيير ملف Compose؟
تشخيص لحدود الذاكرة يغطي مجموعات cgroups النشطة، وإعادة التشغيل مقابل إعادة الإنشاء، وحقول Compose، والحدود الصارمة والمرنة، والنطاقات الأصلية، وذاكرة التبديل، وأكوام الذاكرة في...

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

