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

يأخذ Rediacc نسخة احتياطية من المستودعات المشفرة ويستعيدها على نفس الجهاز أو على جهاز مختلف. النسخ الاحتياطية مشفرة لأن المستودع نفسه مشفر: ما يغادر الجهاز هو النص المشفر، ويلزم بيانات اعتماد LUKS الخاصة بمستودعك للاستعادة.

هناك طريقتان للنسخ الاحتياطي، وتجيبان عن سؤالين مختلفين.

• اللقطات إلى التخزين المجزّأ (rdc backup snapshot) تحتفظ بتاريخ يمكنك العودة عبره. هذا هو المسار الرئيسي.
• نسخة على جهاز آخر (rdc repo push، rdc repo pull) تحتفظ بالمستودع كما هو الآن على عتاد تتحكم فيه. لا حساب سحابي مطلوب.

هما مستقلان. المستودع المنسوخ احتياطياً بإحدى الطريقتين ليس منسوخاً احتياطياً بالأخرى.

كيف تعمل اللقطات

تُقطَّع صورة المستودع إلى خلايا ثابتة الحجم على شبكة ثابتة. كل خلية إما ثقب، أي أنه لم يُكتب فيها شيء قط، أو تُخزَّن تحت مفتاح هو قيمة SHA-256 للنص المشفر لتلك الخلية.

من هذا القرار الواحد تنبع كل الخصائص.

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

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

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

كل لقطة تقف بمفردها. لا يوجد “نسخة احتياطية كاملة” يجب ألا تفقدها ولا نافذة تُبطل فيها زيادة معطوبة ما بعدها. أي لقطة في القائمة قابلة للاستعادة مباشرة.

التحقق هو إعادة تجزئة، لا ثقة. بما أن المفتاح هو تجزئة المحتوى، فإن فحص نسخة احتياطية يعني جلب الخلايا وتجزئتها. rdc backup verify يأخذ عينة؛ rdc backup verify --deep يعيد تجزئة كل خلية مسجَّلة.

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

ما الذي يكلفك

تُحتسب الحصة بـالبايتات الفعلية الفريدة المخزَّنة: ما هو محفوظ فعلياً بعد إزالة التكرار، لا مجموع ما تمثله لقطاتك منطقياً. ثلاثون لقطة لمستودع يتغيّر ببطء تكلّف تقريباً كلقطة واحدة. يُظهر rdc backup usage البايتات المخزَّنة مقابل حصتك، وهي رقم لكل اشتراك يبدأ من 10 GB في خطة Community.

ما تحتاجه اللقطات

يمرّ رفع اللقطة عبر خادم الحساب، الذي يخوّل كل تشغيل مقابل الترخيص المثبَّت للمستودع ويسلّم الجهاز صلاحية كتابة قصيرة الأجل. لذا يحتاج هذا المسار إلى خادم حساب يستطيع الجهاز الوصول إليه ومستودع مرخَّص. بدونهما تُرفض اللقطة بدلاً من أن تُتخطى بصمت، ولا يجد rdc backup manifests وrdc backup usage وrdc backup retention ما يقرؤونه.

هذا يشمل --dry-run. تُقرأ الترخيصة قبل أن يقرر التشغيل إن كان يخطط أم يرفع، لذا فإن التشغيل التجريبي معاينة للعمل، لا طريقة لتجربة الأمر بلا بيانات اعتماد.

الدفع والسحب من جهاز إلى جهاز لا يحتاجان إلى أي منهما. هما نقل مباشر بين جهازين موجودين بالفعل في إعداداتك.

ما لا تعِد به اللقطة

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

مسار تخزين rclone اختفى

كان rdc repo push --to <storage> وأقرباؤه يُستخدمون لنسخ ملف نسخة احتياطية كاملاً إلى مزود سحابي تُسجّله بنفسك. أصبحت هذه الآن ترفض وجهة تخزين وتسمّي بديلها. النقل من جهاز إلى جهاز لم يمرّ عبر rclone أصلاً ولم يتأثر. إذا كنت لا تزال بحاجة لقراءة أرشيف كُتب بتلك الطريقة، راجع قراءة أرشيف كُتب قبل الإيقاف.

أوامر التخزين المجزّأ

# رفع لقطة. التشغيل الأول يزرع البيانات، والتشغيلات اللاحقة ترسل فقط الخلايا المتغيّرة.
rdc backup snapshot my-app

# التخطيط دون رفع: يُظهر ما كان سيتحرك.
rdc backup snapshot my-app --dry-run

# إيقاف الحاويات، التجميد، إعادة التشغيل، ثم الرفع.
rdc backup snapshot my-app --cold

# عدم الوثوق بالمرساة المحلية وإعادة رفع المخزون كاملاً.
# هذا يعيد رفع كل شيء ويُعيد احتساب الحصة؛ استخدمه فقط عندما
# يكون من المؤكد أن المرساة تالفة.
rdc backup snapshot my-app --reseed

# التحقق من المخزون المحفوظ وحصتك.
rdc backup verify my-app
rdc backup manifests my-app
rdc backup usage

الخيار	الوصف
<repo-ref> (موضعي)	المستودع المراد أخذ لقطة له
--dry-run	تخطيط فقط: لا رفع. يُظهر ما كان سيتحرك
--cold	إيقاف الحاويات، التجميد، إعادة التشغيل، ثم الرفع. لا يُجمع مع --dry-run
--reseed	عدم الوثوق بالمرساة المحلية ورفع مخزون كامل. يعيد رفع كل شيء ويُعيد احتساب الحصة
--debug	تفعيل الإخراج التفصيلي

اللقطات الباردة (--cold)

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

# كل مستودع في مخزن البيانات الافتراضي.
sudo renet backup snapshot --cold

# المستودعات التي تحددها فقط. يأخذ --repo معرّف GUID لمستودع، ويمكن تكراره.
sudo renet backup snapshot --cold --repo <guid> --repo <guid>

لا يمكن الجمع بين --cold و--dry-run. التشغيل التجريبي الذي يوقف الحاويات ليس تجريبياً، والذي لا يوقفها ليس بارداً، لذلك يرفض renet هذا الاقتران بدلاً من أن يختار لك معنىً واحداً.

ماذا يفعل التشغيل البارد

لكل مستودع مختار، بهذا الترتيب:

1. إيقاف حاوياته.
2. كتابة نقطة تركيب المستودع ومخزن البيانات إلى القرص.
3. التأكد من أن الحاويات توقفت فعلاً.
4. أخذ نسخة reflink بأسلوب النسخ عند الكتابة من صورة المستودع.
5. تشغيل الحاويات من جديد.

عندها فقط يبدأ الرفع، وكل المستودعات تكون قد عادت للعمل بالفعل.

وقت التوقف هو التجميد وليس النقل. الـ reflink بيانات وصفية فقط، لذا يستغرق الوقت نفسه سواء احتوى المستودع على 1 GB أو 100 GB. الرفع ليس كذلك: فهو يكبر مع البايتات المتغيّرة، واللقطة الأولى ترفع المخزون غير الفارغ كاملاً. إبقاء الحاويات متوقفة حتى ينتهي الرفع كان سيربط وقت التوقف بحجم البيانات، وهذا في النسخة الأولى يعني ساعات بدل أجزاء من الثانية.

تُوقَف كل المستودعات المختارة داخل نافذة واحدة، لا واحداً تلو الآخر. يكلّف ذلك وقت توقف أطول قليلاً لكل مستودع، ويمنح في المقابل نقطة اتساق واحدة للمجموعة كلها.

المستودع الذي لا تعمل فيه أي حاوية هادئ أصلاً. تُؤخذ لقطته دون أي وقت توقف، وهذه نتيجة طبيعية وليست فشلاً.

كم يكلّف وقت التوقف

بالقياس على جهاز حقيقي، بلغ وقت التوقف الكلي 222 ms:

المرحلة	المقاس	ماذا يحدث
cold_down	64 ms	توقف الحاويات
cold_sync	26 ms	كتابة نقاط تركيب المستودعات ومخزن البيانات إلى القرص
cold_verify	31 ms	تأكيد أن الحاويات متوقفة
cold_stage	0 ms	نسخة reflink من صورة المستودع
cold_up	99 ms	تشغيل الحاويات من جديد

النصيب الأكبر لإعادة تشغيل الحاويات، أما التحضير فمجاني عملياً: الـ reflink لا يظهر أصلاً بدقة الميلي ثانية. لكن اقرأ هذا الصفر إلى جانب سجلات كل مستودع لا بمفرده. التشغيل الذي رفض كل المستودعات يبلّغ أيضاً cold_stage=0ms، والسجلات وحدها تقول أي الحالتين أمامك.

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

يطبع renet الأرقام نفسها في نهاية التشغيل، حتى تقيس أجهزتك بنفسك بدل أن تصدّق أرقامنا:

Cold backup: <n> repositories quiesced, outage 222ms (cold_down=64ms cold_sync=26ms cold_verify=31ms cold_stage=0ms cold_up=99ms)

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

متى تختار البارد

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

اختر البارد للبيانات التي لا يمكن التقاطها بأمان أثناء الكتابة عليها. قاعدة بيانات لها سجل كتابة مسبق وحالة في الذاكرة هي المثال الواضح. أنت تبادل وقت توقف قصيراً ومقاساً بلقطة يستطيع التطبيق فتحها دون أن يتعافى أولاً.

ماذا يرفض التشغيل البارد

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

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

إذا انقطع التشغيل والحاويات متوقفة، بسبب systemctl stop أو إعادة تشغيل، يعيد renet تشغيلها قبل أن يخرج. والتعافي على الجهاز شبكة أمان: يلاحظ نسخة باردة اختفى صاحبها ويعيد تلك المستودعات إلى العمل.

إرسال نسخة احتياطية إلى جهاز آخر

نسخ مستودع إلى جهاز ثانٍ عبر SSH:

rdc repo push my-app --to server-1

يُحلّ --to <machine> الوجهة من إعداداتك، ويقول --to-machine <machine> الشيء نفسه صراحة. اسم تخزين يُرفض: ذلك المسار مُتقاعد.

تُنسخ الصورة المشفرة بنفس الـ GUID، لذا هذه نسخة احتياطية أو ترحيل وليست تفريعاً. للحصول على نسخة مستقلة، شغّل rdc repo fork أولاً ثم أرسل التفريع.

يحمل الإرسال الأول الصورة كاملة. كل إرسال بعده يرسل فقط الكتل المتغيّرة مقابل صورة أساسية غير قابلة للتغيير محفوظة على كلا الجهازين، دون أعلام تضبطها. يسمّي --delta-base <guid> تلك الأساس بنفسك إن احتجت.

تحطّ النسخة المُرسَلة على الهدف كقطعة أثرية للنسخ الاحتياطي لا كمستودع يعمل. حوّلها إلى مستودع باستخدام rdc backup restore:

rdc backup restore my-app@server-1 --as my-app --machine server-1 --up

للنسخ الاحتياطي عند نقطة زمنية محددة، استخدم التخزين المجزّأ بدلاً من ذلك: rdc backup snapshot my-app يرفع فقط الخلايا التي تغيّرت، وrdc backup restore my-app --at <snapshot> يعيد أياً منها.

الخيار	الوصف
<ref> (موضعي)	مرجع المستودع المراد إرساله
--to <remote>	الجهاز أو العنقود الهدف
--to-machine <machine>	الجهاز الهدف، مذكور صراحة
--provision <provider>	توفير الجهاز الهدف عبر هذا مزود السحابة إذا لم يكن موجوداً
--checkpoint	إنشاء نقطة تحقق CRIU قبل الإرسال (للحاويات التي تحمل تسمية rediacc.checkpoint=true). الهدف يستعيد تلقائياً عند repo up
--force	استبدال نسخة احتياطية موجودة
--bwlimit <limit>	حد عرض النطاق الترددي لنقل rsync (مثال: 10M، 500K)
--delta-base <guid>	نقل الكتل المتغيّرة فقط مقارنةً بـ GUID أساسي غير قابل للتغيير. اتركه فارغاً للأساس التلقائي
--strategy <strategy>	استراتيجية دلتا الكتل عند استخدام أساس دلتا: auto أو physical أو shared
--debug	تفعيل الإخراج التفصيلي
--skip-router-restart	تخطي إعادة تشغيل خادم المسار بعد العملية

سحب نسخة احتياطية من جهاز آخر

إعادة مستودع من الجهاز الذي يحمله:

rdc repo pull my-app --from server-1

أضف --up لتحميله ونشره في الأمر نفسه. للاستعادة من التخزين المجزّأ بدلاً من ذلك، استخدم rdc backup restore my-app --at <snapshot-id>.

يرفض السحب استبدال مستودع مُحمَّل حالياً. أزل تحميله أولاً، ثم نفّذ السحب، ثم أعده للعمل عبر rdc repo up. المستودعات القائمة على مجلد استثناء: فهي تُزامَن في مكانها أثناء كونها محمّلة.

الخيار	الوصف
<ref> (موضعي)	مرجع المستودع المراد سحبه
--from <remote>	الجهاز أو العنقود المصدر
--from-machine <machine>	الجهاز المصدر، مذكور صراحة
--force	استبدال نسخة احتياطية محلية موجودة
--up	تحميل المستودع ونشره بعد السحب
--bwlimit <limit>	حد عرض النطاق الترددي لنقل rsync (مثال: 10M، 500K)
--delta-base <guid>	استقبال الكتل المتغيّرة فقط مقارنةً بـ GUID أساسي غير قابل للتغيير
--strategy <strategy>	استراتيجية دلتا الكتل عند استخدام أساس دلتا: auto أو physical أو shared
--debug	تفعيل الإخراج التفصيلي
--skip-router-restart	تخطي إعادة تشغيل خادم المسار بعد العملية

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

عرض اللقطات في التخزين المجزّأ:

rdc backup manifests my-app

كل صف نقطة زمنية محفوظة واحدة:

العمود	المعنى
Repo	اسم المستودع المُحلَّل من إعداداتك المحلية (يعود إلى GUID للمستودعات غير الموجودة في الإعدادات)
Snapshot	معرّف اللقطة. هذا ما يأخذه rdc backup restore --at
Created	وقت UTC الذي أُخذت فيه اللقطة
Total	حجم صورة المستودع التي تمثلها هذه اللقطة
Added	البايتات التي رفعتها هذه اللقطة فعلياً فوق ما سبقها
Chunks	عدد الخلايا التي أضافتها

لرؤية ما تركه rdc repo push --to <machine> على الوجهة، اسأل ذلك الجهاز عمّا يحمله:

rdc repo list --machine server-1

تظهر النسخة المُرسَلة تحت اسمها الخاص. صف ثانٍ يحمل GUID خاماً بجانبها هو أساس الدلتا المحتفَظ به، وهو ما يجعل الإرسال التالي إلى ذلك الجهاز تزايدياً بدلاً من نقل كامل.

يقرأ rdc backup list --machine <machine> مجلدي hot/ وcold/ اللذين تكتب فيهما التشغيلات المجدولة، لذا فهو الأداة الخاطئة لنسخة وضعها إرسال هناك، ولن يُظهر لك شيئاً.

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

عرض التخزين أُوقف مع مسار rclone؛ يرفض الأمر التنفيذ ويذكر هذين البديلين.

الاحتفاظ

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

# ما يُفرض حالياً.
rdc backup retention my-app

# الاحتفاظ بنافذة متجددة: 7 يومياً، 4 أسبوعياً، 6 شهرياً.
rdc backup retention set my-app --keep-daily 7 --keep-weekly 4 --keep-monthly 6

# العودة إلى الاحتفاظ بكل شيء.
rdc backup retention clear my-app

الخيار	الوصف
--keep-last <n>	الاحتفاظ بهذا العدد من أحدث اللقطات
--keep-hourly <n>	الاحتفاظ بأحدث لقطة من كل واحدة من هذه الساعات
--keep-daily <n>	الاحتفاظ بأحدث لقطة من كل واحد من هذه الأيام
--keep-weekly <n>	الاحتفاظ بأحدث لقطة من كل واحد من هذه الأسابيع
--keep-monthly <n>	الاحتفاظ بأحدث لقطة من كل واحد من هذه الأشهر
--keep-yearly <n>	الاحتفاظ بأحدث لقطة من كل واحدة من هذه السنوات

اعطِ قاعدة واحدة على الأقل. يُرفض set بلا قواعد بدلاً من أن يُعامَل كـ”لا تحتفظ بشيء”، لأن مسح السياسة هو ما وُجد له clear.

الاستعادة

يحوّل rdc backup restore نسخة احتياطية إلى مستودع حي، وهو نفس الأمر لكلا المسارين. ما يختلف هو ما توجّهه إليه.

# نقطة زمنية من التخزين المجزّأ.
rdc backup restore my-app --as my-app-yesterday --at <snapshot-id> --up

# قطعة أثرية تركها إرسال على جهاز.
rdc backup restore my-app@server-1 --as my-app --machine server-1 --up

يأخذ --at معرّف لقطة من rdc backup manifests، أو وقت RFC 3339 مثل 2026-08-14T12:00:00Z، والذي يُحلّ إلى أحدث لقطة أُخذت عند تلك اللحظة أو قبلها. يُرفض وقت ليس له لقطة عنده أو قبله بدلاً من تقريبه للأمام.

الاستعادة تحت اسم جديد باستخدام --as لا تستبدل شيئاً، لذا فإن تمرين الاستعادة آمن للتشغيل على جهاز حي. تُرفض الاستعادة تحت اسم موجود بالفعل.

الخيار	الوصف
<artifact-ref> (موضعي)	ما المراد استعادته. repo للقطة من التخزين المجزّأ، repo@place لقطعة أثرية على جهاز
--as <name>	اسم المستودع المُستعاد (افتراضياً اسم القطعة الأثرية)
-m, --machine <machine>	الجهاز المراد الاستعادة عليه
--datastore <name>	الاستعادة في مخزن البيانات المسمى هذا، الذي يستضيفه جهازه المرفق
--at <time>	استعادة نقطة زمنية: معرّف لقطة أو وقت RFC 3339
--up	نشر المستودع المُستعاد بعد النقل
--health-window <seconds>	مدة مراقبة صحة المستودع المنشور
--health-timeout <seconds>	مدة الانتظار حتى يصبح صحياً
-y, --yes	تخطي التأكيد
--debug	تفعيل الإخراج التفصيلي

تحتاج استعادة مستودع إلى بيانات اعتماد LUKS الخاصة به، وهي تعيش في إعداداتك. إذا كان تخزين الإعدادات مفعّلاً لديك، تعود تلك البيانات مع إعداداتك على جهاز جديد. إذا لم يكن كذلك، احتفظ بنسخة من الإعدادات في مكان لا يأخذه معه فشل الجهاز.

إثبات الاستعادة على كل جهاز

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

افعل هذا مرة واحدة لكل جهاز، قبل أن تعتمد على النسخ الاحتياطية:

1. خذ لقطة: rdc backup snapshot my-app.
2. تأكد من تسجيلها: rdc backup manifests my-app.
3. استعدها تحت اسم للاستخدام والتخلص: rdc backup restore my-app --as my-app-drill --at <snapshot-id>.
4. قارن المستودع المُستعاد بالمصدر، ثم احذف نسخة التمرين بـ rdc repo delete my-app-drill --yes.

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

مزامنة مستودع واحد في كل مرة

يعمل الدفع والسحب على مستودع واحد فقط، يُحدَّد عبر مرجع (name أو name:tag أو name@machine). لا توجد صيغة «جميع المستودعات دفعة واحدة»: شغّل الأمر مرة واحدة لكل مستودع.

مرجع يسمّي تفريعاً وجهازاً يعمل بنفس طريقة الاسم البسيط:

rdc repo push shop:nightly@server-1 --to server-2
rdc repo pull shop:nightly@server-1 --from server-2

قوائم الخيارات الكاملة موجودة تحت إرسال نسخة احتياطية إلى جهاز آخر وسحب نسخة احتياطية من جهاز آخر.

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

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

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

الوضع	السلوك	وقت التوقف
hot	صورة المستودع تُجمَّد أثناء استمرار الخدمات (متسقة عند التعطل)	لا يوجد
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 status <machine> --containers يُظهر حالة التشغيل. قارن مع المجموعة المتوقعة.
• /var/run/rediacc/cold-backup-<guid>.status.json على الجهاز. افحص عبر rdc term connect <repo> -c "cat /var/run/rediacc/cold-backup-$GUID.status.json". success: false مع startedAt قديم يعني أن آخر نسخة احتياطية لم تكتمل بنظافة.
• السجلات من تشغيل نسخ renet الاحتياطي (journalctl -u renet-* أو استدعاء rdc 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 ثانية

خطوة التجميد هي نسخة reflink بأسلوب النسخ عند الكتابة من صورة المستودع. إنها بيانات وصفية فقط، لذا تستغرق الوقت نفسه سواء احتوى المستودع على 1 GB أو 100 GB، وفي تشغيل مقاس لم تظهر أصلاً بدقة الميلي ثانية. لا يُبقى المستودع متوقفاً خلال تجميد المستودعات الأخرى. يعمل الرفع بعد ذلك ضد النسخة المجمَّدة بينما تكون جميع المستودعات قد عادت للعمل بالفعل.

الوقت الإجمالي (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 ثانية)، وليس بطول التشغيل كاملاً. تُجدول المستودعات في فتحات التزامن بترتيب اكتشافها؛ لا يوجد طابور أولوية. أعطِ المستودعات الثقيلة استراتيجيتها الخاصة المحدودة بـ --include إذا احتجت إلى جدولة أدق.

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

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

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

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

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

هذا السلوك الافتراضي مقصود. تشغيل نسختين احتياطيتين باردتين بالتوازي على نفس مخزن البيانات سيتنافس على مسار التجميد، وعلى الرفع، وعلى sidecars كل مستودع في /var/run/rediacc/cold-backup-<guid>.status.json. الانتظار خلف نسخة قيد التشغيل أفضل من إجهاد البيانات نفسها من اتجاهين. يفرض قفل مخزن البيانات ذلك: يجد تشغيل بارد ثانٍ القفل مشغولاً فيُرفض رأساً دون أن يوقف شيئاً.

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

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

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

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

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

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

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

rdc backup strategy set hourly-hot \
  --destination rediacc \
  --cron "0 * * * *" \
  --mode hot \
  --bwlimit 20M \
  --enable

rdc backup strategy set weekly-cold \
  --destination rediacc \
  --cron "15 3 * * 0" \
  --mode cold \
  --include shop --include mail \
  --enable

يسمّي --destination <name> الوجهة داخل الاستراتيجية؛ إنه تسمية تختارها أنت، وهو يصف التخزين المجزّأ. يسرد --include المستودعات المراد نسخها احتياطياً، وتكراره يضيف المزيد. حذفه يجعل الاستراتيجية تغطي كل مستودع على مخزن البيانات. تتطابق الأسماء مع اسم المستودع في الإعدادات المحلية (بدون :tag).

يُرفض --exclude عند وجهة تخزين مجزّأ بدلاً من أن يُتجاهل بصمت، لأن backup snapshot الأساسي يختار المستودعات بتسميتها وليس لديه استثناء خاص به. احترامه كان سيعني نسخ مستودعات طلبت استبعادها احتياطياً. اجعل نطاق الاستراتيجية بـ --include بدلاً من ذلك، حتى يُكتَب ما يغطيه تشغيل مجدول بدلاً من استنتاجه.

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

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

rdc backup strategy list
rdc backup strategy show weekly-cold

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

rdc backup strategy remove weekly-cold

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

استراتيجية غير مرتبطة بأي جهاز لا تُنشر أبداً. اربط واحدة أو أكثر بجهاز:

rdc backup strategy bind hourly-hot --machine hostinger
rdc backup strategy bind weekly-cold --machine hostinger
rdc backup strategy unbind weekly-cold --machine hostinger

يُسجَّل الربط في إعداداتك كقائمة على الجهاز، وهو ما يقرأه rdc backup schedule ليقرر أي وحدات ينشر:

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

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

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

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

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

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

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

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

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

الاستراتيجية بلا --include تغطي كل مستودع على مخزن البيانات. تكرار --include يضيّقها إلى المستودعات التي تسمّيها، مطابَقة مع اسم المستودع في الإعدادات المحلية (بدون :tag).

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

# الاستراتيجية الباردة: أسبوعياً، وفقط المستودعات التي تحتاج إلى تهدئة
rdc backup strategy set weekly-cold \
  --destination rediacc \
  --cron "15 3 * * 0" \
  --mode cold \
  --include shop --include mail \
  --enable

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

سمِّ المستودعات التي تريدها في التشغيل عالي التكرار، بدلاً من تركه يأخذ كل شيء، عندما:

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

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

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

المستودع الذي تغطيه كلتا الاستراتيجيتين يحصل على لقطات ساعية متسقة عند التعطل ولقطة أسبوعية متسقة على مستوى التطبيق. يعرضهما rdc backup manifests <repo> معاً، وتُخزَّن الخلايا المشتركة بينهما مرة واحدة.

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

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

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

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

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

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

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

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

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

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

rdc backup run -m server-1
rdc backup run weekly-cold -m server-1

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

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

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

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

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

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

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

rdc repo migrate my-app@server-1 --to server-2

الخيار	الوصف
<ref> (موضعي)	مرجع المستودع المراد ترحيله؛ الجزء @machine منه يحدد المصدر
--to <place>	الجهاز أو العنقود الهدف
--provision <provider>	توفير الجهاز الهدف تلقائياً عبر مزود السحابة هذا (مثال: hetzner، linode)
--checkpoint	إنشاء نقطة تحقق CRIU قبل الترحيل، حتى تنتقل ذاكرة العملية أيضاً
--delta-base <guid>	GUID أساسي غير قابل للتغيير لدلتا التحوّل. افتراضياً أساس المرحلة الأولى
--strategy <strategy>	استراتيجية دلتا الكتل للتحوّل: auto أو physical أو shared
--skip-dns	تخطي تحديث سجلات DNS بعد الترحيل
--keep-source	الاحتفاظ بصور المصدر بعد نجاح النقل
--bwlimit <limit>	حد عرض النطاق الترددي للنقل (مثال: 50M)

ينقل الترحيل بيانات المستودع المشفرة عبر rsync على مرحلتين: نقل كتلي بينما يستمر المستودع في العمل، ثم توقف قصير للدلتا. الترحيل ينقل المستودع، لذا تُحذف صور المصدر بمجرد نجاح النقل. مرّر --keep-source للاحتفاظ بها. هذا هو الفرق بين repo migrate وrepo push: يترك الدفع المصدر يعمل دون مساس.

قراءة أرشيف كُتب قبل الإيقاف

rdc storage هو ما تبقى من مسار rclone، وهو للقراءة فقط. لم يعد بإمكانه أن يكون وجهة نسخ احتياطي، لكنه لا يزال قادراً على الوصول إلى أرشيف كُتب على واحد منها.

# تسجيل remote سبق أن أعددته لـ rclone.
rdc storage import rclone.conf
rdc storage list

# النظر في محتواه. هذا يشغّل rclone الموجود على PATH لديك.
rdc storage browse my-storage

يقرأ import ملف إعداد rclone ويسجّل الـ remotes في إعداداتك؛ الأنواع المدعومة هي S3 وB2 وGoogle Drive وOneDrive وMega وDropbox وBox وAzure Blob وSwift.

يتطلب browse وجود rclone على PATH لديك. يشغّل rclone المثبَّت على الجهاز الذي تكتب عليه؛ لم تعد هناك نسخة مضمَّنة. بدونه يخبرك بذلك ولا يفعل شيئاً آخر.

الإرسال إلى تخزين، والسحب منه، وعرضه، واستعادته أُوقفت جميعاً؛ كل منها يرفض ويذكر الأمر الذي يحل محله.

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

• جدولة النسخ الاحتياطي البارد اليومي للحصول على نسخ متسقة على مستوى التطبيق للبيانات الحيوية
• استخدام النسخ الاحتياطي الساخن للتشغيلات عالية التكرار حيث لا يُقبل أي توقف
• اختبار الاستعادة بشكل دوري. rdc backup restore --as <new-name> لا يستبدل شيئاً، لذا فإن التمرين آمن على جهاز حي
• ضع سياسة احتفاظ بدلاً من التقليم اليدوي، حتى تكون النافذة التي تحتفظ بها مكتوبة
• احتفظ بنسخة من جهاز إلى جهاز إلى جانب اللقطات إذا أردت نسخة على عتاد تتحكم فيه
• الحفاظ على أمان بيانات الاعتماد؛ النسخ الاحتياطية مشفرة لكن بيانات اعتماد LUKS مطلوبة للاستعادة