rsync مقابل scp: أي أمر نسخ تستخدم في لينكس

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

ما الفرق بين rsync وscp؟

يفعل scp شيئًا واحدًا: يفتح قناة SSH، يبثّ البايتات، يغلق. لا حالة عنده بين الجلسات، فإذا مات النقل عند 90% بدأت من الصفر.

أما rsync فهو أداة مزامنة تستخدم SSH وسيلة نقل صدفة. قبل الإرسال يبني قائمة بصمات للملف الوجهة (خوارزمية الفروق ذات البصمة المتدحرجة) وينقل الكتل المختلفة وحدها. شغّل الأمر نفسه مرتين فتحمل المرور الثاني ما لا يكاد يذكر. وهذا يجعل rsync الأداة الطبيعية لإبقاء مجلدين متزامنين — جدوِله وتنقل كل جلسة الفروق فقط.

النتائج العملية:

• الانقطاعات: rsync يستأنف؛ scp يعيد الملف من البداية.
• النسخ المتكررة: rsync يرسل التغييرات فقط؛ scp يعيد إرسال كل شيء.
• الحذف: rsync يستطيع مرآة الحذف بـ --delete؛ scp لا.
• الترشيح: rsync لديه أنماط --exclude؛ scp ينسخ كل ما تشير إليه.
• التجربة الجافة: rsync يعرض ما سيفعله بـ --dry-run؛ scp لا يعرض شيئًا.

هل rsync أسرع من scp؟

في النسخة الأولى لملف كبير عبر وصلة سريعة، متقاربان — كلاهما يشبع SSH، ومرور البصمات يضيف حِملًا يسيرًا فقط. أما الفجوة فتنفتح في ثلاثة مواضع:

1. الملفات الصغيرة بالجملة. يمرّر rsync جولات المجلدات في خط أنابيب ويمكنه إعادة استخدام اتصال واحد؛ إعدادات scp القديمة كانت تنشئ عملًا لكل ملف. آلاف الملفات الصغيرة (a node_modules، تثبيت ووردبريس) تكتمل بوضوح أسرع مع rsync.
2. الإعادات. انسخ ملفًا بحجم 4 جيجابايت تغيّر منه 50 ميغابايت فيتحرك مع rsync نحو 50 ميغابايت؛ ويعيد scp نقل 4 جيجابايت كاملة.
3. الضغط. -z يضغط أثناء الطيران، وهذا ينفع على وصلات WAN البطيئة.

وقّت الاثنين بنفسك — الأمر مطابق في شكله:

# نفس الملف، نفس الخادم، كلاهما عبر SSH
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

# أعد تشغيل الاثنين: scp يعيد النسخ، rsync يتحقق ويرسل ما لا يُذكر
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

إذا قضيت يومك بين الخوادم، فسرعة النقل من الأمور التي تستحق قياسًا واحدًا — على طريقة تفوق ss على netstat في الأجهزة المشغولة (انظر ss مقابل netstat).

هل يستأنف scp النقل المقطوع؟

لا. لا استئناف عند scp؛ إذا قطع الاتصال عند 900 من أصل 1000 ميغابايت، تبدأ من جديد. هذا هو السبب الأكثر اقتباسًا في كل نقاش rsync-مقابل-scp، وهو حقيقي.

تصميم rsync كله يفترض أن النقل سينقطع أحيانًا. التعويذة القياسية للاستئناف:

rsync -avh --partial --append-verify --progress bigfile.tar.gz user@server:/srv/backup/

• --partial يحفظ الملف نصف المكتوب بدل حذفه.
• --append-verify يستأنف بالإلحاق ثم يتحقق بصميًا من المنطقة الملحقة — آمن من ملف جزئي فاسد، على خلاف --append المجردة القديمة.
• --progress يريك من أين أمسك الخيط.

وملفوفًا في حلقة إعادة محاولة، يصبح نسخًا احتياطيًا اضبطه وانمَ عنه حتى عبر وصلة عدائية:

until rsync -avh --partial --append-verify --progress 
    ./bigfile.tar.gz user@server:/srv/backup/; do
  sleep 5
done

متى تستخدم scp بدل rsync؟

يبقى scp الأداة الصحيحة في حفنة حالات:

• ملف صغير واحد، مرة واحدة. كتابة scp app.conf user@host:/etc/myapp/ أقصر من أي استدعاء rsync، ولا يوجد شيء لاستئنافه.
• rsync غائب في الطرف الآخر. يحتاج rsync ثنائيه في الجهتين. كثير من الحاويات والأجهزة المدمجة تشحن خادم SFTP الخاص بـ scp بلا rsync.
• لا تريد خادم rsync مكشوفًا. نادر، لكن بعض البيئات تشدّ الإغلاق تحديدًا على عفريت rsync.

دقة تستحق المعرفة: مشروع OpenSSH أهمل بروتوكول scp الأصلي منذ سنوات، وscp الحديث يتحدث فعليًا بـ SFTP في الطبقة السفلية. هذا أصلح خدعة هروب المسارات، لكنه لم يغيّر شيئًا في القيدين المهمين هنا — لا استئناف ولا نقل فروق. تغيير البروتوكول لا يجعل scp نسخة من rsync.

ومن الباب نفسه: إذا كان سؤالك في الحقيقة “rsync مقابل cp” فالجواب يردد هذا — cp هو مكافئ scp المحلي (لا استئناف ولا فروق ولا خصائص إلا بخيارات إضافية)، وrsync يعمل محليًا وبعيدًا. وللنسخ المحلية العابرة، cp يكفي.

أي خيارات rsync أهم؟

معظم الناس لا يحتاجون أبدًا إلا سطرًا واحدًا:

rsync -avh --partial --progress src/ user@server:/srv/dest/

الخيار	ماذا يفعل
-a (أرشيف)	تكراري + يحفظ الأذونات والأزمنة والمجموعة والروابط الرمزية والأجهزة
-v (مطوّل)	يسرد ما ينقل
-h (بشري)	أحجام مقروءة للإنسان
--partial	يحفظ الملفات المنقولة جزئيًا فتستأنف الإعادة
--progress	تقدم لكل ملف — الشيء الذي لم يعرفه scp قط
-z	ضغط أثناء الطيران (معالجات بطيئة على شبكة سريعة: تجاهله)
--delete	يطابق الحذف أيضًا — خطر، اربطه دائمًا بتجربة جافة
--dry-run (-n)	اعرض ما سيحدث، لا تغيّر شيئًا

عادتان تستحقان التبني. أولًا: جرّب جافًا أي أمر فيه --delete:

rsync -avh --delete --dry-run src/ user@server:/srv/dest/   # راجع
rsync -avh --delete src/ user@server:/srv/dest/             # ثم نفّذ

وثانيًا: انتبه للشرطة المائلة الختامية — /srv/src تنسخ المجلد نفسه إلى الوجهة، بينما /srv/src/ تنسخ محتوياته. هذا يعثر كل إنسان مرة واحدة؛ بل يحذرك rsync من “لا بايتات منقولة” حين كنت تقصد الصيغة الأخرى.

ولمزامنة يومية أو أسبوعية، أفلِت rsync في مؤقت systemd ودعه ينقل الفروق فقط — وجانب journalctl في الجدولة تغطيه ورقة أوامر journalctl.

rsync مقابل scp: الحكم

	scp	rsync
يأتي مع OpenSSH	نعم	نعم (الجهتان معًا)
استئناف نقل مقطوع	لا	نعم (--partial)
نقل الفروق في الإعادات	لا	نعم
حفظ الأذونات/الروابط الرمزية	جزئيًا	كاملًا (-a)
أنماط استثناء	لا	--exclude
تجربة جافة	لا	--dry-run
مرآة الحذف	لا	--delete
الأفضل لـ	نسخ عابرة سريعة	نسخ احتياطي، مزامنة، أشجار ضخمة

عُد إلى rsync افتراضيًا في النسخ الاحتياطي والأشجار الكبيرة وأي شيء عبر وصلة قابلة للقطع وأي شيء ستشغله أكثر من مرة. واستخدم scp حين يكون الأمر أقصر من الفكرة. وإذا أخذت خيارًا واحدًا من هذا المقال فخذ --partial — يحول كل قطع اتصال مستقبلي من إعادة تشغيل إلى توقف مؤقت.