حلّ المجتمع

أنشئ نسخًا احتياطية مجدولة باستخدام rsync ومقاومة لإعادة التشغيل على ZimaOS مع Ofelia

A user moved weekly AppData and NAS backup scheduling into a persistent Portainer stack using Ofelia, rsync, and scripts stored on RAID storage.

الجدولة اللازمة للعمل مع حالة Docker المستمرة

أراد المؤلف إنشاء نسخ أسبوعية من AppData إلى مجموعة RAID 1، ونسخة ثانية من تلك المجموعة إلى قرص USB متصل باستمرار. لم تحتفظ crontab الخاصة بالنظام وتطبيق جدولة مجتمعي بالمهام بشكل موثوق بعد إعادة التشغيل، لذلك نقل المؤلف الجدولة إلى مكدس Ofelia مُدار عبر Portainer ومخزّن ضمن بيانات ZimaOS المستمرة.

فصل التصميم الناتج بين ثلاث طبقات: نصوص shell البرمجية على وحدة تخزين RAID، وحاوية Ofelia التي توفر الجدول، وحاويات rsync قصيرة العمر التي تنفذ كل عملية نسخ.

تخزين النصوص البرمجية والسجلات على وحدة تخزين مستمرة

وضع المثال النصوص البرمجية ضمن مسار مثل /media/RAID1/scripts. وتم تركيب هذا المجلد بوضع القراءة والكتابة داخل مجدول المهام باسم /scripts. كُتبت السجلات بجوار النصوص البرمجية بحيث يمكن فحصها عبر Files أو مشاركة شبكية بعد اكتمال المهمة.

كل مسار في المثال خاص بالتثبيت. قد يؤدي نسخ اسم RAID الخاص بالمؤلف من دون التحقق من مسار التركيب الفعلي إلى إرسال نسخة احتياطية إلى المكان الخطأ أو إلى فشل المهمة بصمت.

وفّرت Ofelia جدولة مستمرة بعد إعادة التشغيل

استخدم مكدس Portainer صورة Ofelia، وضبط restart: always، وركّب مجلد النصوص البرمجية، وخزّن تسميات الجدولة مع الحاوية. جدولة المثال AppData في الساعة 23:30 من كل يوم أحد، وبيانات NAS العامة في الساعة 23:45.

ofelia.job-local.appdata.schedule: "0 30 23 * * 0"
ofelia.job-local.appdata.command: "/bin/sh /scripts/backup_appdata.sh"
ofelia.job-local.nas_home.schedule: "0 45 23 * * 0"
ofelia.job-local.nas_home.command: "/bin/sh /scripts/backup_nas_home.sh"

أفاد المؤلف بأن المجدول ومهامه عادا إلى العمل خلال نحو دقيقة من إعادة التشغيل، من دون الحاجة إلى جلسة SSH أخرى.

أوقف نص AppData خدمة Plex قبل النسخ

لتقليل احتمال نسخ قاعدة بيانات Plex أثناء تغيّرها، أوقف النص خدمة Plex، وشغّل rsync من تركيب مصدر AppData للقراءة فقط، ثم أعاد تشغيل Plex. ثبّتت حاوية المجدول واجهة Docker CLI عند الحاجة، وتحكّمت في الحاويات الشقيقة عبر مقبس Docker.

يمنح تركيب /var/run/docker.sock المجدول تحكمًا واسعًا في مضيف Docker. كما أن تشغيله بصلاحيات root وبوضع privileged يزيد هذه الصلاحيات أكثر. يعرض الموضوع هذا باعتباره تصميم المؤلف العامل، وليس نموذجًا أمنيًا يطبّق مبدأ أقل الصلاحيات.

ينشئ rsync --delete نسخة مطابقة تمامًا، لا سجلًا بإصدارات متعددة

استخدم المثال rsync -avH --delete. يزيل الخيار --delete ملفات الوجهة التي لم تعد موجودة في المصدر. وينتج عن ذلك نسخة مطابقة تمامًا، لكنه قد يكرر أيضًا الحذف العرضي أو التلف.

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

لم تحل استمرارية الجدولة بعد إعادة التشغيل مشكلة إعادة توصيل USB

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

الأسئلة الشائعة

لماذا صمدت هذه الجدولة بعد إعادة التشغيل؟

كانت تعريفات المهام موجودة في مكدس Portainer مفعّل لإعادة التشغيل، وكانت النصوص البرمجية موجودة على وحدة تخزين مستمرة بدلًا من crontab نظام مؤقتة.

هل ينشئ هذا إصدارات تاريخية من النسخ الاحتياطية؟

لا. ينشئ أمر rsync الموثق نسخة مطابقة ويستخدم --delete. ويتطلب الاحتفاظ بالإصدارات تصميمًا مختلفًا.

لماذا أُوقفت خدمة Plex قبل نسخ AppData؟

فعل المؤلف ذلك لتقليل خطر نسخ قاعدة بياناتها أثناء تعديلها.