لماذا تؤدي استعادة وحدة تخزين Docker إلى إعادة إنشاء محتويات الملفات مع فقدان السمات الموسّعة؟

يمكن لاستعادة وحدة تخزين Docker إعادة إنشاء كل بايت من الملفات، مع فقدان السمات الموسّعة إذا كان تنسيق النسخة الاحتياطية أو خياراتها أو الامتيازات أو الوجهة لا تدعم حفظها.

السمات الموسّعة هي أزواج من البيانات الوصفية تتكوّن من اسم وقيمة، وتُخزَّن خارج محتوى الملفات العادي وملكية الملفات وبتات الصلاحيات والطوابع الزمنية. ويمكن أن تتضمن بيانات قوائم التحكم بالوصول (ACL) وتسميات SELinux وإمكانات Linux وعلامات التطبيقات أو بيانات Samba الوصفية. قد تؤدي نسخة احتياطية بسيطة لوحدة تخزين قائمة على tar إلى استعادة دليل يبدو كاملًا، بينما تتصرف التطبيقات بشكل مختلف لأن الأرشيف لم يسجل السمات الموسّعة أو لأن عملية الاستعادة لم تتمكن من الكتابة إلى مساحة أسماء محمية.

جرد سمات المصدر قبل تكرار الاستعادة

حدد ملفات ممثلة وسجّل تجزئاتها ومالكها وصلاحياتها وقائمة التحكم بالوصول (ACL) وكل اسم وقيمة من أسماء وقيم السمات الموسّعة. أدرج الملفات التي تفشل في التطبيق بعد الاستعادة.

يفصل نموذج السمات الموسّعة في Linux بين مساحات أسماء user وsystem وsecurity وtrusted، ولكل منها متطلبات وصول وامتيازات مختلفة.

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

تحقق مما أرشفه أمر النسخ الاحتياطي في Docker فعليًا

احفظ صورة Docker الدقيقة، والأمر، ودليل العمل، وتنسيق الأرشيف، والمستخدم، والمصدر الموصول، ووجهة النسخ الاحتياطي الموصولَة التي استخدمتها حاوية النسخ الاحتياطي.

يستخدم مثال النسخ الاحتياطي لوحدات تخزين Docker الأمر tar داخل حاوية مساعدة، لكن الحفاظ على البيانات الوصفية يظل معتمدًا على تطبيق tar والخيارات المحددة.

يثبت نجاح ملف الأرشيف أن إدخالات الدليل والبيانات قد قُرئت، لكنه لا يثبت تضمين كل مساحة من مساحات أسماء السمات الموسّعة. افحص الأرشيف باستخدام الأداة نفسها التي أنشأته.

فعّل السمات الموسّعة أثناء إنشاء الأرشيف واستخراجه

قارن خيارات tar المستخدمة في النسخ الاحتياطي والاستعادة. تأكد من تفعيل السمات الموسّعة في الاتجاهين، ومن أن أنماط التضمين أو الاستبعاد لم تزل مساحات الأسماء المطلوبة.

يوضح GNU tar أن الخيار --xattrs يخزّن السمات الموسّعة ويستعيدها.

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

Featured

ZimaCube 2 سحابة شخصية منزلية NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

استخدم خيارات Rsync الصحيحة للبيانات الوصفية في النسخ الاحتياطية القائمة على الملفات

إذا كانت النسخة الاحتياطية لوحدة التخزين تستخدم Rsync، فافحص خيارات الأرشفة وقوائم التحكم بالوصول (ACL) والسمات الموسّعة والمعرّفات الرقمية وfake-super والامتيازات على كل من المرسل والمستقبل.

يوثق دليل Rsync الرسمي الخيار -X للحفاظ على السمات الموسّعة، ويصف تخزين fake-super عندما يتعذر تطبيق البيانات الوصفية ذات الامتيازات مباشرة.

لا يتضمن خيار الأرشفة الشائع -a تلقائيًا كل متطلبات ACL والسمات الموسّعة. اختبر الأمر الدقيق عبر نظامَي الملفات الفعليين للمصدر والوجهة.

تحقق من دعم نظام الملفات والتحميل في الوجهة

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

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

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

تحقق من امتيازات مساحات أسماء security وtrusted

سجّل مستخدم حاوية الاستعادة وإمكاناتها ومساحة أسماء المستخدم ووضع التشغيل دون صلاحيات الجذر وسياسة SELinux، وما إذا كان مسار وحدة التخزين موصولًا من المضيف.

توثق Red Hat أن تسميات SELinux قد تحتاج إلى استعادة متوافقة مع السياسة بعد نسخ الملفات أو إعادة إنشائها.

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

افصل بين ACL والإمكانات والسمات الموسّعة الخاصة بالتطبيق

قارن بشكل منفصل إدخالات ACL الخاصة بـ POSIX وإمكانات ملفات Linux وتسميات SELinux وسمات المستخدم الموسّعة وبيانات Samba أو macOS الوصفية. فقد تفشل لأسباب مختلفة.

يمكن لوحدة xattr_tdb في Samba تخزين السمات الموسّعة بشكل منفصل عن نظام الملفات الأساسي.

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

استعد ملفًا اختباريًا واحدًا وتحقق من التطبيق

أنشئ ملف مصدر معروفًا يتضمن تجزئة للمحتوى وقائمة تحكم بالوصول (ACL) وسمة موسّعة للمستخدم وأي بيانات وصفية مطلوبة للتطبيق. انسخه احتياطيًا واستعده إلى وحدة تخزين مؤقتة.

تغطي مقالة ZimaSpace حول تغييرات صلاحيات وبيانات NAS الوصفية سلوك الترحيل على نطاق أوسع؛ أما هذه المقالة فتعزل النسخ الاحتياطي لوحدات تخزين Docker واستعادتها.

تُحل المشكلة عندما تتطابق تجزئات المحتوى وأسماء وقيم السمات الموسّعة المطلوبة وقوائم ACL وتسميات الأمان وسلوك التطبيق، بعد إجراء نسخة احتياطية واستعادة مضبوطة ثانية.

الأسئلة الشائعة

هل السمات الموسّعة هي نفسها قوائم ACL؟

لا. قد تُنفَّذ قوائم ACL باستخدام سمات موسّعة للنظام على بعض أنظمة الملفات، لكن السمات الموسّعة تخزّن أيضًا تسميات الأمان والإمكانات وبيانات المستخدم الوصفية والقيم الخاصة بالتطبيق.

هل يحافظ tar على السمات الموسّعة افتراضيًا؟

لا تفترض ذلك. يوفر GNU tar خيارات صريحة للسمات الموسّعة، ويجب أن يخزن الأرشيف السمات أثناء الإنشاء قبل أن يتمكن الاستخراج من استعادتها.

هل يمكن أن تفقد الاستعادة السمات الموسّعة حتى عند تشغيلها كمستخدم root؟

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