Rsync vs SCP: कौन-सा Linux कॉपी कमांड इस्तेमाल करें

झटपट एक-बार की कॉपी से बड़े हर काम के लिए rsync, और scp तब जब फ़ाइल को इसी वक़्त दूसरी मशीन पर पहुँचाना है। मूल फ़र्क़ यह है: scp हर बार पूरी फ़ाइल फिर से बहाता है और टूटे कनेक्शन की कोई याद नहीं रखता, जबकि rsync सोर्स और डेस्टिनेशन की तुलना करता है, सिर्फ़ बदले हुए ब्लॉक भेजता है, और रुकी हुई कॉपी को वहीं से आगे बढ़ा देता है। कमज़ोर लाइन पर बड़े बैकअप में यही फ़र्क़ है दो मिनट और फिर से शुरू करने के बीच। दोनों लगभग हर Linux डिस्ट्रो में OpenSSH के साथ ही आते हैं, तो यह इंस्टॉल का सवाल नहीं, आदत का सवाल है — और आदत का डिफ़ॉल्ट rsync होना चाहिए। नीचे: सीधी तुलना टेबल, असली स्पीड का फ़र्क़, वह resume चाल जो scp कर ही नहीं सकता, और वे हालात जहाँ scp अब भी सही जवाब है।

rsync और scp में असल फ़र्क़ क्या है?

scp एक ही काम करता है: SSH चैनल खोलो, बाइट्स बहाओ, बंद करो। दो चलाने के बीच उसका कोई हाल नहीं रहता, तो ट्रांसफ़र 90% पर मर गया तो शून्य से शुरू करना पड़ता है।

rsync एक सिंक टूल है जो इत्तेफ़ाक़न SSH को अपना रास्ता बनाता है। भेजने से पहले वह डेस्टिनेशन फ़ाइल की checksum सूची बनाता है (rolling-checksum delta एल्गोरिद्म) और सिर्फ़ अलग वाले ब्लॉक भेजता है। वही कमांड दो बार चलाइए और दूसरी बारी में लगभग कुछ भी सफ़र नहीं करता। इसी वजह से rsync दो डायरेक्टरी सिंक में रखने का क़ुदरती टूल भी है — शेड्यूल कर दीजिए और हर चलाने में सिर्फ़ डेल्टा कॉपी होता है।

अमली नतीजे:

• बीच में रुकना: rsync वहीं से आगे बढ़ता है; scp फ़ाइल शुरू से।
• दूसरी बार कॉपी: rsync सिर्फ़ बदलाव भेजता है; scp सब कुछ दोबारा।
• डिलीशन: rsync --delete से deletions भी मिरर कर सकता है; scp नहीं।
• फ़िल्टरिंग: rsync में --exclude पैटर्न हैं; scp जिसकी तरफ़ इशारा, सब कॉपी करता है।
• ड्राई रन: rsync --dry-run से बता देता है कि क्या करेगा; scp कुछ नहीं देता।

क्या rsync scp से तेज़ है?

तेज़ लाइन पर एक बड़ी फ़ाइल की पहली कॉपी में दोनों बराबरी पर हैं — दोनों SSH को भर देते हैं, और checksum के चक्कर का ओवरहेड नगण्य है। खाई तीन जगह खुलती है:

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: which Linux port command to use)।

क्या scp रुके हुए ट्रांसफ़र को वहीं से आगे बढ़ा सकता है?

नहीं। 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 जोड़कर आगे बढ़ता है, फिर जोड़े गए हिस्से की 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 की किसी भी सूरत से छोटा है, और resume करने को कुछ है नहीं।
• सामने वाले सिरे पर rsync नहीं है। rsync को दोनों तरफ़ उसका बाइनरी चाहिए। कई न्यूनतम कंटेनर और ऐप्लायंस scp का SFTP सर्वर तो रखते हैं पर rsync नहीं।
• rsync सर्वर उजागर नहीं चाहिए। दुर्लभ बात है, पर कुछ माहौल rsync डेमॉन को ख़ास तौर पर बंद रखते हैं।

एक बारीकी जान लीजिए: OpenSSH प्रोजेक्ट ने scp के मूल प्रोटोकॉल को सालों पहले deprecated कर दिया था, और आज का scp अंदर ही अंदर SFTP बोलता है। इससे एक path-escaping की गड़बड़ी ठीक हुई, पर यहाँ मायने रखने वाली दो कमियों — न resume, न delta ट्रांसफ़र — पर कुछ नहीं बदला। प्रोटोकॉल बदलने से scp, rsync नहीं बन जाता।

जुड़ी एक और बात: अगर आपका सवाल असल में “rsync vs cp” है, तो जवाब इसी का प्रतिबिंब है — cp स्थानीय-सिर्फ़ scp है (न resume, न delta, फ़्लैग जोड़े बिना एट्रिब्यूट्स भी नहीं), और rsync लोकल और रिमोट दोनों के लिए चलता है। लोकल झटपट काम के लिए cp ठीक है।

rsync के सबसे काम के फ़्लैग कौन-से हैं?

ज़्यादातर लोगों को जीवन भर एक ही लाइन चाहिए:

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

फ़्लैग	क्या करता है
-a (archive)	रिकर्सिव + permissions, times, group, symlinks, devices बचाता है
-v (verbose)	क्या ट्रांसफ़र हो रहा है, सूची देता है
-h (human)	इंसान-पढ़ने लायक साइज़
--partial	आधी ट्रांसफ़र हुई फ़ाइलें रखता है, ताकि अगली बारी वहीं से शुरू हो
--progress	हर फ़ाइल की प्रगति — वह चीज़ जो scp कभी नहीं देता
-z	रास्ते में कंप्रेस (तेज़ LAN, धीमा CPU: छोड़ दीजिए)
--delete	deletions भी मिरर करता है — ख़तरनाक, हमेशा पहले ड्राई रन के साथ
--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 तो “no bytes transferred” की चेतावनी भी देता है जब आपका मतलब दूसरे रूप से था।

रोज़ या हफ़्ते का sync करना हो तो rsync को एक systemd timer में बिठा दीजिए और वह सिर्फ़ डेल्टा कॉपी करता रहेगा — शेड्यूलिंग का journalctl वाला पहलू journalctl cheat sheet में सँभला है।

Rsync vs scp: आख़िरी फ़ैसला

	scp	rsync
OpenSSH के साथ आता है	हाँ	हाँ (दोनों सिरे चाहिए)
रुका ट्रांसफ़र वहीं से आगे	नहीं	हाँ (--partial)
दोबारा चलाने पर delta ट्रांसफ़र	नहीं	हाँ
permissions/symlinks बचाना	आंशिक	पूरा (-a)
exclude पैटर्न	नहीं	--exclude
ड्राई रन	नहीं	--dry-run
deletions मिरर करना	नहीं	--delete
किसके लिए बेस्ट	झटपट एक-बार की कॉपी	बैकअप, sync, बड़े ट्री

बैकअप, बड़े ट्री, टूट सकने वाले किसी लिंक पर होने वाला कोई भी काम, और जो एक से ज़्यादा बार चलाने वाला है — उन सबका डिफ़ॉल्ट rsync रखिए। scp तब लीजिए जब कमांड ख़याल से भी छोटी हो। एक फ़्लैग याद रखना हो तो --partial रखिए — वह आने वाला हर टूटा कनेक्शन रीस्टार्ट से निकलकर एक ठहराव बना देता है।