أتمتة النسخ الاحتياطي المُشفَّر للخادم باستخدام مهمة cron

آخر تحديث: 2026-09-01

النسخ الاحتياطي الذي عليك أن تتذكر تشغيله لا يحدث. أما cron فيتذكر، وواجهة Relayium CLI مبنية لذلك: أمر واحد غير تفاعلي ينسخ (أو يعكس) مجلدًا إلى جهاز آخر ويتحقق من كل ملف يَنقله.

يغطي هذا الدليل جدولة relayium push وrelayium sync التزايدي عبر cron، ووسيلتَي النقل اللتين يمكن توجيه أيٍّ منهما إليهما، وأسطر crontab الجاهزة للنسخ.

push مقابل sync: نسخة كاملة أم مرآة تزايدية

كلٌّ من push وsync ينقل مجلدًا إلى جهاز آخر، وكلاهما آمن للتشغيل المتكرر، لكنهما يحلّان مشكلتَي نسخ احتياطي مختلفتَين قليلًا.

يرسل push نسخة عبر SSH أو daemon-direct في كل مرة تُشغّله — بسيط، بل ويعمل حتى مع خادم مجرّد لا يوجد عليه relayium عبر بديل tar. أما sync فيُبقي الوجهة كمرآة تزايدية أحادية الاتجاه للمصدر: تُعاد فقط الملفات المتغيرة، فتصبح مزامنة ليلية لمجلد كبير سريعة بعد التشغيل الأول. يحتاج sync دائمًا إلى بروتوكول relayium الأصلي على الطرفين — ولا يوجد لديه بديل tar.

استخدم push لنسخة مجدولة مباشرة، خاصةً إلى خادم قد لا يكون relayium مثبتًا عليه.
استخدم sync لمجلد كبير أو كثير التغير حيث تكون إعادة إرسال كل شيء كل ليلة إهدارًا.
كلاهما يتحقق مما يَنقله بـ SHA-256 لكل ملف على البروتوكول الأصلي. ولا يستأنف push ولا pull؛ ومن الثلاثة، sync وحده يُكمل ملفًا جزئيًا، أما تراجع tar فلا يتحقق ولا يستأنف شيئًا.

قبل أن تبدأ

كل ما يلي هو relayium CLI، فثبّته أولًا إن لم تكن قد فعلت. على macOS وLinux، يُسقط أمر واحد ملفًا ثنائيًا مُسبق البناء في PATH الخاص بك:

curl -fsSL https://relayium.com/install.sh | sh

تفضّل اختيار الملف بنفسك، أو تعمل على Windows؟ احصل على ملف ثنائي من صفحة الإصدارات — يسرد relayium.com/cli كل خيارات التثبيت (أو go build -o relayium ./cmd/relayium إن كان لديك Go).
يؤكّد relayium --version أنه مثبَّت. تخطَّ هذا وستطبع الأوامر أدناه ‘command not found’ لا غير.

وسيلتا نقل: SSH أو daemon-direct

وجِّه أيًّا من الأمرين إلى وجهة SSH (بأسلوب scp، باستخدام ~/.ssh/config لديك)، أو إذا كان الجهاز الآخر يشغّل relayium serve، فمباشرةً إليه عبر بروتوكول daemon-direct — دون حاجة إلى SSH.

# وجهة SSH — تستخدم مفاتيح SSH وإعداداتك الحالية
relayium push ./data user@backup-server:/srv/backups/

# daemon-direct — الوجهة تشغّل "relayium serve"، ولا حاجة إلى SSH
relayium push ./data relayium://backup-server:9031

اتصالات daemon-direct مثبَّتة على TLS 1.3 مع الثقة عند الاستخدام الأول، ثم تُثبَّت على تلك البصمة في كل تشغيل لاحق.
يقبل sync الشكلين نفسيهما للوجهة كما يقبلهما push.

جدولته باستخدام cron

ما تحتاجه قبل الخطوة 1

الـ CLI على هذا الجهاز، وعلى الوجهة أيضًا إن كنت تنوي استخدام sync. فـ sync بلا بديل احتياطي عبر tar.
مفتاح SSH بلا عبارة مرور، أو وجهة تشغّل relayium serve. فـ cron بلا وكيل وبلا طرفية، ولا يستطيع الإجابة عن طلب عبارة المرور.
دليل مصدر موجود فعلًا في اللحظة التي ينطلق فيها cron — لا دليل على مشاركة شبكية لا تُركَّب إلا وأنت مسجَّل الدخول.
مكان تكتب فيه سجلًا. فمهمة cron التي تذهب مخرجاتها إلى العدم هي نسخة احتياطية لن تعرف حالها إلا يوم تحتاجها.

كلٌّ من push وsync أمر واحد غير تفاعلي، فيندرج مباشرةً في crontab. وجِّهه إلى مفتاح SSH بلا عبارة مرور (أو إلى وكيل)، وسجِّل المُخرجات لتظهر حالات الفشل:

# نسخة كاملة كل ليلة عند الساعة 2 — أضِفها إلى crontab لديك (crontab -e)
0 2 * * * relayium push -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/$(date +\%F)/ >> ~/relayium-backup.log 2>&1

# مرآة تزايدية كل 15 دقيقة بدلًا من ذلك
*/15 * * * * relayium sync -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/ >> ~/relayium-sync.log 2>&1

اعرف أين يوجد relayium فعلًا. فـ cron لا يستخدم PATH الخاص بصدفتك، وinstall.sh يتراجع إلى ‎~/.local/bin‎ حين يتعذّر الكتابة في ‎/usr/local/bin‎ — وهو بالضبط الموضع الذي لا يراه cron أبدًا.
```
command -v relayium
```
تأكّد أن المفتاح يعمل ولا أحد أمام لوحة المفاتيح. فـ BatchMode=yes يفشل بدل أن يسأل، وهذا هو حال cron تمامًا.
```
ssh -i ~/.ssh/backup_key -o BatchMode=yes user@backup-server true
```
شغّل الأمر كاملًا يدويًا مرة واحدة، مكتوبًا تمامًا كما سيشغّله cron، بما في ذلك المسار المطلق.
```
/usr/local/bin/relayium push -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/
```
عندها فقط أضف الجدولة. أبقِ المسار المطلق وإعادة التوجيه كما هما.
```
crontab -e
```
بعد أول تشغيل مجدول، اقرأ السجل بدل أن تفترض. هذه هي الخطوة التي يتخطّاها الناس، وهي نفسها التي كانت ستخبرهم.
```
tail -n 20 ~/relayium-backup.log
```

كيف يبدو إعداد يعمل بشكل صحيح

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

$ command -v relayium
/usr/local/bin/relayium
$ ssh -i ~/.ssh/backup_key -o BatchMode=yes user@backup-server true
$ echo $?
0

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

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

افتراضيًا، لا يفعل sync سوى إضافة الملفات أو تحديثها في الوجهة. أضف --delete لجعله مرآة حقيقية تزيل أيضًا الملفات التي لم تعد موجودة في المصدر — يجب أن يكون الطرف المستقبِل مُنصِتًا صراحةً بـ serve --allow-delete، وإلا تُتجاهَل عمليات الحذف بصمت ويُبلَّغ عنها بأنها مرفوضة. كما يرفض sync استخدام --delete تمامًا إذا لم يُحلَّل مجلد المصدر إلى أي ملف، فلا يمكن لخطأ مطبعي في مسار المصدر أن يمحو الوجهة.

إذا كنت تفضّل ألا تنتظر الدورة التالية لـ cron، يُبقي --watch عمل relayium sync مستمرًا ويعيد المزامنة تلقائيًا بعد لحظة من تغيّر أي ملف تحت المصدر — بديل خفيف عن الاستطلاع وفق جدول زمني.

relayium sync ./data user@backup-server:/srv/backups/ --delete يعكس عمليات الحذف (يحتاج المستقبِل إلى serve --allow-delete).
relayium sync ./data user@backup-server:/srv/backups/ --watch يبقى مستمرًا ويعيد المزامنة عند التغيّر بدلًا من التشغيل مرة واحدة من cron.

حين لا ينجح الأمر

كل حالة من هذه غير مرئية حتى تنظر في السجل — ولهذا كُتبت إعادة التوجيه ضمن سطر crontab لا كخيار إضافي. والحالة الخامسة أسوأ من كونها غير مرئية: فهي تبدو كالنجاح.

العَرَض، الفحص، الإصلاح

يقول السجل relayium: command not found بينما الأمر نفسه يعمل في صدفتك.

tail -n 5 ~/relayium-backup.log
# /bin/sh: relayium: command not found

يعمل cron بمسار PATH أدنى، غالبًا ‎/usr/bin:/bin‎ فقط. وإن لم يتمكّن install.sh من الكتابة في ‎/usr/local/bin‎ فقد وضع الثنائي في ‎~/.local/bin‎، وهو موضع لن يبحث فيه cron قط. ضع المسار المطلق الذي يعطيه command -v في سطر crontab، أو أضف سطر ‎PATH=‎ في أعلى crontab.

يُظهر السجل رفض اتصال ssh، أو لا شيء بعد التشغيل الأول.

ssh -i ~/.ssh/backup_key -o BatchMode=yes user@backup-server true
# Permission denied (publickey).

لا يملك cron وكيل ssh ولا طرفية، فالمفتاح المحمي بعبارة مرور لا يسعه إلا أن يتعلّق أو يفشل. وجّه ‎-i‎ إلى مفتاح بلا عبارة مرور مخصَّص للنسخ الاحتياطي، وتحقّق بـ BatchMode=yes الذي يرفض السؤال بدل انتظار شخص غير موجود.

يعمل sync بنظافة، لكن الملفات المحذوفة من المصدر ما تزال في الوجهة.

grep -i deni ~/relayium-sync.log

الحذف اختيار يفعّله الطرف المستقبِل. وبلا serve --allow-delete في الجهة المقابلة تُتخطّى عمليات الحذف ويُبلَّغ عنها بأنها مرفوضة، ولهذا يوجد الجواب في السجل لا في رمز الخروج. أعد تشغيل مُنصِت الطرف المقابل مع ‎--allow-delete‎.

يرفض sync الخيار ‎--delete‎ رفضًا قاطعًا.

relayium sync ~/documents user@backup-server:/srv/backups/ --delete
# refusing --delete with an empty source: this would delete everything on the destination. Check the path(s).

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

تعمل النسخة الاحتياطية وتنتهي بالرمز 0، لكنها ليست ما تظنه.

ssh user@backup-server command -v relayium

حين لا يملك الجهاز البعيد relayium يتراجع push إلى تدفّق tar عادي عبر SSH. تصل الملفات فلا يشتكي شيء — لكن هذا المسار بلا تحقّق SHA-256 لكل ملف وبلا فحص تعارض مسبق، وهما بالضبط السببان اللذان من أجلهما تجدول هذا بدل scp. ثبّت الـ CLI على الوجهة لتستعيدهما. أما sync فلا يعرف هذا الإخفاق: إذ لا بديل احتياطي لديه أصلًا، فيفشل بصوت عالٍ بدلًا من ذلك.

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

هل يحتاج خادم النسخ الاحتياطي إلى تثبيت relayium؟

يعتمد على الأمر. يعمل push في كلتا الحالتين: مع تثبيت relayium يستخدم البروتوكول الأصلي (فحص التعارض المسبق + SHA-256 لكل ملف)؛ ومن دونه، يتراجع push إلى تدفق tar عادي عبر SSH، فيعمل حتى الخادم المجرّد. أما sync فيحتاج دائمًا إلى بروتوكول relayium الأصلي على الطرف البعيد — لا يوجد بديل tar لـ sync، فثبِّته هناك أولًا.

هل النسخة الاحتياطية مُشفَّرة ومُتحقَّق منها؟

نعم. يُفحَص كل ملف بتجزئة SHA-256 من الطرف إلى الطرف، والدفع عبر SSH أو daemon-direct يعني أن البايتات محمية أصلًا بتشفير ذلك الاتصال — لا شيء إضافي لضبطه.

ماذا يحدث إذا قوطعت مهمة cron في منتصفها؟

يعتمد على الأمر الذي جدولته. sync يُكمل: التشغيل التالي يتخطى ما يطابق سلفًا ويُكمل ملفًا جزئيًا، و‏--no-resume يوقف ذلك. أما push فلا يستأنف في أي من البروتوكولين — فهو يرفض وجهة موجودة سلفًا، ولهذا يكتب سطر push أعلاه في مجلد مؤرَّخ، كي تكون الليلة التالية نسخة كاملة نظيفة بدل الرفض. و‏--no-resume مقبول في push ولا يفعل شيئًا.

هل يمكن أن يمحو --delete وجهتي بالخطأ؟

يرفض sync التشغيل مع --delete إذا لم يحتوِ مجلد المصدر على أي ملف، ويجب تشغيل المستقبِل بـ serve --allow-delete حتى تسري عمليات الحذف أصلًا — وإلا تُتجاهَل ويُبلَّغ عنها إليك.

هل أحتاج إلى حساب، وهل يكلّف هذا شيئًا؟

لا. واجهة CLI مجانية ولا تحتاج إلى حساب لـ push أو pull أو sync — يجري النقل عبر اتصال SSH لديك أو اتصال daemon مباشر، لا عبر خوادم Relayium.

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

احصل على CLI