النسخ الاحتياطي والاستعادة

يمكن لـ Rediacc نسخ المستودعات المشفرة احتياطياً إلى مزودي تخزين خارجيين واستعادتها على نفس الجهاز أو على جهاز مختلف. النسخ الاحتياطية مشفرة؛ يلزم بيانات اعتماد LUKS الخاصة بالمستودع للاستعادة.

تكوين التخزين

قبل إرسال النسخ الاحتياطية، قم بتسجيل مزود تخزين. يدعم Rediacc أي تخزين متوافق مع rclone: S3 وB2 وGoogle Drive وغيرها الكثير.

الاستيراد من rclone

إذا كان لديك بالفعل جهاز rclone بعيد مُكوَّن:

rdc config storage import --file rclone.conf

يستورد هذا تكوينات التخزين من ملف إعدادات rclone إلى التكوين الحالي. الأنواع المدعومة: S3 وB2 وGoogle Drive وOneDrive وMega وDropbox وBox وAzure Blob وSwift.

عرض وحدات التخزين

rdc config storage list

إرسال نسخة احتياطية

إرسال نسخة احتياطية من مستودع إلى تخزين خارجي:

rdc repo push --name my-app -m server-1 --to my-storage

يتحقق الإرسال دائماً من تثبيت المستودع الهدف قبل الكتابة. إذا لم يكن مثبتاً، تُلغى العملية.

الخيار	الوصف
--to <storage>	موقع التخزين الهدف
--to-machine <machine>	الجهاز الهدف للنسخ الاحتياطي من جهاز إلى جهاز
--dest <filename>	اسم ملف الوجهة المخصص
--checkpoint	إنشاء نقطة تحقق CRIU قبل الإرسال (للحاويات التي تحمل تسمية rediacc.checkpoint=true). الهدف يستعيد تلقائياً عند repo up
--force	استبدال نسخة احتياطية موجودة
--bwlimit <limit>	حد عرض النطاق الترددي لنقل rsync (مثال: 10M، 500K)
--tag <tag>	وسم النسخة الاحتياطية
-w, --watch	مراقبة تقدم العملية
--debug	تفعيل الإخراج التفصيلي
--skip-router-restart	تخطي إعادة تشغيل خادم المسار بعد العملية

سحب / استعادة نسخة احتياطية

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

rdc repo pull --name my-app -m server-1 --from my-storage

يتحقق السحب دائماً من تثبيت المستودع الهدف قبل الكتابة. إذا لم يكن مثبتاً، تُلغى العملية.

الخيار	الوصف
--from <storage>	موقع التخزين المصدر
--from-machine <machine>	الجهاز المصدر للاستعادة من جهاز إلى جهاز
--force	استبدال النسخة الاحتياطية المحلية الموجودة
--bwlimit <limit>	حد عرض النطاق الترددي لنقل rsync (مثال: 10M، 500K)
-w, --watch	مراقبة تقدم العملية
--debug	تفعيل الإخراج التفصيلي
--skip-router-restart	تخطي إعادة تشغيل خادم المسار بعد العملية

عرض النسخ الاحتياطية

عرض النسخ الاحتياطية المتاحة في موقع تخزين:

rdc repo backup list --from my-storage -m server-1

الإخراج عبارة عن جدول موحَّد يدمج كلا مجلدَي النسخ الاحتياطية المجدولة (hot/ و cold/) لرؤية كل نسخة احتياطية في عرض واحد:

العمود	المعنى
Mode	hot أو cold. مجلد النسخ الاحتياطي المجدول الذي يقع فيه هذا الإدخال
Name	اسم المستودع المُحلَّل من الإعدادات المحلية (يعود إلى GUID للمستودعات غير الموجودة في الإعدادات)
GUID	GUID المستودع على القرص
Size	حجم ملف النسخة الاحتياطية بصيغة قابلة للقراءة
Modified	الطابع الزمني UTC من وحدة التخزين الخلفية

للتنقيب في وضع واحد، مرّر --path:

rdc repo backup list --from my-storage -m server-1 --path hot
rdc repo backup list --from my-storage -m server-1 --path cold

تخطيط التخزين

تُحفظ النسخ الاحتياطية المجدولة ضمن مجلدات فرعية لكل وضع داخل المجلد المُكوَّن للتخزين، بحيث يستضيف نفس التخزين كلاً من تدفق الساعة وتدفق الأسبوع بشكل نظيف دون اختلاطهما:

<bucket>/<folder>/
├── hot/
│   ├── <guid-1>
│   ├── <guid-2>
│   └── ...
└── cold/
    ├── <guid-1>
    ├── <guid-3>
    └── ...

يمكن أن يظهر المستودع في كلا hot/ و cold/ (يلتقطه الجدول الساعي ويلتقطه الجدول الأسبوعي مرة أخرى). يُظهر الإدراج المدموج كلا الصفين بحيث يكون من الواضح أي تدفقات تغطي أي مستودعات.

المزامنة المجمّعة

إرسال أو سحب جميع المستودعات دفعة واحدة:

إرسال الكل إلى التخزين

rdc repo push --to my-storage -m server-1

سحب الكل من التخزين

rdc repo pull --from my-storage -m server-1

الخيار	الوصف
--to <storage>	التخزين الهدف (اتجاه الإرسال)
--from <storage>	التخزين المصدر (اتجاه السحب)
--repo <name>	مزامنة مستودعات محددة (قابل للتكرار)
--override	استبدال النسخ الاحتياطية الموجودة
--debug	تفعيل الإخراج التفصيلي
--skip-router-restart	تخطي إعادة تشغيل خادم المسار بعد العملية

النسخ الاحتياطي المجدول

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

أوضاع النسخ الاحتياطي

الوضع	السلوك	وقت التوقف
hot	لقطة BTRFS مأخوذة أثناء تشغيل الخدمات (متسقة عند التعطل)	لا يوجد
cold	إيقاف الخدمات، أخذ لقطة، إعادة تشغيل الخدمات، رفع اللقطة (متسقة على مستوى التطبيق)	نافذة إيقاف+تشغيل لكل مستودع، متوازية عبر المستودعات. راجع “تقدير وقت التوقف للنسخ الاحتياطي البارد” أدناه.

استخدم hot للخدمات التي تتحمل لقطات متسقة عند التعطل. استخدم cold عندما تحتاج إلى ضمان الاتساق ويمكنك قبول إعادة تشغيل مؤقتة.

دلالات النسخ الاحتياطي البارد

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

ما يضمنه النسخ الاحتياطي البارد:

• قبل اللقطة، يُوقَف كل حاوية تعمل في كل مستودع مُضمَّن بلطف عبر خطاف down() في Rediaccfile، ويُهدأ Docker daemon الخاص بكل مستودع. لذلك تكون اللقطة متسقة على مستوى التطبيق وليس فقط عند التعطل.
• يُحفظ مجموعة معرفات الحاويات التي كانت تعمل قبل اللقطة في ملف جانبي على /var/run/rediacc/cold-backup-<guid>.running.json. هذا هو مصدر الحقيقة لـ “ما يجب أن يعود عند الانتهاء.”
• بعد اللقطة، يُستدعى خطاف up() في Rediaccfile للمستودع لاستعادة مكدس compose الكامل.
• يُسجل ملف جانبي لحالة كل تشغيل على /var/run/rediacc/cold-backup-<guid>.status.json مرحلة كل محاولة ونتيجتها وأي خطأ.

ما لا يضمنه النسخ الاحتياطي البارد:

• up() هو جهد أفضل ما يمكن. يمكن أن يفشل لأسباب خارجة عن سيطرة النسخ الاحتياطي البارد (شرط depends_on: service_healthy لا يزال ينتظر، خطأ في بناء جملة ملف compose، فشل شبكة عابر أثناء سحب صورة). عند الفشل، يسجل النسخ الاحتياطي البارد الخطأ على مستوى الخطأ، يكتب الملف الجانبي للحالة، وينتقل إلى المستودع التالي.
• عند فشل up()، يبدأ إعادة تشغيل مباشرة احتياطية: يُقرأ الملف الجانبي للتشغيل ويُعاد تشغيل كل معرف حاوية مسجل عبر Docker API مباشرة (بدون compose). هذا يُعيد الخدمات حتى في حالة وجود مشكلة في سير compose، وإن كان ذلك دون إعادة تشغيل أي خطافات Rediaccfile.
• إذا فشلت حتى الاستعادة الاحتياطية لبعض معرفات الحاويات (مثلاً، Docker daemon نفسه معطل)، يُبقى الملف الجانبي في مكانه حتى يتمكن watchdog الموجه من الاستمرار في المحاولة في كل دورة.

استرداد Watchdog: في كل دورة، يتحقق watchdog من وجود ملف جانبي للتشغيل. أي معرف حاوية مُدرج هناك يكون متوقفاً حالياً يُعاد تشغيله، بغض النظر عن سياسة restart_policy المحفوظة للحاوية. هذا يعني أن الخدمات ذات restart: on-failure (التي لن يُعيد Docker تشغيلها بعد توقف نظيف) ستعود بعد النسخ الاحتياطي البارد. بمجرد أن تعمل جميع الحاويات المُدرجة، يُحذف الملف الجانبي.

كيف يكتشف المشغلون الأعطال:

• rdc machine query --name <machine> --containers يُظهر حالة التشغيل. قارن مع المجموعة المتوقعة.
• /var/run/rediacc/cold-backup-<guid>.status.json على الجهاز. افحص عبر rdc term connect -m <machine> -r <repo> -c "cat /var/run/rediacc/cold-backup-$GUID.status.json". success: false مع startedAt قديم يعني أن آخر نسخة احتياطية لم تكتمل بنظافة.
• السجلات من تشغيل نسخ renet الاحتياطي (journalctl -u renet-* أو استدعاء rdc machine deploy-backup المباشر) تصدر سطر ملخص نهائي بالشكل Cold backup: post-snapshot restart summary total=N compose_ok=N fallback_ok=N failed=N failed_repos=[...]. failed_repos غير الفارغة هي هدف grep.

تقدير وقت التوقف للنسخ الاحتياطي البارد

كل مستودع يكون متوقفاً فقط خلال نافذة down() + up() الخاصة به. على مضيف في حالة تشغيل، تكون هذه الأوقات عادةً:

نوع المستودع	الإيقاف+التشغيل النموذجي
صغير (1-2 حاوية، بدون قاعدة بيانات)	5-15 ثانية
متوسط (تطبيق ويب + ذاكرة تخزين مؤقت)	20-45 ثانية
ثقيل (قاعدة بيانات + طوابير + بريد)	60-120 ثانية

خطوة اللقطة (btrfs subvolume snapshot -r) هي O(1) بغض النظر عن حجم المستودع: 0.1-1 ثانية. لا يُبقى المستودع متوقفاً خلال لقطات المستودعات الأخرى. يعمل المحمل بعد ذلك ضد لقطة للقراءة فقط بينما تكون جميع المستودعات قد عادت للعمل.

الوقت الإجمالي (wall-clock) لكامل التشغيل يُحدده عدد المستودعات التي تُعاد تشغيلها بالتوازي. يشتق renet هذه القيمة من المضيف:

concurrency = min(repoCount, max(2, NumCPU/2), 8)

أمثلة:

المضيف	المستودعات	التزامن	وقت إعادة التشغيل
جهاز افتراضي 4 CPU	5 مستودعات، بمتوسط 30 ثانية لكل واحد	2	~75 ثانية
خادم 16 CPU	10 مستودعات، بمتوسط 40 ثانية لكل واحد	8	~80 ثانية
عقدة أسطول 64 CPU	50 مستودعاً، بمتوسط 40 ثانية لكل واحد	8	~4 دقائق

تجاوز عبر متغير بيئة: اضبط REDIACC_COLD_BACKUP_CONCURRENCY=N في بيئة خدمة النسخ الاحتياطي (عادةً عبر systemd drop-in) لتثبيت قيمة محددة. =1 يفرض إعادة تشغيل تسلسلية صارمة، وهو مفيد عند تصحيح حلقة تعطل في خطاف up() لأحد المستودعات.

إذا كنت تشغل مستودعاً حساساً للكمون (تطبيق ويب عام، بريد)، فإن وقت توقفه مقيد بإيقافه وتشغيله الخاص (عادةً 30-90 ثانية)، وليس بطول التشغيل كاملاً. تُجدول المستودعات في فتحات التزامن بترتيب اكتشافها؛ لا يوجد طابور أولوية. قسّم المستودعات الثقيلة إلى استراتيجياتها الخاصة المحدودة بـ --exclude إذا احتجت إلى جدولة أدق.

النسخ الاحتياطية طويلة الأمد وتداخل الجداول

النسخ الاحتياطي البارد الذي يستغرق وقتاً أطول من فاصل جدوله الخاص (على سبيل المثال، قد يحتاج أول seed لمستودع بحجم 500 جيجابايت عبر خط متواضع إلى أكثر من 24 ساعة، وخلالها يُفعَّل المؤقت الليلي مرة أخرى) لا يضع في قائمة الانتظار ولا يُشغّل تشغيلاً ثانياً. وحدة systemd Type=oneshot هي نسخة واحدة: عندما يُفعَّل المؤقت والخدمة بالفعل في حالة activating، يدمج systemd التشغيل في المهمة القائمة. لا تُشغَّل أي عملية جديدة، ولا يُوضع أي تشغيل في قائمة الانتظار لوقت لاحق.

تحديداً، تشغيل يبدأ يوم الاثنين الساعة 03:00 UTC وينتهي ظهر يوم الخميس:

اليوم	إطلاق الساعة 03:00 UTC	النتيجة
الاثنين	الإطلاق الأول	يبدأ التشغيل
الثلاثاء	الإطلاق الثاني	تم تجاهله بصمت (التشغيل السابق لا يزال نشطاً)
الأربعاء	الإطلاق الثالث	تم تجاهله بصمت (التشغيل السابق لا يزال نشطاً)
الخميس	ينتهي التشغيل ظهراً	لا توجد استعادة؛ التشغيل التالي هو الجمعة الساعة 03:00 UTC

توجيه Persistent=true للمؤقت لا يُنقذ هذه الإطلاقات. يُعيد Persistent=true تشغيل الإطلاقات التي فُقدت لأن المؤقت نفسه كان غير نشط (النظام متوقف، المؤقت معطل). أما الإطلاقات التي جرى تجاهلها لأن الخدمة كانت مشغولة، فقد ضاعت.

هذا السلوك الافتراضي مقصود. تشغيل نسختين احتياطيتين باردتين بالتوازي على نفس datastore سيتنافس على مسار لقطة BTRFS وعلى remote rclone وعلى sidecars كل مستودع في /var/run/rediacc/cold-backup-<guid>.status.json. التسلسل خلف نسخة طويلة الأمد هو النتيجة الآمنة.

أثر المراقبة. النسخ الاحتياطي المعلق (على سبيل المثال، rclone عالق في ثقب أسود للشبكة) يُسقط بصمت كل إطلاق تالٍ للمؤقت. لا يُصدر المجدول أي إنذار. راقب systemctl show <unit> -p ActiveEnterTimestamp: إذا كانت الخدمة في حالة activating لفترة أطول من مدة التشغيل المتوقعة (مثلاً، أكثر من 48 ساعة على مؤقت ليلي)، فقم بالتحقيق.

إذا كنت بحاجة إلى تنفيذ كل إطلاق مجدول، فبدّل المؤقت من OnCalendar=<cron> إلى OnUnitInactiveSec=<فاصل>. يُطلق ذلك بعد N ساعة من اكتمال التشغيل السابق بدلاً من جدول ساعة حائط ثابت، فلا تسبب التشغيلات الطويلة إسقاطات. بل فقط تدفع التشغيل التالي لاحقاً. المقايضة هي انحراف الجدول: يصبح 03:00 الليلي لديك «24 ساعة بعد انتهاء التشغيل الأخير».

تعريف استراتيجية

الإعداد الافتراضي القياسي هو تقسيم باستراتيجيتين: تدفق ساخن سريع كل ساعة يلتقط كل مستودع، وتدفق بارد أسبوعي أبطأ يأخذ لقطات متسقة على مستوى التطبيق. تكتب الاستراتيجيتان إلى مجلدات فرعية مختلفة في التخزين (hot/ و cold/) بحيث لا تختلط النسخ الاحتياطية أبداً.

rdc config backup-strategy set \
  --name hourly-hot \
  --destination my-storage \
  --cron "0 * * * *" \
  --mode hot \
  --bwlimit 20M \
  --enable

rdc config backup-strategy set \
  --name weekly-cold \
  --destination my-storage \
  --cron "15 3 * * 0" \
  --mode cold \
  --exclude very-large-repo \
  --enable

مرشح --exclude على الاستراتيجية الباردة هو منفذ الهروب الموصى به للمستودعات الكبيرة جداً التي لا تتسع في نافذة الصيانة الأسبوعية لديك. لا تزال الاستراتيجية الساخنة الساعية تغطيها؛ والباردة تتخطاها فحسب. تتطابق أسماء المستودعات في --exclude مع اسم المستودع في الإعدادات المحلية (بدون :tag).

الخيار	الوصف
--name <name>	اسم الاستراتيجية (يُستخدم لربط الجهاز)
--destination <storage>	مزود التخزين للرفع إليه
--cron <expression>	تعبير cron (مثال: "0 2 * * *" يومياً الساعة 2 صباحاً)
--mode <hot|cold>	وضع النسخ الاحتياطي
--bwlimit <limit>	حد عرض النطاق الترددي للرفع (مثال: 10M)
--include <pattern>	مرشح التضمين (قابل للتكرار)
--exclude <pattern>	مرشح الاستثناء (قابل للتكرار)
--enable / --disable	تفعيل أو تعطيل الاستراتيجية

عرض الاستراتيجيات

rdc config backup-strategy list
rdc config backup-strategy show --name weekly-cold

إزالة استراتيجية

rdc config backup-strategy remove --name weekly-cold

ربط الاستراتيجيات بجهاز

في التكوين الخاص بك، اربط اسماً واحداً أو أكثر من أسماء الاستراتيجيات بجهاز:

{
  "machines": {
    "hostinger": {
      "backupStrategies": ["hourly-hot", "weekly-cold"]
    }
  }
}

عمليات النسخ الاحتياطي

نشر الجدول على الجهاز

ادفع الاستراتيجيات المرتبطة إلى جهاز كمؤقتات systemd:

rdc machine backup schedule -m server-1
rdc machine backup schedule -m server-1 --dry-run

النشر هو مُوفِّق حالة. يقرأ ملفات الوحدة الحالية وحالة systemd على الجهاز، ويقارنها بما ستنتجه التهيئة (SHA-256 لكل ملف)، ولا يَمَسّ إلا الوحدات التي تغيّر محتواها فعليًا. إعادة التشغيل دون تغييرات في التهيئة عملية لا تأثير لها: لا كتابات ولا daemon-reload ولا اضطراب في المؤقتات.

--dry-run يطبع الخطة لكل استراتيجية (created، updated (service, timer, env)، unchanged، removed) دون مَس الجهاز. استخدمه مع --debug لطباعة محتوى الوحدات المُولَّدة أيضًا؛ تُخفى رموز rclone.

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

--reset-failed اختياري. عند تمريره، يمسح حالة الفشل في systemd على الخدمات المُعدَّلة بعد نشر ناجح. معطّل افتراضيًا حتى تظل إشارات الفشل السابقة مرئية للتنبيهات.

تشغيل نسخة احتياطية الآن

تشغيل نسخة احتياطية فوراً دون انتظار المؤقت. يعمل حتى لو لم يُنشر أي مؤقت، باستخدام systemd-run للتنفيذ الآني:

rdc machine backup now -m server-1
rdc machine backup now -m server-1 --strategy weekly-cold

عرض حالة النسخ الاحتياطي

عرض الحالة الحالية لمؤقتات النسخ الاحتياطي ونتائج المهام الأخيرة:

rdc machine backup status -m server-1
rdc machine backup status -m server-1 --strategy hourly-hot

إلغاء نسخة احتياطية جارية

rdc machine backup cancel -m server-1
rdc machine backup cancel -m server-1 --strategy weekly-cold

ترحيل المستودعات

نقل مستودع من جهاز إلى آخر:

rdc repo migrate --name my-app --from server-1 --to server-2

الخيار	الوصف
--name <repo>	المستودع المراد ترحيله
--from <machine>	الجهاز المصدر
--to <machine>	الجهاز الهدف
--provision	توفير المستودع في الوجهة قبل النقل
--checkpoint	إنشاء نقطة تحقق CRIU قبل الترحيل
--skip-dns	تخطي تحديث سجلات DNS بعد الترحيل
--bwlimit <limit>	حد عرض النطاق الترددي للنقل (مثال: 50M)

ينقل الترحيل بيانات المستودع المشفرة عبر rsync. يبقى المستودع المصدر سليماً حتى تقوم بإزالته صراحةً.

تصفح التخزين

تصفح محتويات موقع تخزين:

rdc storage browse --name my-storage

أفضل الممارسات

• جدولة النسخ الاحتياطي البارد اليومي للحصول على لقطات متسقة على مستوى التطبيق للبيانات الحيوية
• استخدام النسخ الاحتياطي الساخن للقطات عالية التكرار حيث لا يُقبل أي توقف
• اختبار الاستعادة بشكل دوري للتحقق من سلامة النسخ الاحتياطية
• استخدام مزودي تخزين متعددين للبيانات الحيوية (مثال: S3 + B2)
• الحفاظ على أمان بيانات الاعتماد؛ النسخ الاحتياطية مشفرة لكن بيانات اعتماد LUKS مطلوبة للاستعادة