لم تكن بيانات المصدر مفقودة بوضوح. فبعد إعادة ضبط ZimaOS، ظل RAID6 موجودًا، كما ظلت أدلة مثل upload, pgdata, thumbs, profile، و encoded-video كانا لا يزالان موجودين. تكمن المشكلة في أن حزمة Immich المعاد تثبيتها لم تكن متصلة بحالة قاعدة البيانات/المكتبة القديمة بطريقة تستعيد فهرس الصور السابق.
كانت النصيحة الأكثر أمانًا في المصدر هي: لا تحذف مجلدي upload وpgdata القديمين أو تنقلهما بعد. لا يعيد Immich بناء فهرسه الكامل بمجرد العثور على ملفات الصور على القرص. تحتوي قاعدة البيانات على مسارات الملفات والمستخدمين والألبومات والبيانات الوصفية وحالة التطبيق. وتوضح وثائق Immich v3 الحالية هذه العلاقة صراحةً، وتوصي بإنشاء نسخة احتياطية من ملفات الأصول وقاعدة البيانات معًا.
أولًا، أكّد مسار تركيب RAID الفعلي
استخدم المصدر ما يلي:
ls -la /media
find /media -maxdepth 4 -type d \( -iname "immich" -o -iname "pgdata" -o -iname "upload" \)ووجد ما يلي:
/media/photos/immich
/media/photos/immich/pgdata
/media/photos/immich/uploadأثبت ذلك أن مجلدات Immich القديمة كانت لا تزال موجودة على RAID.
/media/ZimaOS-HD → /DATA لم يثبت أن Immich كان يستخدم قرص نظام التشغيل
شعر المستخدم بالقلق بسبب العبارة التالية:
/media/ZimaOS-HD -> /DATAلكن المجتمع أوضح بشكل صحيح أن هذه علاقة ربط/رمز تعريفي في ZimaOS. ووجودها لا يخبرك بمسارات المضيف التي تستخدمها حاويات Immich فعليًا.
فحص نقاط الربط الفعلية في Docker
أوصى النقاش بالتحقق مما يلي:
docker inspect immich-server --format '{{json .Mounts}}'
docker inspect immich-postgres --format '{{json .Mounts}}'هذا أكثر موثوقية من افتراض أن لقطة شاشة أو ذاكرة قديمة تعكس إعدادات الحاوية قيد التشغيل.
بيانات pgdata القديمة لا تقل أهمية عن ملفات الصور القديمة
إذا أدت إعادة التثبيت إلى تهيئة قاعدة بيانات جديدة تمامًا بدلًا من القاعدة القديمة، فقد تظل الملفات موجودة بينما يبدو Immich فارغًا.
يستخدم Immich الحالي UPLOAD_LOCATION وDB_DATA_LOCATION
يفصل Compose الحالي في Immich v3 بين موقع الأصول على المضيف وموقع Postgres باستخدام UPLOAD_LOCATION و DB_DATA_LOCATIONتذكر الجهة المطوّرة صراحةً أن مشاركات الشبكة غير مدعومة لمسار قاعدة البيانات.
استخدم نموذج التخزين الحالي في Immich.
النسخة الاحتياطية لقاعدة البيانات أكثر أمانًا من إعادة إرفاق مجلد pgdata قديم وقيد التشغيل عبر الإصدارات
كان المصدر يعمل بإصدار Immich v2.7.2. أما Immich الحالي فهو v3. عند الاسترداد بين الإصدارات، يكون سير عمل النسخ الاحتياطي والاستعادة لقاعدة البيانات من الجهة المطوّرة أكثر أمانًا من افتراض إمكانية إرفاق مجلد بيانات Postgres قديم ببساطة بصورة قاعدة بيانات أحدث.
راجع عملية النسخ الاحتياطي والاستعادة الحالية في Immich.
لا تُعد ترتيب مجلدات الأصول الداخلية في Immich يدويًا
تحذّر وثائق Immich الحالية من أن مجلدات مثل library, upload, thumbs, profile، و encoded-video تُدار بواسطة التطبيق. قد يؤدي نقل الملفات الفردية أو حذفها من خلف Immich إلى إنشاء أصول مفقودة أو غير متتبعة.
المستخدم الذي أبلغ عن المشكلة لم يؤكد نجاح الاسترداد
اقترح أعضاء المجتمع عدة أساليب لربط المسارات، بما في ذلك تركيب مجلد أب واحد، لكن jerlo قرر في النهاية ترك المشكلة جانبًا وبدأ من جديد على نظام آخر. لذلك، لا يؤكد المنتدى أن أي ربط لمسار معيّن هو الحل النهائي.
يفضّل Immich حاليًا جذر رفع مُدارًا بدلًا من ربط كل مجلد فرعي يدويًا
تُظهر لقطات الشاشة المصدر عمليات ربط يدوية لـ upload, thumbs, profile, library, encoded-video، والنسخ الاحتياطية واحدًا تلو الآخر. أما Compose الحالي من المصدر الأساسي فيتمحور حول UPLOAD_LOCATION، مع تولّي Immich إدارة مجلداته الفرعية الداخلية أسفل ذلك الجذر.
عند إعادة البناء على إصدار أحدث من Immich، استخدم تخطيط Compose/التخزين الحالي بدلًا من إعادة إنتاج مجموعة تاريخية من عمليات ربط المجلدات الفرعية، ما لم تتطلب الحزمة ذلك تحديدًا.
أبقِ مسار بيانات Postgres على وحدة تخزين محلية مدعومة
تنص وثائق Immich الحالية صراحةً على أن المشاركات الشبكية غير مدعومة لـ DB_DATA_LOCATION. قد يكون نظام ملفات RAID/التخزين المتصل محليًا مناسبًا، لكن دليل قاعدة البيانات المثبّت عبر SMB/NFS ليس مسار قاعدة البيانات المدعوم.
يتطلب الاسترداد الكامل لـ Immich كلاً من الأصول وقاعدة البيانات
تنص وثائق النسخ الاحتياطي الحالية لـ Immich على أن نسخ قاعدة البيانات الاحتياطية تتضمن البيانات الوصفية ومعلومات المستخدمين، لكنها لا تتضمن أصول الصور/الفيديو. ويجب نسخ شجرة الأصول احتياطيًا بشكل منفصل واستعادتها إلى جانب نسخة احتياطية متوافقة من قاعدة البيانات.
وهذا يفسر سبب كون عبارة «ما تزال ملفات الرفع موجودة» مطمئنة لكنها غير كافية في الحالة المصدر.
لا تُرفق دليل pgdata قديمًا وقيد التشغيل بصدفة بإصدار مختلف من Postgres أو صورة مختلفة
دليل بيانات Postgres الخام حساس للإصدار. إذا كانت البيئة القديمة والحزمة الجديدة تستخدمان إصدارات مختلفة من Postgres أو Immich، ففضّل تفريغ قاعدة البيانات واستعادتها بطريقة مدعومة أو اتبع مسار ترحيل موثّق. أنشئ نسخة احتياطية مطابقة للبايت من النسخة القديمة pgdata قبل التجربة.
الأسئلة الشائعة حول استرداد Immich
هل أدى إعادة ضبط ZimaOS إلى محو مجلدات الصور المصدر الموجودة على RAID6؟
لا. ذكر المستخدم أن RAID والمجلدات/الملفات الموجودة بقيت سليمة.
هل ستؤدي مطابقة ملفات الصور القديمة وحدها إلى استعادة مكتبة Immich؟
ليس بالضرورة. يحتاج Immich أيضًا إلى حالة قاعدة البيانات/الفهرس المقابلة.
ما الذي ينبغي حمايته قبل التجربة؟
التخزين الكامل للأصول بالإضافة إلى قاعدة البيانات أو نسخة احتياطية موثَّقة من قاعدة البيانات.
