هل يجب عليك أخذ لقطة لبيانات تطبيق NAS المنزلي قبل كل تحديث للحاوية؟
يجب عليك إنشاء نقطة تراجع قبل تحديثات الحاوية التي يمكن أن تغير بيانات التطبيق الدائمة، مخططات قاعدة البيانات، ملكية الحجم، أو تخطيط التخزين. لا تحتاج إلى لقطة نظام ملفات جديدة قبل كل سحب صورة غير ضار أو إعادة تشغيل عندما تكون الخدمة بلا حالة، والمسارات الدائمة لم تتغير، ونسخة احتياطية مختبرة تغطي البيانات بالفعل.
القاعدة المفيدة لـ NAS المنزلي ليست "التقاط كل تحديث". بل هي "حماية كل تحديث يغير الحالة". هذا يتطلب معرفة ما يتحكم به صورة الحاوية، وما يعيش في الأحجام أو تثبيتات الربط، وما إذا كان التطبيق يمكنه التعافي من لقطة متسقة مع تعطل.
قاعدة لقطة واحدة تفشل لأن تحديثات الحاوية تغير أشياء مختلفة
يمكن أن يكون استبدال صورة منخفض المخاطر عندما تخدم الحاوية فقط رمزًا قابلًا للتخلص وتقرأ التكوين من التحكم في الإصدار. يمكن أن يكون التحديث الذي يبدو مماثلًا عالي المخاطر عندما يقوم الإصدار الجديد بترحيل قاعدة بيانات، إعادة كتابة فهرس، تغيير ملكية الملفات، أو تحويل تخطيط حجم دائم.
تعتمد ديمومة الحاوية على تخزين موجه بشكل صحيح. يشرح دليل تحديث الخادم المنزلي أن تعيينات الحجم تحافظ على بيانات التطبيق عبر إعادة الإنشاء، لكن الديمومة وحدها لا تخلق نقطة تراجع بعد أن يغير التطبيق تلك الملفات.
اختر وحدة التراجع قبل اختيار اللقطة
| الحالة التي يجب حمايتها | كائن التراجع | اللقطة فقط؟ |
|---|---|---|
| صورة الحاوية والعلامة | هضم صورة قديمة أو إصدار مثبت | لا حاجة إلى لقطة بيانات إذا لم يتغير شيء دائم |
| ملف التكوين، البيئة، المنافذ، والتثبيتات | تصدير التكوين تحت التحكم في الإصدار | لا؛ لقطة التخزين لا تستعيد تعريف النشر |
| ربط التثبيتات والأحجام المسماة مع الملفات العادية | لقطة نظام الملفات أو نسخة احتياطية للملفات تم التحقق منها | عادةً، عندما تكون الملفات في حالة سكون ويتم تضمين جميع المسارات |
| PostgreSQL أو MariaDB أو SQLite أو قاعدة بيانات نشطة أخرى | تفريغ مدرك للتطبيق، لقطة منسقة، أو نسخة إيقاف تشغيل نظيفة قصيرة | ليس تلقائيًا |
| الأسرار والشهادات والاعتمادات الخارجية | سجل نسخ احتياطي واسترداد سري مستقل | لا؛ قد تعيش خارج مجموعة البيانات التي تم التقاطها |
يجب أن تتضمن وحدة التراجع كل مكون يحتاجه التطبيق للبدء. قد يترك التراجع عن الصورة فقط مخطط قاعدة البيانات الجديد قائمًا، بينما قد يترك التراجع عن الحجم فقط صورة أو تكوين غير متوافق نشطًا.
التقط لقطة قبل التحديثات التي يمكن أن تعيد كتابة الحالة الدائمة
ترحيلات قواعد البيانات والمخططات
قم بعمل نسخة احتياطية واعية بالتطبيق أو لقطة منسقة قبل تحديث تذكر ملاحظات الإصدار فيه ترحيل المخطط، تحويل قاعدة البيانات، إعادة الفهرسة، أو خطوات الترقية أحادية الاتجاه. يجمع سير عمل تحديث الحاوية العملي صراحةً النسخ الاحتياطي لبيانات التطبيق مع تسجيل الإصدار الحالي قبل سحب بديل.
تغييرات تخطيط الحجم والأذونات
أنشئ نقطة تراجع عندما يغير التحديث مسارات التثبيت، ملكية UID/GID، دلائل قواعد البيانات، بيانات الوسائط، الصور المصغرة المولدة، أو تنسيق تخزين التطبيق. يمكن أن تجعل هذه التغييرات الحاوية القديمة غير قادرة على قراءة البيانات المحدثة حتى عندما لا تزال الملفات موجودة.
بيانات منزلية كبيرة أو يصعب إعادة إنشائها
التقط لقطة قبل تحديث مكتبات الصور، أنظمة الوثائق، تاريخ الأتمتة المنزلية، مديري كلمات المرور، أو بيانات الوسائط عندما يستغرق إعادة بناء الحالة وقتًا أطول من إنشاء واختبار نقطة التراجع.
تخطى اللقطة عندما يكون التحديث عديم الحالة حقًا
قد تضيف لقطة تخزين منفصلة قيمة قليلة عندما لا تحتوي الحاوية على مسار دائم قابل للكتابة، وكل التكوين قابل لإعادة الإنتاج، والبيانات الخارجية محمية بالفعل، والتراجع يعني بدء الصورة المثبتة سابقًا. تأكد من أن التطبيق لا يكتب بهدوء إلى حجم مجهول أو مسار مضيف خارج مجموعة البيانات المتوقعة.
سجّل هضم الصورة القديمة بدقة حتى في هذا المسار منخفض المخاطر. غالبًا ما يرغب مشغلو الخوادم المنزلية في هضم الصورة القديمة بحيث يمكن ربط مشكلة تم اكتشافها بعد عدة إعادة تشغيل بالإصدار الذي تم تغييره.
قد لا تكون لقطة نظام الملفات الحية متسقة مع التطبيق
تلتقط لقطة نظام الملفات نقطة زمنية، لكن قاعدة بيانات نشطة قد تحتوي على صفحات غير مكتملة في الذاكرة، معاملات مكتوبة جزئيًا، أو ملفات معتمدة يجب أن تتوافق مع بعضها البعض. تميز إرشادات النسخ الاحتياطي لقاعدة البيانات بين نسخة متسقة مع التعطل ولقطة متسقة مع التطبيق تُنشأ أثناء وضع النسخ الاحتياطي أو أثناء تهدئة قاعدة البيانات.
لتطبيق NAS منزلي صغير، قد يكون الخيار الآمن الأبسط هو تفريغ منطقي أو توقف نظيف قصير قبل الالتقاط. أرشيف عادي لحجم MySQL مباشر ليس مكافئًا؛ تنصح نصائح النسخ الاحتياطي للحاويات بأن توقف قاعدة البيانات قبل النسخ عند عدم استخدام طريقة واعية بالتطبيق.
استخدم مصفوفة المخاطر بدلاً من قاعدة لكل تحديث
| شرط التحديث | الحماية الموصى بها | لماذا |
|---|---|---|
| إصدار تصحيحي، لا ترحيل، خدمة بدون حالة | ثبت الصورة القديمة واحتفظ بتاريخ التكوين | لا يُتوقع تغيير الحالة المستمرة |
| التطبيق يكتب ملفات عادية في مجموعة بيانات ملتقطة بلقطة | لقطة سريعة قبل التحديث بالإضافة إلى نسخة احتياطية عادية | التراجع بسيط عندما يتم تغطية جميع المسارات |
| ترحيل قاعدة البيانات أو تنسيق تخزين جديد | نسخة احتياطية أصلية لقاعدة البيانات بالإضافة إلى لقطة منسقة | قد لا يفهم الصورة القديمة البيانات المهاجرة |
| مجموعات بيانات متعددة، قاعدة بيانات خارجية، أسرار، أو شهادات | قائمة التحقق من التبعيات ونسخ احتياطية منفصلة لكل مالك حالة | لقطة نظام ملفات واحدة لا يمكن أن تغطي التطبيق بالكامل |
| التحديث لا يمكن التراجع عنه أو لم يتم اختبار التراجع من قبل | نافذة الصيانة، اختبار الاستعادة المعزول، واحتفاظ أطول باللقطات | مسار التراجع غير المعروف هو الخطر الرئيسي |
استخدم سير عمل تحديث NAS المنزلي القابل للعكس
- اقرأ ملاحظات الإصدار الخاصة بالترحيلات، تغييرات الأذونات، الإعدادات المحذوفة، وأدنى إصدارات قاعدة البيانات.
- سجل هضم الصورة الحالية، وملف التكوين، ومتغيرات البيئة، ونقاط التوصيل، وإصدار التطبيق.
- أنشئ الحماية المطلوبة حسب مصفوفة المخاطر: لا لقطة، لقطة نظام ملفات سريعة، نسخ احتياطي لقاعدة بيانات واعي بالتطبيق، أو كلاهما.
- قم بتحديث مجموعة تطبيق واحدة في كل مرة واحتفظ بالصورة القديمة متاحة.
- اختبر تسجيل الدخول، والبيانات الأساسية، والمهام الخلفية، والتحميلات، وكتابات قاعدة البيانات، واستعادة أو تصدير تمثيلي واحد.
- احتفظ بنقطة التراجع قبل التحديث حتى يصمد التطبيق في الاستخدام المنزلي العادي ودورة النسخ الاحتياطي المنتظمة.
- قم بحذف اللقطة المؤقتة فقط بعد أن يمكن لنسخة احتياطية منفصلة إعادة بناء الحالة الحالية.
يجب اختبار التراجع على نسخة مكررة أو هدف منفصل عندما تسمح منصة التخزين بذلك. يمكن أن يؤدي التراجع المباشر إلى فقدان الحالة الأحدث؛ على سبيل المثال، يجب على مستخدمي ZFS فهم أن التراجع يلغي اللقطات الأحدث والتغييرات التي تم إنشاؤها بعد النقطة المحددة.
الأسئلة الشائعة
هل لقطة لحاوية قاعدة بيانات تعمل كافية؟
فقط عندما يمكن لقاعدة البيانات وطريقة التخزين إنتاج حالة متسقة قابلة للاسترداد بعد تعطل النظام أو عندما تكون اللقطة منسقة مع قاعدة البيانات. للتطبيقات المنزلية ذات القيمة الأعلى، استخدم نسخ الحاوية المتسق مع قاعدة البيانات بدلاً من افتراض أن لقطة الحجم الحي كافية.
كم من الوقت يجب الاحتفاظ بلقطة ما قبل التحديث؟
احتفظ بها حتى يجتاز التطبيق المحدث الفحوصات الوظيفية، ويصمد في الاستخدام العادي، ويكمل نسخة احتياطية منفصلة واحدة على الأقل تم التحقق منها. احتفظ بها لفترة أطول عندما تكون عمليات الترحيل لا رجعة فيها، أو قد تظهر المشاكل ببطء، أو يكون إعادة بناء مجموعة التطبيقات القديمة صعبًا.
اللقطة هي أداة تراجع قصيرة المدى، وليست بديلاً عن النسخ الاحتياطية ذات الإصدارات، أو سجل التكوين، أو استرداد الأسرار، أو حماية قواعد البيانات الواعية بالتطبيق. استخدمها عندما يمكن أن يغير التحديث الحالة، وتجنبها عندما يكون التحديث قابلًا للتخلص منه بالفعل ومسار التراجع مثبت.
المنتجات الموصى بها
الدعم والنصائح
المزيد للقراءة
هل يمكن لـ Plex مشاركة وحدة معالجة الرسومات (GPU) مع حاوية Docker أخرى؟
يمكن لـ Plex وحاوية أخرى غالبًا الوصول إلى وحدة معالجة الرسومات نفسها، لكن يجب اختبار دعم برنامج التشغيل، وتعيين الجهاز، وحِمل محرّك الفيديو، والذاكرة،...
كيفية معرفة ما إذا كان خطأ Plex ناتجًا عن العميل أم الخادم
أعِد إنتاج العنصر نفسه على عميل آخر، وقارن مسار الجلسة، ثم اجمع أدلة من الخادم فقط بعد أن يحدد النطاق موضع الفشل الفعلي.
كيفية إعداد ذاكرة التخزين المؤقت وموقع التخزين المؤقت لتحويل الترميز في Plex
احمِ حالة Plex الدائمة مع وضع الملفات المؤقتة للتحويل على مساحة تخزين محلية مناسبة، ثم تحقّق من التنظيف والمساحة الحرة وسلوك إعادة التشغيل.
