‏Relayium مقابل rsync: زامِن المجلدات دون إعداد SSH

مواطن قوّة rsync

إن rsync ثنائي الاتجاه — أيّ جانب يمكن أن يكون المصدر — وتقارن خوارزمية النقل بالدلتا فيه كتل الملف بمجموع تحقّق متدحرج، فتعديل صغير على ملف ضخم يرسل الكتل المتغيّرة فقط، لا الملف كله من جديد. وذلك، إضافةً إلى عقود من الأعلام (‎--exclude‎ و‎--link-dest‎ للقطات الروابط الصلبة، والضغط، وحدود عرض النطاق، وأكثر)، يجعله الأداة المناسبة لكثير من المهام.

وهو أيضًا في كل مكان: تأتي به معظم أنظمة Linux وmacOS، ويعمل فوق اتصال SSH ربما أعددته أصلًا. لا شيء من ذلك يحاول Relayium sync استبداله.

قبل أن تبدأ

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

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

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

ما يفعله Relayium sync بدلًا من ذلك

إن ‎relayium sync <src...> <dest> [--delete] [--watch]‎ مرآة تزايدية أحادية الاتجاه: يقارن حجم كل ملف ووقت تعديله، ويتخطّى ما يطابق أصلًا، ويرسل الباقي.

يعمل عبر daemon direct. وجّهه إلى ‎relayium://host[:port]‎ فيتخطّى SSH كليًا: اتصال TLS 1.3 مثبَّت مباشرة إلى مستمع relayium serve على الجهاز الآخر، مُصادَق عليه ببصمة ذلك الجهاز (يُوافَق عليها مرة، وتُذكَر بعد ذلك). لا sshd لإعداده، ولا مفاتيح SSH لإدارتها — فقط جهازان عليهما relayium ومنفذ مفتوح بينهما. أما sync القديم عبر SSH إلى وجهة ‎user@host:/dest‎ فقد أُوقف، ويرفضه CLI الحالي برسالة «SSH transfers are currently disabled».

relayium serve --dir /backup/photos                   # على جهاز الاستقبال

relayium sync ./photos relayium://203.0.113.9:9031    # daemon direct، بلا SSH

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

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

لمجلد يتغيّر باستمرار، يبقي --watch على تشغيل sync بعد المرور الأول ويعيد العكس كلما تغيّر ملف تحت المصدر — لا يملك rsync شيئًا مدمجًا لهذا؛ إذ تلجأ عادةً إلى مهمة cron أو غلاف مثل lsyncd.

relayium serve --dir /backup --port 9031 --allow-delete

relayium sync ./photos relayium://203.0.113.9:9031 --delete --watch

السلامة والاستئناف وحدوده بصراحة

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

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

متى يبقى rsync الأداة الأفضل

اختر rsync حين تحتاج إلى مزامنة في الاتجاهين، أو حين يكون SSH مُعدًّا أصلًا ولا تريد daemon آخر، أو حين تحتاج إلى تحكّم دقيق (استثناءات، ومرشّحات، ولقطات روابط صلبة، وحدود عرض نطاق، وضغط)، أو حين يتغيّر ملف تغيّرًا طفيفًا ومتكررًا فيوفّر النقل بالدلتا عرض نطاق حقيقيًا. لا يحاول Relayium sync تغطية أيٍّ من ذلك.

• أحادي الاتجاه فقط: يعكس sync من المصدر ← الوجهة؛ أما rsync فيمكنه الذهاب في أيّ اتجاه.
• لا نقل بالدلتا: يعيد sync إرسال الملف المتغيّر كاملًا؛ أما مجموع التحقّق المتدحرج في rsync فيرسل الكتل المتغيّرة فقط.
• خيارات أقل: يملك rsync عقودًا من الأعلام للترشيح والضغط وأخذ اللقطات؛ أما sync فلديه ‎--delete‎ و‎--watch‎.
• أين يتفوّق Relayium sync: لا حاجة إلى خادم SSH (daemon direct)، وTLS مثبَّت بمصادقة بالبصمة، وإعادة مزامنة فورية بـ ‎--watch‎، والأوضاع المباشرة — sync وpush عبر daemon direct — مجانية بلا شيء يُقاس؛ وsync نفسه لا يحتاج حسابًا إطلاقًا.