Rsync vs SCP: কোন Linux কপি কমান্ড ব্যবহার করবেন

এক-বারের ছোট কপির বাইরে সব কিছুতে rsync, আর scp তখনই, যখন এখনই অন্য বক্সে একটা ফাইল দরকার। মূল পার্থক্য: scp প্রতিবার পুরো ফাইলটাই আবার স্ট্রিম করে, ছিঁড়ে যাওয়া সংযোগের কোনো স্মৃতি নেই; অথচ rsync উৎস আর গন্তব্য তুলনা করে, শুধু বদলে যাওয়া ব্লক ট্রান্সফার করে, আর থেমে যাওয়া কপি ঠিক সেখান থেকেই resume করে। দুর্বল লিংকে বড় ব্যাকআপে এই পার্থক্যই দুই মিনিট আর শূন্য থেকে শুরুর মধ্যে। প্রায় প্রতিটি Linux ডিস্ট্রিবিউশনে দুটোই OpenSSH-সহ আসে, তাই প্রশ্ন ইনস্টলের নয়, অভ্যাসের — আর অভ্যাসের ডিফল্ট হওয়া উচিত rsync। নিচে: সোজাসাপ্টা তুলনা টেবিল, আসল গতির পার্থক্য, scp-র না-পারা resume কৌশল, আর scp যে কেসগুলোতে এখনো সঠিক উত্তর।

rsync আর scp-র পার্থক্য কী?

scp একটাই কাজ করে: SSH চ্যানেল খোলা, বাইট স্ট্রিম করা, বন্ধ করা। দৌড়ের মাঝে কোনো স্টেট মনে থাকে না, তাই ট্রান্সফার 90%-এ মরলে শূন্য থেকে শুরু।

rsync একটা সিঙ্ক্রোনাইজেশন টুল, যে কাকতালে SSH-কে ট্রান্সপোর্ট হিসেবে ব্যবহার করে। পাঠানোর আগে গন্তব্য ফাইলের চেকসাম-তালিকা বানায় (rolling-checksum delta অ্যালগরিদম) আর কেবল ভিন্ন ব্লকগুলোই পাঠায়। একই কমান্ড দুবার চালান, দ্বিতীয় দৌড়ে প্রায় কিছুই নড়ে না। এজন্যই দুই ডিরেক্টরি সমান রাখার স্বাভাবিক টুলও rsync — তালিকা দিন, প্রতি দৌড়ে কপি হবে কেবল ডেল্টা।

বাস্তব ফলগুলো:

• বিঘ্ন: rsync resume করে; 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 GB ফাইলে 50 MB বদলালে rsync নড়ায় মোটামুটি 50 MB; scp আবার 4 GB নড়ায়।
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 vs netstat: কোন Linux পোর্ট কমান্ড)।

scp কি থেমে যাওয়া ট্রান্সফার resume করতে পারে?

না। scp-র resume নেই; 1 GB-র 900 MB-তে সংযোগ ছিঁড়লে শূন্য থেকে শুরু। rsync-vs-scp যুদ্ধে সবচেয়ে বেশি উদ্ধৃত কারণটা এটাই, আর সেটা আসল।

rsync-র পুরো ডিজাইনই ধরে নেয় ট্রান্সফার মাঝে মাঝে বিঘ্নিত হবে। ক্লাসিক resume মন্ত্র:

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

• --partial অর্ধেক-লেখা ফাইলটা মুছে না ফেলে রেখে দেয়।
• --append-verify জুড়ে দিয়ে resume করে, তারপর জোড়া অংশটা চেকসামে যাচাই করে — করাপ্ট পার্শিয়াল ফাইলের বিরুদ্ধে নিরাপদ, পুরোনো খালি --append-এর মতো নয়।
• --progress দেখায় কোথা থেকে ধরল।

রিট্রাই লুপে জড়িয়ে দিলে সেটা এমনকি শত্রুতাপূর্ণ সংযোগেও set-and-forget ব্যাকআপ:

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 ইনভোকেশনের চেয়ে ছোট, আর resume করার কিছুই নেই।
• ওপার প্রান্তে rsync নেই। rsync-র বাইনারি দুই প্রান্তেই লাগে। অনেক মিনিমাল কন্টেইনার আর অ্যাপ্লায়েন্স scp-র SFTP সার্ভার বহন করে, rsync নয়।
• rsync সার্ভার খোলা রাখতে চান না। বিরল, তবে কিছু পরিবেশ rsync ডেমনকেই আলাদাভাবে বন্ধ রাখে।

একটা সূক্ষ্মতা জানা ভালো: OpenSSH প্রজেক্ট scp-র মূল প্রোটোকল বহু বছর আগেই বাতিল করেছে, আধুনিক scp আসলে নিচে SFTP-তেই কথা বলে। এতে একটা path-escaping কৌশল সারানো, তবে এখানে যে দুটো সীমাবদ্ধতা ম্যাটার করে — resume নেই, ডেল্টা ট্রান্সফার নেই — সেগুলোতে হাত দেয়নি। প্রোটোকল বদলালেই scp হয়ে যায় না rsync।

সম্পর্কিত: প্রশ্নটা আসলে “rsync vs cp” হলে উত্তর এই নিবন্ধেরই প্রতিচ্ছবি — cp হলো scp-র লোকাল-অনলি সংস্করণ (resume নেই, ডেল্টা নেই, ফ্ল্যাগ না দিলে অ্যাট্রিবিউটও নেই), আর rsync লোকাল-রিমোট দুই জায়গাতেই চলে। লোকাল one-shot-এ cp-ই ঠিক।

কোন rsync ফ্ল্যাগগুলো সবচেয়ে কাজের?

বেশিরভাগ মানুষের সারাজীবনে একটা লাইনই লাগে:

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

ফ্ল্যাগ	যা করে
-a (archive)	Recursive + পারমিশন, সময়, গ্রুপ, symlink, ডিভাইস ধরে রাখে
-v (verbose)	কী ট্রান্সফার হচ্ছে তালিকা করে
-h (human)	মানুষ-পাঠযোগ্য সাইজ
--partial	আধা-ট্রান্সফার হওয়া ফাইল রেখে দেয়, ফলে পরের দৌড় resume করে
--progress	প্রতি-ফাইল অগ্রগতি — যা scp-র কখনোই ছিল না
-z	চলার পথে চাপ দেয় (দ্রুত LAN-এ ধীর CPU: বাদ দিন)
--delete	মোছাও মিরর করে — বিপজ্জনক, সবসময় ড্রাই রানের সাথে জুড়ুন
--dry-run (-n)	কী ঘটবে দেখায়, কিছুই বদলায় না

দুটো অভ্যাস গড়ে ফেলুন। প্রথমত, --delete-সহ সব কিছুর আগে ড্রাই রান:

rsync -avh --delete --dry-run src/ user@server:/srv/dest/   # রিভিউ
rsync -avh --delete src/ user@server:/srv/dest/             # তারপর commit

দ্বিতীয়ত, শেষের স্ল্যাশে চোখ রাখুন — /srv/src ডিরেক্টরিটা নিজেকে গন্তব্যে কপি করে, /srv/src/ তার ভেতরের জিনিস কপি করে। সবাই জীবনে অন্তত একবার এখানেই পা পিছলায়; অন্য রূপটা মানে রেখে rsync নিজেই “no bytes transferred” সতর্কবার্তা দেয়।

রোজ বা সাপ্তাহিক sync-এ rsync-কে systemd timer-এ ঢুকিয়ে দিন, সে কেবল ডেল্টা কপি করবে — তালিকা বাঁধার journalctl-দিকটা আছে journalctl cheat sheet-এ।

Rsync vs scp: রায়

	scp	rsync
OpenSSH-সহ আসে	হ্যাঁ	হ্যাঁ (দুই প্রান্তেই লাগে)
থেমে যাওয়া ট্রান্সফার resume	না	হ্যাঁ (--partial)
পুনরাবৃত্ত দৌড়ে ডেল্টা ট্রান্সফার	না	হ্যাঁ
পারমিশন/symlink ধরে রাখা	আংশিক	পূর্ণ (-a)
Exclude প্যাটার্ন	না	--exclude
ড্রাই রান	না	--dry-run
মোছা মিরর করা	না	--delete
সবচেয়ে ভালো যেখানে	দ্রুত এক-বারের কপি	ব্যাকআপ, sync, বিশাল ট্রি

ব্যাকআপ, বড় ট্রি, ছিঁড়তে পারে এমন লিংকের ওপারের যেকোনো কিছু, আর একবারের বেশি চালাবেন এমন যেকোনো কিছুতে ডিফল্ট rsync। scp ব্যবহার করুন যখন কমান্ডটা চিন্তাটার চেয়ে ছোট। একটা ফ্ল্যাগ মনে রাখবেন মাত্র, তা হোক --partial — ভবিষ্যতের প্রতিটা ছেঁড়া সংযোগকে রিস্টার্ট থেকে বিরতিতে নামিয়ে আনে সেটাই।