انسخ الملفات احتياطيًا إلى خادمك عبر SSH باستخدام Relayium CLI

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

إذا كان لديك بالفعل وصول SSH إلى جهاز — خادم افتراضي خاص، أو خادم منزلي، أو NAS، أو محطة عمل — فيمكنك نسخ الملفات إليه احتياطيًا باستخدام Relayium CLI دون إعداد خدمة مزامنة أو حساب. تجري عملية النقل عبر اتصال SSH الموجود لديك، فتذهب البايتات مباشرة إلى خادمك ولا تمر أبدًا عبر Relayium.

يغطّي هذا الدليل دفع المجلدات وسحبها، وما يغطّيه التحقق من السلامة وما لا يغطّيه، ولماذا يرفض push العمل مرتين إلى الوجهة نفسها، وكيفية تشغيله وفق جدول باستخدام cron.

قبل أن تبدأ

كل ما يلي هو 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 الذي تستخدمه أصلًا. لا بد أن يعود ssh user@your-server true بصمت، فـpush يعيد استخدام هذا الاتصال نفسه ولا يهيّئ شيئًا خاصًا به.
وجهة قابلة للكتابة على الخادم. يجب أن يكون المجلد الأب لمسار الوجهة موجودًا وقابلًا للكتابة من قِبَل مستخدم SSH ذاك.
اختياريًا relayium على الخادم، فهو ما يمنحك فحص التعارض المسبق وتحقق SHA-256 لكل ملف. وبدونه يظل push يعمل عبر بث tar بسيط، لكنه لا يتحقق من شيء.
لا حساب على Relayium ولا خدمة تعمل في الخلفية على أي من الطرفين. لا شيء هنا يتحدث إلى خوادم Relayium.

يأخذ push مصدرًا واحدًا أو أكثر ووجهة بأسلوب scp. يتصل Relayium عبر SSH باستخدام مفاتيحك وإعداداتك المعتادة، ثم يبثّ الملفات إلى مجلد الوجهة:

تأكّد من وصول SSH الذي سيعيد push استخدامه. عودته بصمت تعني أن مفاتيحك واسم المضيف المستعار والمنفذ صحيحة أصلًا.
```
ssh user@your-server true
```
اعرف أي بروتوكول ستحصل عليه. ظهور مسار يعني البروتوكول الأصلي، أي فحص التعارض المسبق وتحقق SHA-256 لكل ملف؛ وغياب أي مخرجات يعني بث tar الذي لا يتحقق من شيء لكل ملف.
```
ssh user@your-server command -v relayium
```
ادفع المجلد. الوجهة مكتوبة بأسلوب scp، والشرطة المائلة في نهايتها تعني «إلى داخل هذا المجلد».
```
relayium push ./photos user@your-server:backups/
```
حدّد المفتاح أو المنفذ لهذا الأمر وحده إن كان إعداد ssh لديك لا يغطي هذا المضيف بعد.
```
relayium push -i ~/.ssh/id_ed25519 -p 2222 ./photos user@your-server:backups/
```
تأكّد مما وصل. يعيد push ./photos بناء المجلد photos تحت الوجهة، فيأتي اسم المجلد معه.
```
ssh user@your-server ls backups/photos
```

كيف يبدو التشغيل الناجح

على البروتوكول الأصلي، يطبع push سطرًا لكل ملف اكتمل وينتهي بالرمز 0. وأمام خادم عارٍ يطبع سطر ملخّص واحدًا فقط، وهذا هو مسار tar، وهو نجاح أيضًا.

relayium push ./photos user@your-server:backups/
  photos/IMG_0413.jpg (2314518 bytes)
  photos/IMG_0414.jpg (1998233 bytes)

# against a server with no relayium installed, one summary line instead:
sent 2 file(s) (zero-dependency mode)

يعيد استخدام ملف ~/.ssh/config لديك، فأسماء المضيفين المستعارة والمفاتيح والمنافذ التي أعددتها من قبل تعمل مباشرة.
إذا كان relayium مثبّتًا على الخادم، يستخدم البروتوكول الأصلي: تُفحَص الدفعة كلها بحثًا عن التعارضات قبل إرسال أي بايت، ويُتحقَّق من كل ملف يَنقله بـ SHA-256 ويوضع في منطقة مؤقتة قبل تثبيته.
إن لم يكن، يتراجع إلى تمرير بث tar عبر أنبوب إلى الطرف البعيد، فيعمل حتى خادم عارٍ لا يملك relayium.

اسحب الملفات مرة أخرى

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

relayium pull user@your-server:backups/ ./restore

على عكس push، يحتاج pull دائمًا إلى relayium مثبّتًا مسبقًا على الطرف البعيد — فهو لا يملك تراجع tar، لذا ثبّته هناك أولًا إن كان ناقصًا.

السلامة مدمجة — أما الاستئناف فلا

عندما يكون relayium على الطرفين، يُتحقَّق من كل ملف يَنقله push من الطرف إلى الطرف بتجزئة SHA-256 ويوضع في منطقة مؤقتة قبل تثبيته — فما يصل إلى الخادم مطابق بايتًا ببايت لما أرسلته. هذا القدر حقيقي، وهو سبب تثبيت relayium على الوجهة.

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

‏--no-resume مقبول في push وpull ولا يفعل شيئًا هناك. وهو حقيقي على مُستمِع serve يستقبل sync — فهذا هو المكان الوحيد الذي يمكن أن يوجد فيه ملف جزئي أصلًا.

لا يستأنف push ولا pull، في أي من البروتوكولين. استخدم sync لمجلد تتوقّع انقطاعه؛ أما تراجع tar فلا يستأنف ولا يتحقق من شيء لكل ملف.
يعمل تحقق SHA-256 تلقائيًا؛ ويُبلَّغ عن أي عدم تطابق ويُوسَم ذلك الملف بالفشل.

شغّله وفق جدول باستخدام cron

جدوِل sync لا push. يرفض push وجهة موجودة سلفًا، فالدفع الليلي إلى المجلد نفسه ينجح مرة واحدة ويُرفَض كل ليلة بعدها. أما sync فهو الوضع المبني للتشغيل المتكرر: يتخطى الملفات التي لم يتغيّر حجمها ولا وقت تعديلها، ويرسل ما تغيّر فقط، ويُكمل ملفًا جزئيًا خلّفه تشغيل منقطع. وهو أمر واحد غير تفاعلي يستخدم مفاتيح SSH لديك، فيندرج مباشرة في cron. وجّهه إلى مفتاح بلا عبارة مرور (أو إلى agent)، وسجّل المخرجات كي ترى حالات الفشل:

# انسخ احتياطيًا كل ليلة عند الساعة 2 — أضِف هذا إلى crontab لديك (crontab -e)
0 2 * * * relayium sync -i ~/.ssh/backup_key ~/documents user@your-server:backups/ >> ~/relayium-backup.log 2>&1

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

حين لا تصل النسخة الاحتياطية

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

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

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

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

الخيار BatchMode=yes يرفض السؤال ويفشل، فيحوّل التعليق الصامت إلى هذا السطر. أضِف الشقّ العام من ذلك المفتاح إلى ملف ~/.ssh/authorized_keys على الخادم، أو وجّه المهمة إلى مفتاح يحمله الوكيل أصلًا.

يعمل سطر crontab لكن السجل يبقى فارغًا.

command -v relayium
# /usr/local/bin/relayium

يعمل cron بمسار PATH مختصر لا يتضمن /usr/local/bin عادةً، فيفشل السطر قبل أن يبدأ relayium أصلًا. اكتب المسار المطلق الذي طبعه الفحص للتو داخل مُدخَل crontab، وأبقِ إعادة التوجيه >> ~/relayium-backup.log 2>&1 كي يظهر العطل التالي.

يبدأ sync الليلي المنقطع من الصفر في التشغيل التالي.

ssh user@your-server command -v relayium
# (لا يطبع شيئًا)

‏relayium غائب عن الطرف البعيد. لا يملك sync أي تراجع فلا يعمل أصلًا، ويهبط push إلى مسار بث tar الذي لا يتحقق من شيء ويعيد إرسال كل ملف كاملًا في كل مرة. ثبّته على الخادم. وحده sync يُكمل ملفًا جزئيًا في التشغيل التالي؛ فلا push ولا pull يستأنف في أي من البروتوكولين. وإن كنت تستخدم sync أصلًا، فتأكّد أيضًا من أنك لا تمرّر --no-resume الذي يعطّل ذلك الاستئناف على المُستمِع عمدًا.

تظهر «N file(s) failed integrity check» مع رمز خروج غير صفري.

relayium push ./photos user@your-server:backups/
# 1 file(s) failed integrity check: [photos/IMG_0413.jpg]
echo $?
# 1

قيمة SHA-256 المحسوبة عند الوصول لم تطابق المُرسَلة، والبروتوكول الأصلي يضع كل ملف في منطقة مؤقتة ولا يثبّته إلا عند تطابق البصمة — لذلك لم يُكتب ذلك المسار على الخادم أصلًا، ولا شيء هناك يحتاج إلى حذف. وإعادة تشغيل الدفعة كاملة سيظل فحص التعارض يرفضها، لأن بقية ملفات تلك الدفعة قد استقرت بالفعل، فأعد push لذلك المسار وحده. وإن فشل مجددًا فهو ليس خطأ نقل عابرًا: افحص الملف المصدر (هل يكتب فيه شيء أثناء قراءته) والتخزين على الطرفين.

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

هل تمر الملفات عبر خوادم Relayium؟

لا. يجري push وpull بالكامل عبر اتصال SSH لديك. خوادم Relayium لا تشارك أبدًا ولا تحتاج إلى حساب.

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

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

كيف يختار أي مفتاح SSH وأي منفذ يستخدم؟

يقرأ ملف ~/.ssh/config لديك كما يفعل ssh، فتُلتقط أسماء المضيفين المستعارة والمفاتيح والمنافذ تلقائيًا. يمكنك أيضًا تجاوزها لكل أمر بـ -i لملف الهوية و -p للمنفذ.

هل هذا أسرع من rsync؟

للدفع إلى خادمك الخاص فهو في المستوى نفسه تقريبًا لـ rsync عبر SSH؛ الهدف ليس التفوّق على rsync بل أن نمنحك أداة واحدة تنفّذ أيضًا عمليات النقل عبر الشبكات ومن خادم إلى خادم بنفس تحقق السلامة لكل ملف.

انسخ مجلدك التالي احتياطيًا بالطريقة المباشرة — عبر SSH لديك، مع تحقق من السلامة لكل ملف، ومجاني.

احصل على CLI