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

يمكن لـ 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

تُحفظ النسخة الاحتياطية في مجلد hot/ داخل التخزين إذا كان المستودع مُحمَّلًا وقت الإرسال، وفي cold/ إذا كان غير مُحمَّل. هذا التخطيط نفسه تستخدمه النسخ الاحتياطية المجدولة، لذا يعرض rdc repo backup list كل نسخة في جدول واحد.

الخيار	الوصف
--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 backup schedule المباشر) تصدر سطر ملخص نهائي بالشكل 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 ساعة بعد انتهاء التشغيل الأخير».

اللقطات والانقطاعات ومساحة التجمع

تعمل كل عملية push من لقطة مؤقتة لمخزن البيانات، بحيث تكون البيانات المرفوعة متسقة حتى وهي المستودعات تستمر في الكتابة. ما دامت النسخة الاحتياطية جارية، تبقى اللقطة تُشير إلى كل كتلة تشاركها مع المستودعات الحية: تُحرّر عمليات الحذف وtrim مساحة أقل في التجمع حتى تنتهي الدورة وتُحذف اللقطة. يُظهر تقرير صحة التخزين مقدار المساحة التي تحجزها لقطات النسخ الاحتياطي حالياً.

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

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

الإعداد الافتراضي القياسي هو تقسيم باستراتيجيتين: تدفق ساخن سريع كل ساعة يلتقط كل مستودع، وتدفق بارد أسبوعي أبطأ يأخذ لقطات متسقة على مستوى التطبيق. تكتب الاستراتيجيتان إلى مجلدات فرعية مختلفة في التخزين (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"]
    }
  }
}

الربط هو إعداد محلي فقط. تعريف استراتيجية وربطها بجهاز لا يؤثر على الجهاز نفسه. شغّل rdc machine backup schedule -m <machine> (راجع نشر الجدول على الجهاز) لنشر مؤقتات systemd، وأعد تشغيله بعد أي تغيير في الاستراتيجية أو الربط.

اختيار الوضع الساخن أو البارد والتصفية لكل مستودع

الساخن مقابل البارد: نظرة سريعة

	الساخن	البارد
الاتساق	متسق عند التعطل (لقطة BTRFS أثناء التشغيل)	متسق على مستوى التطبيق (إيقاف - لقطة - تشغيل)
وقت التوقف	لا يوجد	نافذة إيقاف+تشغيل لكل مستودع (عادةً 5-120 ثانية)
التكرار المناسب	عالٍ (مثل كل ساعة)	منخفض (مثل يومياً أو أسبوعياً)
الاستخدام النموذجي	شبكة أمان متكررة	نسخ احتياطي مجدول بضمان الاتساق

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

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

تصفية المستودعات لكل استراتيجية

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

# الاستراتيجية الساخنة: نسخ احتياطي لكل شيء كل ساعة
rdc config backup-strategy set \
  --name hourly-hot \
  --destination my-storage \
  --cron "0 * * * *" \
  --mode hot \
  --bwlimit 6M \
  --enable

# الاستراتيجية الباردة: نسخ احتياطي لكل شيء أسبوعياً، باستثناء مجموعة البيانات المشتقة الكبيرة
rdc config backup-strategy set \
  --name weekly-cold \
  --destination my-storage \
  --cron "15 3 * * 0" \
  --mode cold \
  --exclude analytics-demo \
  --enable

متى يُستثنى مستودع من الاستراتيجية الساخنة المتكررة

استبعد مستودعاً من التشغيل عالي التكرار عندما:

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

مثال. يحتوي مستودع analytics-demo على ما يقارب 114 جيجابايت من جداول Postgres المشتقة التي يمكن إعادة بنائها بالكامل من ملفات تفريغ CSV الخام المخزنة بالفعل داخل نفس الوحدة. عند حد رفع 6 ميجابايت/ثانية، تستغرق نسخة احتياطية ساخنة واحدة لهذا المستودع أكثر من 5 ساعات. التشغيل كل ساعة يعني أن كل تشغيل لا يزال جارياً عند انطلاق التالي، مما يتسبب في إسقاط كل تشغيل لاحق بصمت (راجع النسخ الاحتياطية طويلة الأمد وتداخل الجداول). استبعاده من hourly-hot وإبقاؤه في weekly-cold يعني نسخه احتياطياً مرة أسبوعياً بدلاً من أن لا يُنسخ أبداً.

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

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

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

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

ادفع الاستراتيجيات المرتبطة إلى جهاز كمؤقتات 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 مطلوبة للاستعادة