امنع النسخ الاحتياطية غير المتسقة لـ Immich من خلال التعامل مع قاعدة البيانات والوسائط كوحدة استرداد واحدة، مع التحكم عمدًا في ترتيب الالتقاط ونشاط الكتابة.
قد تحتوي النسخة الاحتياطية على كل ملف طُلب منها نسخه، ومع ذلك تفشل عملية الاستعادة إذا كانت قاعدة البيانات تشير إلى أصول لم يتم التقاطها، أو إذا كانت نسخة الوسائط تمثل نقطة زمنية مختلفة عن الكتالوج. حدّد حدود الاتساق أولًا، واختر طريقة متوقفة أو مباشرة منسّقة، ثم تحقّق من النتيجة في بيئة معزولة.
حدّد وحدة الاسترداد قبل جدولة النسخة الاحتياطية
أدرج قاعدة بيانات PostgreSQL، والوسائط المُحمّلة، وبيانات الملف الشخصي، وإعدادات النشر، وقيم البيئة، والأسرار، وأي مسارات تخزين مخصّصة مطلوبة لإعادة إنشاء الخدمة. صنّف الصور المصغرة المُنشأة، ومقاطع الفيديو المُرمّزة، وملفات النماذج بشكل منفصل وفقًا لسياسة الاسترداد، أي ما إذا كانت تحميها أو تعيد إنشاءها.
تشرح مقارنة ZimaSpace بين النسخ الاحتياطية المباشرة والمتوقفة لـ Immich خيار الاتساق الأساسي. وتذهب آلية الوقاية هذه خطوة أبعد: أيًا كانت الطريقة التي تختارها، يجب أن تنتج نقطة موثّقة يمكن استعادتها دون التخمين بشأن قاعدة البيانات التي تنتمي إليها نسخة الوسائط.
دوّن ترتيب الاستعادة بجانب نطاق النسخة الاحتياطية. إذا كانت الخطة تقول «استعادة الصور» لكنها لا تحدد تفريغ قاعدة البيانات، والإعدادات، وبيانات الاعتماد، وتعيينات التخزين التي تعيد ربط تلك الصور بالمستخدمين والألبومات، فإن تعريف النسخة الاحتياطية يكون غير مكتمل قبل بدء أول تشغيل مجدول.
استخدم التقاطًا بعد الإيقاف عندما تكون الحدود الأبسط مقبولة
بالنسبة إلى منزل صغير يمكنه تحمّل فترة صيانة قصيرة، أوقف التحميلات وأوقف خدمات التطبيق التي تكتب حالة المكتبة. أنشئ نسخة احتياطية من قاعدة البيانات، والتقط الوسائط والإعدادات، ثم أعد التشغيل فقط بعد أن تحمل اللقطة أو النسخة وقتًا واضحًا ونتيجة إكمال مؤكدة.
لا يجعل إيقاف التطبيق مسارًا خاطئًا صحيحًا تلقائيًا. تحقّق من نجاح تصدير قاعدة البيانات، ومن تضمين جذور الوسائط المقصودة، ومن استقلال وجهة النسخة الاحتياطية عن البيانات المباشرة التي يُفترض أن تستعيدها. سجّل وقتي البدء والانتهاء حتى تتمكن عمليات الاستعادة اللاحقة من تحديد الجيل المحدد بدقة.
تنجح الطريقة عندما لا تحدث أي عمليات كتابة من التطبيق أثناء الالتقاط، وعندما تعيد استعادة اختبارية المستخدمين وأعداد الأصول والألبومات والملفات الأصلية المختارة كما هو متوقع. وإذا تجاوز وقت التوقف بانتظام ما يمكن للأسرة تحمّله، فانتقل إلى طريقة مباشرة منسّقة بدلًا من السماح باستئناف التحميلات بهدوء في منتصف نسخ ملف.
في النسخ الاحتياطية المباشرة، التقط قاعدة البيانات والملفات بترتيب معروف
عندما يجب أن يظل Immich متاحًا، أنشئ تفريغًا متسقًا أصليًا لقاعدة البيانات بدلًا من نسخ مجلد بيانات PostgreSQL النشط كملفات عادية. ثم التقط شجرة الوسائط أو أنشئ لقطة لها بالترتيب الموثّق، مع تتبّع التحميلات التي تصل أثناء نافذة النسخ الاحتياطي.
يوضّح سير عمل النسخ الاحتياطي لقاعدة بيانات Immich العملي النهج المدرك لقاعدة البيانات. قد تختلف الأوامر وأسماء الحاويات باختلاف النشر، لذا يتمثل المبدأ القابل للنقل في طلب نسخة احتياطية متسقة من PostgreSQL بدلًا من الوثوق بنسخة عودية مباشرة من ملفات قاعدة البيانات الحية.
فضّل ترتيبًا لا يمكن أن يترك قاعدة البيانات المستعادة تشير إلى وسائط لم تدخل النسخة الاحتياطية قط. فإذا احتوت نسخة نظام الملفات على ملفات إضافية لا تعرفها قاعدة البيانات بعد، فيمكن تسوية ذلك بأمان أكبر من غياب الملفات الأصلية التي تشير إليها سجلات قاعدة البيانات. وثّق أي تحميلات تتجاوز الحدود الزمنية.
نسّق لقطات نظام الملفات مع خطافات قاعدة البيانات بدلًا من افتراض الذرية
تُعد لقطات نظام الملفات قيّمة لأنها تلتقط وحدة تخزين بسرعة، لكنها لا تجعل نظامين يتغيران بشكل مستقل متسقين معاملاتيًا من تلقاء نفسها. فإذا كانت قاعدة البيانات والوسائط موجودتين على مجموعتي بيانات أو جهازين مختلفين، فحدّد خطافات قبل اللقطة وبعدها، واجعل توقيتها ظاهرًا في سجل النسخ الاحتياطي.
يوضح مثال من عام 2026 يجمع بين برامج النسخ الاحتياطي وخطافات لقطات Btrfs سبب حاجة تنسيق اللقطات إلى حدود صريحة للتطبيق أو قاعدة البيانات. استخدم الفكرة لتنسيق عمليات الالتقاط، ولا تنسخ أوامر نظام الملفات فيه حرفيًا إلى تخطيط مختلف.
إذا تعذّرت على أداة اللقطات تنسيق الحد الزمني بين قاعدة البيانات والوسائط، فارجع إلى تفريغ منطقي لقاعدة البيانات مع نسخة احتياطية للوسائط بدلًا من الادعاء بتحقيق استرداد ذري. لا يُبرَّر التعقيد إلا عندما يثبت تمرين الاستعادة أن الالتقاط الأسرع يعيد حالة متماسكة للتطبيق.
اجعل اختبار الاستعادة جزءًا من جدول النسخ الاحتياطي
لا يثبت نجاح مهمة النسخ الاحتياطي سوى اكتمال الالتقاط. اختر جيلًا حديثًا دوريًا، واستعده تحت اسم مضيف معزول، واربط وحدة التخزين المتوقعة، وتحقّق من المستخدمين، والملفات الأصلية النموذجية، والألبومات، والأذونات، وسلوك البحث، ونسخة احتياطية جديدة من قاعدة البيانات للمثيل المستعاد.
يؤكد العرض العام لاسترداد PostgreSQL ضمن التخطيط للنسخ الاحتياطي والاستعادة أهمية التحقق من الاستعادة وأهدافها، بدلًا من اعتبار إنشاء التفريغ نهاية العملية. طبّق الانضباط نفسه على وحدة استرداد Immich الموحّدة.
اعتبر سياسة النسخ الاحتياطي فاشلة إذا نجحت استعادة قاعدة البيانات لكن كانت الملفات مفقودة، أو إذا فُتحت الوسائط دون المستخدمين أو العلاقات، أو إذا كان الاسترداد يعتمد على سر مخزّن فقط على المضيف المتعطل. أصلح النطاق أو الترتيب أو الاحتفاظ أو الاستقلالية قبل زيادة وتيرة النسخ الاحتياطي؛ فالمزيد من النسخ غير المتسقة لا ينشئ نقطة استرداد موثوقة.
الدعم والنصائح
المزيد للقراءة

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

كيفية منع تكرار المهام أو عمليات الاستيراد في Immich
افصل المهام المتكررة عن الأصول المكررة. استخدم مسارًا أساسيًا واحدًا للإدخال، وتحكّم في عمليات إعادة المحاولة وتغييرات المسارات، ثم اختبر إعادة الإدخال على مجموعة...

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

