rsync در مقابل scp: کدام دستور کپی در Linux را به‌کار ببریم

برای هر چیزی بزرگ‌تر از یک کپی یک‌باره سریع، rsync؛ وقتی همین الان فقط می‌خواهید یک فایل روی دستگاه دیگر باشد، scp. تفاوت اصلی: scp هر بار کل فایل را از نو استریم می‌کند و حافظه‌ای از قطع شدن اتصال ندارد، در حالی که rsync مبدا و مقصد را مقایسه می‌کند، فقط بلوک‌های تغییر‌یافته را منتقل می‌کند و کپی نیمه‌کاره را از همان‌جا که مانده ادامه می‌دهد. روی یک بکاپ بزرگ روی خطی ناپایدار، همین یعنی فاصله بین دو دقیقه و شروع از صفر. هر دو همراه OpenSSH روی تقریباً هر توزیع Linux می‌آیند، پس این یک انتخاب عادت است نه انتخاب نصب — و عادت باید پیش‌فرضش rsync باشد. در ادامه: جدول مقایسه بی‌تعارف، تفاوت سرعت واقعی، ترفند ادامه انتقال که scp از عهده‌اش برنمی‌آید، و مواردی که scp هنوز جواب درست است.

تفاوت rsync و scp چیست؟

scp یک کار می‌کند: کانال SSH باز می‌کند، بایت‌ها را می‌فرستد، می‌بندد. بین دو اجرا هیچ حافظه‌ای ندارد، پس اگر انتقال در 90 درصد بمیرد، از صفر شروع می‌کنید.

rsync یک ابزار همگام‌سازی است که اتفاقاً SSH را به‌عنوان transport به کار می‌برد. قبل از ارسال، فهرست checksum فایل مقصد را می‌سازد (الگوریتم دلتا با rolling-checksum) و فقط بلوک‌های متفاوت را می‌فرستد. همان دستور را دو بار اجرا کنید، بار دوم تقریباً هیچ‌چیز جابه‌جا نمی‌شود. همین rsync را به ابزار طبیعی هم‌سطح نگه داشتن دو پوشه تبدیل می‌کند — زمان‌بندیش کنید و هر اجرا فقط دلتاها را کپی می‌کند.

پیامدهای عملی:

• قطع شدن: rsync ادامه می‌دهد؛ scp فایل را از نو می‌فرستد.
• کپی دوباره: rsync فقط تغییرات را می‌فرستد؛ scp همه‌چیز را از نو.
• حذف‌ها: rsync حذف‌ها را هم با --delete آینه می‌کند؛ scp نمی‌تواند.
• فیلتر: rsync الگوهای --exclude دارد؛ scp هرچه را اشاره کنید کپی می‌کند.
• آزمایش بدون اجرا: rsync با --dry-run نشان می‌دهد چه خواهد کرد؛ scp هیچ معادلی ندارد.

آیا rsync سریع‌تر از scp است؟

برای کپی اولیه یک فایل بزرگ روی لینک سریع، نزدیک هم‌اند — هر دو اشباع SSH هستند و چک‌سام فقط سربار کوچکی اضافه می‌کند. شکاف در سه جا باز می‌شود:

1. فایل‌های ریز انبوه. rsync پیمایش پوشه را پایپ‌لاین می‌کند و می‌تواند از یک اتصال استفاده مجدد کند؛ پیاده‌سازی‌های قدیمی scp به ازای هر فایل پردازش می‌ساختند. هزاران فایل ریز (یک node_modules، نصب یک WordPress) با rsync محسوس‌تر تمام می‌شوند.
2. اجرای دوباره. یک فایل 4 گیگابایتی را کپی کنید که 50 مگابایتش تغییر کرده و rsync حدوداً همان 50 مگابایت را جابه‌جا می‌کند؛ scp دوباره 4 گیگابایت را می‌فرستد.
3. فشرده‌سازی. -z حین انتقال فشرده می‌کند که روی لینک‌های WAN کند کمک می‌کند.

می‌توانید هر دو را خودتان زمان‌گیری کنید — شکل دستور یکسان است:

# same file, same server, both over SSH
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

# re-run both: scp re-copies, rsync verifies and sends ~nothing
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

اگر روزتان در سرورها می‌گذرد، سرعت انتقال از آن چیزهایی است که یک بار اندازه‌گرفتنش می‌ارزد — همان‌طور که ss روی hostهای شلوغ از netstat می‌برد (ببینید ss در مقابل netstat: کدام دستور پورت در Linux).

آیا scp می‌تواند انتقال نیمه‌کاره را ادامه دهد؟

نه. scp امکان ادامه ندارد؛ اگر اتصال در 900 مگابایت از 1 گیگابایت بیفتد، از اول شروع می‌کنید. این پر‌استنادترین دلیل در هر بحث rsync-در-برابر-scp است و واقعی هم هست.

کل طراحی rsync بر این فرض بنا شده که انتقال گاهی قطع می‌شود. وردِ جادویی ادامه انتقال:

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

• --partial فایل نیمه‌نوشته را نگه می‌دارد به‌جای حذفش.
• --append-verify با الحاق ادامه می‌دهد و بعد ناحیه الحاق‌شده را با checksum راستی‌آزمایی می‌کند — در برابر فایل ناقص خراب امن است، برخلاف --append ساده قدیمی.
• --progress نشان می‌دهد از کجا برداشته است.

داخل یک حلقه retry، این یک بکاپ بی‌دردسر حتی روی اتصالی بدخواه است:

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

چه زمانی به‌جای rsync از scp استفاده کنیم؟

scp در چند مورد هنوز ابزار درست است:

• یک فایل کوچک، یک بار. تایپ scp app.conf user@host:/etc/myapp/ از هر فراخوانی rsync کوتاه‌تر است و چیزی هم برای ادامه دادن نیست.
• rsync در آن طرف غایب است. rsync به باینری خودش در دو سر خط نیاز دارد. خیلی از کانتینرهای مینیمال و دستگاه‌های آماده سرور SFTP مربوط به scp را دارند ولی rsync نه.
• نمی‌خواهید سرور rsync در معرض دید باشد. کمیاب است، ولی بعضی محیط‌ها daemon rsync را مشخصاً می‌بندند.

یک ظرافت که دانستنش می‌ارزد: پروژه OpenSSH سال‌ها پیش پروتکل اصلی scp را منسوخ اعلام کرد و scp مدرن در واقع زیر پوست SFTP حرف می‌زند. این یک quirk گریز از مسیر را درست کرد، اما در دو محدودیتی که اینجا مهم‌اند هیچ تغییری نداد — نه ادامه انتقال دارد و نه انتقال دلتا. عوض شدن پروتکل، scp را rsync نمی‌کند.

مرتبط با همین: اگر سؤال واقعی شما «rsync یا cp» است، جواب آینه همین بحث است — cp معادل محلیِ scp است (بدون ادامه انتقال، بدون دلتا، بدون ویژگی‌های فایل مگر فلگ اضافه کنید) و rsync هم محلی هم ریموت را پوشش می‌دهد. برای کپی‌های یک‌باره محلی، cp کافی است.

کدام فلگ‌های rsync اهمیت دارند؟

بیشتر مردم فقط به یک خط نیاز دارند:

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

فلگ	چه می‌کند
-a (archive)	بازگشتی + حفظ مجوزها، زمان‌ها، گروه، symlinkها، دستگاه‌ها
-v (verbose)	فهرست می‌کند چه چیزی منتقل می‌شود
-h (human)	اندازه‌های خوانا برای انسان
--partial	فایل‌های نیمه‌منتقل‌شده را نگه می‌دارد تا اجرای بعدی ادامه دهد
--progress	پیشرفت به ازای هر فایل — همان چیزی که scp هرگز نداشت
-z	حین انتقال فشرده می‌کند (CPU کند روی LAN سریع: نزنید)
--delete	حذف‌ها را هم آینه می‌کند — خطرناک، همیشه با dry-run جفت کنید
--dry-run (-n)	نشان می‌دهد چه خواهد شد، هیچ چیزی را عوض نمی‌کند

دو عادت که ارزش فراگیری دارند. اول، هر دستوری که --delete دارد را اول dry-run بگیرید:

rsync -avh --delete --dry-run src/ user@server:/srv/dest/   # review
rsync -avh --delete src/ user@server:/srv/dest/             # then commit

دوم، مراقب اسلش انتهایی باشید — /srv/src خود پوشه را داخل مقصد کپی می‌کند، در حالی که /srv/src/ محتویاتش را را. این یک بار سر هرکسی می‌کوبد؛ rsync حتی وقتی شما شکل دیگر را می‌خواستید هشدار «no bytes transferred» می‌دهد.

برای همگام‌سازی روزانه یا هفتگی، rsync را در یک timer مربوط به systemd بیندازید تا فقط دلتاها را کپی کند — سمت journalctlِ زمان‌بندی در چیت‌شیت journalctl پوشش داده شده.

rsync در مقابل scp: حکم نهایی

	scp	rsync
همراه OpenSSH می‌آید	بله	بله (هر دو سر لازم است)
ادامه انتقال نیمه‌کاره	خیر	بله (--partial)
انتقال دلتا در اجراهای بعدی	خیر	بله
حفظ مجوزها و symlinkها	جزئی	کامل (-a)
الگوهای استثنا	خیر	--exclude
آزمایش بدون اجرا	خیر	--dry-run
آینه کردن حذف‌ها	خیر	--delete
مناسب برای	کپی‌های یک‌باره سریع	بکاپ، همگام‌سازی، درخت‌های بزرگ

برای بکاپ‌ها، درخت‌های بزرگ، هر چیزی روی لینکی که می‌تواند بیفتد و هر چیزی که بیش از یک بار اجرایش می‌کنید، پیش‌فرض rsync را بگذارید. از scp وقتی استفاده کنید که نوشتن دستور کوتاه‌تر از فکر کردن به آن است. اگر قرار است فقط یک فلگ با خودتان ببرید، --partial را ببرید — هر قطع شدن آینده را از یک شروع مجدد به یک مکث تبدیل می‌کند.