لماذا يفقد Immich الوصول إلى البيانات الدائمة بعد إعادة إنشاء المكدس؟

عندما يبدو Immich فارغًا أو يتعذر عليه قراءة مكتبته بعد إعادة إنشاء الحزمة، افترض أولًا أن البيانات الدائمة القديمة غير متصلة أو غير قابلة للقراءة، قبل افتراض أنها حُذفت.

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

أوقف المثيل الجديد وأثبت أن البيانات القديمة لا تزال موجودة

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

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

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

قارن نقاط الربط المُعاد إنشاؤها بالحزمة السابقة

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

قد يؤدي الربط الفاشل أو المتغير أو المفقود إلى ظهور مجلد فارغ داخل الحاوية، حتى عندما تكون البيانات المتوقعة لا تزال موجودة في مكان آخر على المضيف. استخدم فحوصات ربط وحدات تخزين Docker لمقارنة المصدر والوجهة ونوع الربط وهوية وحدة التخزين المُسمّاة لكل مسار دائم في Immich. يفسر عدم التطابق هنا مباشرة ظهور المثيل كأنه جديد.

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

تحقق من تركيب التخزين الخارجي قبل بدء Immich

إذا كانت بيانات Immich موجودة على تجمع أقراص HDD أو مشاركة NAS أو طبقة دمج أو نقطة تركيب خارجية أخرى، فتأكد من أن ذلك التخزين مركب فعليًا على المضيف قبل أن يبدأ Docker الحزمة. قد يظل مسار مثل /mnt/photos موجودًا كمجلد محلي عادي عندما يكون الجهاز الحقيقي غائبًا.

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

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

-15% OFF

ZimaBoard 2 - خادم منزلي صغير لأفكارك الكبيرة

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

تحقق من UID وGID وأذونات المجلدات دون إعادة كتابة كل شيء

قد تعمل الحزمة المُعاد إنشاؤها بخدمة ذات هوية رقمية أو مساحة أسماء للمستخدم أو سياق أمني مختلف عن السابق. وتختلف النتيجة عن فقدان الربط: فالمسار موجود والملفات مرئية من المضيف، لكن سجلات Immich تعرض أخطاء أذونات أو يتعذر عليها إنشاء الملفات المتوقعة.

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

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

أعد الاتصال بالحالة الأصلية وتحقق من إعادة إنشاء أخرى

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

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

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