مزامنة مجلد كبير بين خادمين (قابلة للاستئناف، في الخلفية)

آخر تحديث: 2026-07-08

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

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

لماذا يناسب relayium sync هذه المهمة

sync مرآة تزايدية أحادية الاتجاه عبر البروتوكول الأصلي (ثبّت relayium على الطرفين). ثلاث خصائص تجعله آمنًا للتشغيل وإعادة التشغيل دون إشراف:

يتخطى الملفات الموجودة سلفًا: الملف الذي تطابق نسخته لدى المُستقبِل في الحجم ووقت التعديل لا يُرسَل ثانيةً.
يستأنف الملفات الجزئية: إذا نُقِل نصف ملف عند انقطاع الاتصال، يُكمِل التشغيل التالي من إزاحة البايت الموجودة سلفًا على القرص بدل إعادته من البداية.
يتحقق من كل ملف: يُفحَص كل ملف بـ SHA-256 من الطرف إلى الطرف، فتُعرَف المرآة المكتملة أنها سليمة.
بسبب هذا، الأمر خامل التكرار (idempotent) — إعادة تشغيله تنجز ما تبقى فقط، وهذا بالضبط ما يتيح لحلقة إعادة المحاولة إتمام نقلٍ ضخم.

المتطلبات المسبقة

ثبّت relayium على كلا الخادمين (sync يتحدث البروتوكول الأصلي، فيجب أن يكون حاضرًا على كل طرف):

# على كلا الخادمين
curl -fsSL https://relayium.com/install.sh | sh

يستخدم هذا الدليل daemon direct (relayium://)، فلا يحتاج الخادمان إلى وصول SSH أحدهما للآخر.
افتح منفذ المُستمِع (9031 افتراضيًا) للمُرسِل على الجدار الناري أو مجموعة الأمان لدى المُستقبِل.

فوِّض المُرسِل مرةً واحدة (على المُستقبِل)

يعتمد المُستقبِل الجهاز المُرسِل مرةً واحدة؛ يُكتَب الاعتماد على القرص ويبقى صالحًا عبر إعادات التشغيل، فلا تكرره أبدًا. شغّل المُستمِع أولًا في طرفية في المقدمة، ووجِّه --dir إلى الدليل الأب — relayium sync /root/workspace يُعيد إنتاج workspace/... لدى المُستقبِل، فـ --dir /root يُنزِل الملفات في /root/workspace/.

عند أول اتصال للمُرسِل (القسم التالي)، يُظهِر serve عنوانه وبصمته ويطلب منك اعتماده؛ أجِب بـ y فيُحفَظ إلى الأبد:

# على المُستقبِل (في المقدمة، للاعتماد تفاعلياً)
relayium serve --dir /root --port 9031

# على المُستقبِل، عند أول اتصال:
Incoming push from 203.0.113.9:52140
  fingerprint: 9f2c41ab…
Accept and remember this peer? [y/N] y

لإعداد بلا إشراف تمامًا، تخطَّ المُطالبة: شغّل relayium id على المُرسِل لطباعة بصمته، ثم relayium authorize ‎<البصمة>‎ على المُستقبِل.
‏--dir هو أب المجلد الذي تزامنه، لا المجلد نفسه — وإلا نزلت الملفات مستوى أعمق مما ينبغي (مثلًا /root/workspace/workspace).

شغّل المُستمِع في الخلفية (على المُستقبِل)

بمجرد اعتماد البصمة، أوقِف serve الذي في المقدمة (Ctrl-C) وأعِد تشغيله منفصلًا كي يصمد بعد خروجك من الجلسة. يحمّل البصمة المحفوظة ويقبل المُرسِل بصمت — لا مُطالبة هذه المرة:

# على المُستقبِل
nohup relayium serve --dir /root --port 9031 > ~/relayium-serve.log 2>&1 &

يعالج serve الاتصالات واحدًا تلو الآخر ويبقى شغّالًا، فيكون جاهزًا لكل إعادة اتصال من حلقة إعادة المحاولة أدناه.
لصندوق وارد دائم التشغيل، شغّله تحت systemd بدلًا من ذلك (Restart=always، --config-dir /etc/relayium).

شغّل sync في حلقة إعادة محاولة تحت tmux (على المُرسِل)

تُقطَع عمليات النقل الطويلة — جلسة تسقط، شبكة متذبذبة، إعادة إقلاع. الحل ليس أداة متطورة؛ بل حلقة تعيد تشغيل sync حتى ينجح، مع مُعدِّد طرفيات كي يصمد بعد خروجك. هنا tmux أنظف من nohup: لا إعادة توجيه مخرجات يمكن أن تُخطئ فيها، ويمكنك إعادة الوصل لمتابعة التقدم.

ابدأ جلسة tmux، ثم شغّل المرآة في حلقة until — تعيد المحاولة كل 10 ثوانٍ حتى يُرجِع sync نجاحًا، ثم تخرج من تلقاء نفسها:

# على المُرسِل
tmux new -s xfer      # نفّذ apt install -y tmux إن لم يكن موجوداً

until relayium sync /root/workspace relayium://203.0.113.43:9031; do echo "$(date) retrying"; sleep 10; done

افصِل بـ Ctrl-b ثم d؛ تظل الحلقة شغّالة بعد إغلاقك الطرفية. أعِد الوصل بـ tmux attach -t xfer.
كل إعادة محاولة تنجز أقل: تُتخطى الملفات المنقولة سلفًا، ويُستأنف الملف المُرسَل نصفه — فتتقارب الحلقة وتنتهي.
يطبع التقدم سطرًا واحدًا لكل ملف مكتمل، فينتقل الملف الكبير بهدوء حتى يكتمل. الصمت ليس تعطّلًا (انظر استكشاف الأخطاء).

التحقق والإنهاء

يكتمل النقل حين تنتهي حلقة until وتعود إلى مُطالبة صدفة عادية. تأكد من تطابق الطرفين، ثم أوقِف المُستمِع:

# قارِن الإجماليات على كلا الخادمين
du -sh /root/workspace

# على المُستقبِل، بعد التحقق
pkill -f 'relayium serve'

فُحِص كل ملف بـ SHA-256 عند وصوله، فتطابق الأحجام مع خروج نظيف يعني نسخةً سليمة.

استكشاف الأخطاء وإصلاحها

بضعة أمور تبدو كمشكلات لكنها غالبًا ليست كذلك — والأمر الذي يكون عادةً مشكلة فعلًا (منفذ محجوب).

غياب المخرجات ليس تعطّلًا. لا يُطبَع التقدم إلا حين يكتمل كل ملف، فينتقل الملف الكبير بصمت. تحقق من الحالة الحقيقية على المُرسِل بـ ss -tnp | grep 9031 — ESTAB تعني متصلًا وينقل؛ SYN-SENT تعني أنه لا يستطيع بلوغ المُستمِع.
‏SYN-SENT تعني أن المنفذ محجوب. افتح 9031/TCP للمُرسِل على المُستقبِل (مجموعة أمان سحابية، أو ufw allow 9031/tcp). هذا أشيع سبب لنقلٍ لا يبدأ أبدًا.
فضِّل tmux مع حلقة من سطر واحد على nohup متعدد الأسطر. لصق أمر متعدد الأسطر فيه علامات اقتباس وإعادة توجيه > في صدفة كثيرًا ما ينكسر عند إعادة التوجيه أو يتركك عند مُطالبة استمرار >.
عند تنظيف العمليات، طابِق بدقة (pkill -f 'relayium sync')، لا pkill relayium — فالمطابقة الواسعة قد تقتل عملية relayium غير ذات صلة تعمل على الجهاز نفسه.
لا يوجد خيار استبعاد، فحدِّد مصادرك بدلًا من ذلك. لا يقبل sync سوى ‎-i و ‎-p (هوية SSH والمنفذ) و --delete و --watch و --config-dir — ولا شيء فيها يُرشِّح مسارًا في وسط الشجرة. ولترك دليل قابل لإعادة التوليد مثل بيئة Python الافتراضية، زامِن الأدلة الفرعية التي تريدها فعلًا: يقبل sync عدة مصادر دفعةً واحدة، ويصل كل مصدر تحت ‎--dir لدى المُستقبِل باسمه هو. فتشغيل relayium sync /root/workspace/src /root/workspace/data relayium://203.0.113.43:9031 مقابل serve --dir /root/workspace يعيد بناءهما في /root/workspace/src و /root/workspace/data، ولا يُمَرّ على venv أصلًا.
تُتخطى الروابط الرمزية والملفات الخاصة — ينقل sync الملفات العادية فقط. عالِج أي روابط رمزية مهمة على حدة.

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

ماذا يحدث إذا انقطع النقل في منتصف الطريق؟

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

بماذا يختلف هذا عن rsync؟

كلاهما يقوم بمرآة تزايدية أحادية الاتجاه، لكن relayium sync يعمل عبر اتصال TLS مُثبَّت دون الحاجة إلى حساب SSH (daemon direct)، ويصادق الجهازين ببصمة الشهادة، ويتحقق من كل ملف بـ SHA-256. إنه محرك النقل نفسه المُستخدَم في أوضاع relayium الأخرى.

هل يحذف sync لدى المُستقبِل الملفات التي أزلتها من المصدر؟

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

هل يمكنني إبقاء مجلدين متزامنين باستمرار؟

نعم. أضِف --watch فيبقى sync شغّالًا، مُعيدًا عكس الصورة عند أي تغيير تحت المصدر. لنقل مجلد كبير لمرة واحدة لا تحتاجه — تكفي حلقة إعادة المحاولة مع sync بسيط.

هل عليّ فتح منفذ؟

لـ daemon direct، نعم — يجب أن يكون منفذ المُستمِع (9031 افتراضيًا) قابلًا للوصول من المُرسِل. إن كنت تفضّل عدم فتح منفذ ولديك SSH بين الخادمين سلفًا، فإن sync يعمل أيضًا عبر SSH: relayium sync /path user@host:/path (يجب تثبيت relayium على الطرف البعيد).

انسخ صورة مجلد بين خادمين من خوادمك — تزايديًا، قابلًا للاستئناف، دون ملازمة.

احصل على CLI