كيفية استعادة قاعدة بيانات Immich من نسخة احتياطية موثوقة

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

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

جمّد الحالة الفاشلة قبل استعادة أي شيء

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

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

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

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

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

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

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

ابدأ أولًا بهدف قاعدة بيانات نظيف ومتوافق

طابق طريقة الاسترداد مع الإصدار الذي أنشأ النسخة الاحتياطية. توفر إصدارات Immich الحالية استعادة قاعدة البيانات من خلال «الإدارة > الصيانة» ومن خلال مسار الإعداد الأولي لتثبيت جديد، بينما قد تتطلب النسخ الاحتياطية الأقدم تعليمات يدوية خاصة بالإصدار؛ فقد تغير سير عمل الاسترداد في الإصدار v2.5.0.

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

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

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

استعد التفريغ مرة واحدة وتوقف عند أول خطأ

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

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

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

تحقق من حالة قاعدة البيانات ومسارات الوسائط وكتابة جديدة

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

يجب أن تتوافق حالة قاعدة البيانات وملفات التطبيق والإعدادات والتحميلات عند الاسترداد. استخدم نسخة احتياطية متسقة لحاوية قاعدة البيانات كنموذج قبول، لا مجرد التحقق من بدء تشغيل PostgreSQL.

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