दो सर्वरों के बीच बड़ी संख्या में फ़ाइलों को जल्दी से कैसे कॉपी करें

90

मुझे दो सेवारत (उबंटू) के बीच बड़ी मात्रा में एमपीज़ ट्रांसफर करने की आवश्यकता है। विशाल से मेरा मतलब है कि एक लाख फाइलें जो औसतन 300K हैं। मैंने कोशिश की scpलेकिन इसमें लगभग एक हफ्ता लगा होगा। (लगभग 500 KB / s) अगर मैं HTTP द्वारा एक भी फाइल को ट्रांसफर करता हूं, तो मुझे 9-10 एमबी / एस मिलते हैं, लेकिन मुझे नहीं पता कि इन सभी को कैसे ट्रांसफर किया जाए।

क्या उन सभी को जल्दी से स्थानांतरित करने का कोई तरीका है?

linux  performance  file-transfer 
— nicudotro
स्रोत
1
सर्वर के बीच आपके पास किस तरह का नेटवर्क है। मैंने प्रत्येक मशीन में 1 एनआईसी के बीच एक जीबी ईथरनेट क्रॉसओवर का उपयोग किया है। मुझे उस विन्यास में पुट के माध्यम से एससीपी
— जिम ब्लोअर
आप जांच कर सकते हैं कि scp इतना धीमा क्यों है। यह धीमा हो सकता है फिर एन्क्रिप्शन की वजह से ftp जैसी चीजें लेकिन यह इतना धीमा नहीं होना चाहिए।
— २०:०२ पर ज़ोराडैच
मेरे पास उनके बीच 100 mbps है। scp छोटी फाइलों पर धीमी है (उनमें से ज्यादातर छोटी हैं)
— निकुदत्रो

जवाबों:

115

मैं टार की सिफारिश करूंगा। जब फ़ाइल पेड़ पहले से ही समान होते हैं, तो rsync बहुत अच्छा प्रदर्शन करता है । हालाँकि, चूंकि rsync प्रत्येक फ़ाइल पर कई विश्लेषण पास करता है, और फिर परिवर्तनों की प्रतिलिपि बनाता है, यह प्रारंभिक प्रतिलिपि के लिए टार की तुलना में बहुत धीमा है। यह आदेश संभवतः वही करेगा जो आप चाहते हैं। यह मशीनों के बीच फाइलों की नकल करेगा, साथ ही अनुमति और उपयोगकर्ता / समूह के स्वामित्व दोनों को संरक्षित करेगा।

tar -c /path/to/dir | ssh remote_server 'tar -xvf - -C /absolute/path/to/remotedir'

नीचे Mackintosh की टिप्पणी के अनुसार यह वह कमांड है जिसका उपयोग आप rsync के लिए करेंगे

rsync -avW -e ssh /path/to/dir/ remote_server:/path/to/remotedir
— स्कॉट पैक
स्रोत
2
+1 टार विकल्प बड़ी संख्या में छोटी फ़ाइलों के लिए अधिक कुशल है क्योंकि दोनों आरसीपी और rsync नेटवर्क में प्रति फ़ाइल कई राउंड ट्रिप होंगे।
— सेकेनरे
3
rsync ने मेरे लिए टार से बेहतर काम किया
— निकुदत्रो
4
इसके अलावा, यदि आपके पास बहुत सी सीपीयू उपलब्ध हैं (दोनों सिरों पर), लेकिन (कम से कम) मेजबानों के बीच एक धीमी कड़ी है, तो यह टार कमांड में कंप्रेशन (जीज़िप या बज़िप) को सक्षम करने के लायक हो सकता है।
— वैटाइन
1
@ जैमी: यदि आप ssh- एजेंट का उपयोग कर रहे हैं, तो इसका उपयोग किया जाना चाहिए। अन्यथा केवल निजी कुंजी खोजने के लिए निर्दिष्ट करने के लिए '-i' विकल्प का उपयोग करें। विवरण के लिए मैन पेज देखें।
— स्कॉट पैक
3
~यदि SSH टर्मिनल का उपयोग कर रहा है तो @niXar एस्केप कैरेक्टर केवल तभी सक्षम होता है। जब आप रिमोट कमांड निर्दिष्ट करते हैं (जब तक कि आप -tविकल्प पास नहीं करते हैं ) ऐसा नहीं है। तो आपकी चिंता अमान्य है।
— गाइल्स
35

बाहरी हार्ड ड्राइव और उसी दिन कूरियर वितरण।

— एडम
स्रोत
10
हेह हे ... कोई नेटवर्किंग तकनीक एक स्टेशन वैगन की बैंडविड्थ को 90 एमपीएच, एह करने वाले टेप से भरी हुई नहीं है? (डरपोक) मैंने मान लिया कि वह एक लैन पर था क्योंकि उसने कहा कि उसे HTTP के साथ 9-10MB / सेकंड मिल रहा था।
— इवान एंडरसन
2
मुझे इंटरनेट पर उस तरह की गति मिलती है, लेकिन मैं जहां रहता हूं, वहां मैं भाग्यशाली हूं! यदि यह एक लैन पर है, तो अभी भी सस्ता है!
— एडम
2
आह - अपने स्थान पर नहीं देखा। हाँ - मैंने सुना है कि कोरिया में इंटरनेट कनेक्टिविटी बहुत शानदार है। यहाँ अमेरिका में फंस गया, मुझे 'नेट' पर 900KB / सेकंड पाने की खुशी है ...
— इवान एंडरसन
1
हाँ, लेकिन आप स्वादिष्ट बर्रिटोस प्राप्त कर सकते हैं जब आप एक डाउनलोड पूरा होने की प्रतीक्षा कर रहे हैं और सियोल में भी लगभग तीन आधे सभ्य मैक्सिकन रेस्तरां हैं ...
— एडम
17

मैं rsync का उपयोग करता हूं।

यदि आपने उन्हें HTTP के माध्यम से निर्देशिका लिस्टिंग के साथ निर्यात किया है, तो आप wget और --mirror तर्क का भी उपयोग कर सकते हैं।

आप पहले से ही देख रहे हैं कि HTTP एससीपी से तेज है क्योंकि एससीपी सब कुछ एन्क्रिप्ट कर रहा है (और इस तरह सीपीयू पर अड़चन है)। HTTP और rsync तेजी से आगे बढ़ने वाले हैं क्योंकि वे एन्क्रिप्ट नहीं कर रहे हैं।

यहां उबंटू पर rsync स्थापित करने पर कुछ डॉक्स दिए गए हैं: https://help.ubuntu.com/community/rsync

वे डॉक्स SSH पर rsync को टनलिंग करने के बारे में बात करते हैं, लेकिन यदि आप डेटा को निजी LAN पर घुमा रहे हैं तो आपको SSH की आवश्यकता नहीं है। (मैं मान रहा हूं कि आप एक निजी लैन पर हैं। यदि आपको इंटरनेट पर 9-10MB / सेकंड मिल रहा है तो मैं जानना चाहता हूं कि आपके पास किस तरह के कनेक्शन हैं!)

यहां कुछ अन्य बहुत ही बुनियादी डॉक्स दिए गए हैं जो आपको एक रिश्तेदार असुरक्षित rsync सर्वर (w / SSH पर निर्भरता नहीं): http://transamrit.net/docs/rsync/ सेटअप करने की अनुमति देगा

— इवान एंडरसन
स्रोत
जबकि SCP डेटा को एन्क्रिप्ट करने के लिए वास्तव में कुछ CPU का उपयोग करता है, मुझे नहीं लगता कि उसके पास 100% CPU उपयोग है, इसलिए CPU एक अड़चन नहीं है। मैंने बहुत बार देखा है कि जब तेजी से स्थानान्तरण की बात आती है तो एससीपी अक्षम है।
— क्रिस्टियन सियुपिटु
यह देखते हुए कि वह एससीपी के लिए 300K और HTTP के लिए 9MB देख रहा था, मैंने मान लिया कि एक एससीपी-संबंधित अड़चन (सामान्य रूप से सीपीयू) खेल में आ रही थी। यह निश्चित रूप से कुछ और हो सकता है, हालांकि। W / o मशीनों के हार्डवेयर स्पेक्स को जानते हुए, यह कहना मुश्किल है।
— इवान एंडरसन
1
rsync लगभग निश्चित रूप से परिवहन के लिए ssh का उपयोग कर रहा है, क्योंकि यह डिफ़ॉल्ट व्यवहार है, इसलिए scp में एन्क्रिप्शन के कारण कोई भी ओवरहेड भी rsync में मौजूद होगा
— डैनियल लॉसन
3
"आप पहले से ही देख रहे हैं कि HTTP एससीपी से तेज है क्योंकि एससीपी सब कुछ एन्क्रिप्ट कर रहा है" → गलत। जब तक उसके पास 10 साल पुराना सर्वर न हो, वह इस कार्य के लिए सीपीयू बाध्य नहीं है।
— niXar
1
@ रामजानपॉलट - आपके पास एक कमांड-लाइन है जो बहुत लंबी है। फ़ाइल चयन को अलग तरीके से निर्दिष्ट करें और यह आपके लिए ठीक काम करेगा। आमतौर पर आप अंत में स्रोत निर्देशिका w / oa वाइल्डकार्ड निर्दिष्ट कर सकते हैं। आप अधिक बारीक पाने के लिए --includeऔर --excludeतर्कों का उपयोग भी कर सकते हैं ।
— इवान एंडरसन
15

बहुत चर्चा के बिना, netcat, नेटवर्क swissarmy चाकू का उपयोग करें। कोई प्रोटोकॉल ओवरहेड नहीं है, आप सीधे नेटवर्क सॉकेट की नकल कर रहे हैं। उदाहरण

srv1$ tar cfv - *mp3 | nc -w1 remote.server.net 4321

srv2$ nc -l -p 4321 |tar xfv -
— Icapan
स्रोत
2
दुर्भाग्य से, मैंने जो भी देखा है netcat बहुत अक्षम है, भले ही यह नहीं होना चाहिए।
— क्रिस्टियन सियुपिटु
मैं तुम्हें नीचा दिखा रहा हूं क्योंकि यह वास्तव में है, वास्तव में भयानक सलाह है। एक सही उत्तर है: rsync। मैं सभी कारणों को सूचीबद्ध कर सकता हूं कि यह बेहतर क्यों है लेकिन यह इस पृष्ठ पर फिट नहीं होगा, अकेले इस छोटे से टिप्पणी बॉक्स को दें।
— niXar
2
@niXar: यदि आप सभी करना चाहते हैं एक एकल फ़ाइल स्थानांतरण (आगे सिंकिंग की कोई आवश्यकता नहीं है), तो टार्पाइप वास्तव में आप सभी की जरूरत है।
— विटिको
2
@niXar netcat ठीक है यदि आप निजी vlan और / या VPN से सुरक्षित वातावरण में ऐसा कर रहे हैं।
— लेस्टर चेउंग
netcat एक सुरक्षित वातावरण के लिए बहुत अच्छा है जब तक आप थोड़े से फ़्लिप नहीं कर लेते और पूरी 1TB स्ट्रीम ख़राब हो जाती है। मेरे पास समानांतर संपीड़न, प्रगति आउटपुट (के माध्यम से pv) और अखंडता के माध्यम से इस तरह की एक विस्तृत स्क्रिप्ट है sha512sum, लेकिन एक बार थोड़ा फ़्लिप होने के बाद, पूरी स्ट्रीम खराब होती है क्योंकि इसे पुनर्प्राप्त करने का कोई तरीका नहीं है। जब हमें वास्तव में ज़रूरत होती है, तो इन सुरक्षित वातावरणों के लिए स्ट्रीमिंग टोरेंट की तरह एक हल्का प्रोटोकॉल होता है जब हमें कम ओवरहेड की आवश्यकता होती है - ऐसा कुछ जो चंक पर अखंडता की जांच करेगा (जैसे, 4 एमबी) के स्तर पर और एक विफल होने पर एक रंक को पुनः प्राप्त कर सकता है। टीसीपी crc पर्याप्त शक्तिशाली नहीं है।
— डैनियल सैंटोस
8

यदि आप rsync के साथ जाते हैं तो बहुत सारी फ़ाइलों के साथ, मैं संस्करण 3 या उससे ऊपर दोनों छोरों को प्राप्त करने का प्रयास करूंगा । कारण यह है कि एक कम संस्करण हस्तांतरण शुरू होने से पहले हर फ़ाइल को एन्यूमरेट करेगा। नई सुविधा को वृद्धिशील-पुनरावृत्ति कहा जाता है ।

एक नया वृद्धिशील-पुनरावृत्ति एल्गोरिथ्म अब उपयोग किया जाता है जब rsync दूसरे 3.x संस्करण से बात कर रहा होता है। इससे स्थानांतरण अधिक तेज़ी से शुरू होता है (सभी फाइलें मिलने से पहले), और बहुत कम मेमोरी की आवश्यकता होती है। कुछ प्रतिबंधों के लिए मैनपेज में --recursive विकल्प देखें।

— काइल ब्रांड
स्रोत
7

rsync, जैसे अन्य पहले ही सुझा चुके हैं। यदि एन्क्रिप्शन से सीपीयू ओवरहेड एक अड़चन है, तो ब्लोफिश की तरह एक और कम सीपीयू गहन एल्गोरिथ्म का उपयोग करें। जैसे कुछ

rsync -ax -e 'ssh -c blowfish' /local/path user@host:/remote/path

— janneb
स्रोत
साइफर को बदलने के बारे में बिंदु के लिए +1
— डैनियल लॉसन
जब तक आपके पास 10G ईथरनेट और 10 साल पुराना CPU नहीं है, CPU एक अड़चन नहीं होने वाला है।
— niXar
1
बस टिप्पणी: सिफर "-c arcfour" तेज है।
— अरमान
@niXar: लेकिन अगर आपके पास पहले से ही अपनी मशीन पर सीपीयू खपत का काम है, तो यह एक चिंता का विषय है।
— इसहाक
6

80 टीबी डेटा (लाखों छोटी फ़ाइलों) को कल में rsyncस्थानांतरित tar करने से , बहुत तेज़ी से साबित होने से , जैसा कि हमने प्रयास करना बंद कर दिया

# slow
rsync -av --progress /mnt/backups/section01/ /mnt/destination01/section01

और tarइसके बदले ...

# fast
cd /mnt/backups/
tar -cf - section01 | tar -xf - -C /mnt/destination01/

चूंकि ये सर्वर उसी लैन पर हैं, इसलिए गंतव्य एनएफएस-माउंटेड सोर्स सिस्टम पर है, जो पुश कर रहा है। नहीं, इसे और भी तेज करें, हमने atimeफाइलों का संरक्षण नहीं करने का फैसला किया :

mount -o remount,noatime /mnt/backups
mount -o remount,noatime /mnt/destination01

नीचे दिया गया ग्राफिक rsync से टार में किए गए बदलाव को दर्शाता है। यह मेरे बॉस का विचार था और मेरे सहयोगी ने इसे निष्पादित किया और अपने ब्लॉग पर शानदार लेखन किया । मुझे बस सुंदर तस्वीरें पसंद हैं । :)

rsync_vs_tar

— फिलिप डर्बिन
स्रोत
एक हैकर जिस पर मुझे भरोसा है वह बताता है "एनएफ़ के बजाय टार ओवर टीसी भी तेज हो सकता है"। यानी tar cf - directory | ttcp -t dest_machineसे ftp.arl.mil/mike/ttcp.html
— फिलिप Durbin
असंबंधित प्रश्न, लेकिन वह ग्राफ़ कहां से है?
— साइबरजैकब
4

बड़ी संख्या में फ़ाइलों की प्रतिलिपि बनाते समय, मैंने पाया कि टार और rsync जैसे उपकरण अधिक अक्षम हैं, क्योंकि उन्हें कई फ़ाइलों को खोलने और बंद करने के ओवरहेड होने की आवश्यकता है। मैंने एक खुला स्रोत उपकरण लिखा है जिसे फास्ट-आर्काइवर कहा जाता है जो इन परिदृश्यों के लिए टार से भी तेज है: https://github.com/replicon/fast/archiver ; यह कई समवर्ती फ़ाइल संचालन करके तेजी से काम करता है।

यहां दो मिलियन से अधिक फाइलों के बैकअप पर फास्ट-आर्काइव बनाम टार का उदाहरण दिया गया है; तेज-संग्रह करने वाले को संग्रह करने में 27 मिनट लगते हैं, बनाम 1 घंटे 23 मिनट लगते हैं।

$ time fast-archiver -c -o /dev/null /db/data
skipping symbolic link /db/data/pg_xlog
1008.92user 663.00system 27:38.27elapsed 100%CPU (0avgtext+0avgdata 24352maxresident)k
0inputs+0outputs (0major+1732minor)pagefaults 0swaps

$ time tar -cf - /db/data | cat > /dev/null
tar: Removing leading `/' from member names
tar: /db/data/base/16408/12445.2: file changed as we read it
tar: /db/data/base/16408/12464: file changed as we read it
32.68user 375.19system 1:23:23elapsed 8%CPU (0avgtext+0avgdata 81744maxresident)k
0inputs+0outputs (0major+5163minor)pagefaults 0swaps

सर्वर के बीच फ़ाइलों को स्थानांतरित करने के लिए, आप ssh के साथ फास्ट-आर्काइवर का उपयोग कर सकते हैं, जैसे:

ssh postgres@10.32.32.32 "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x
— mfenniak
स्रोत
3

मैं टार का उपयोग netcatदृष्टिकोण के माध्यम से भी करता हूं, इसके अलावा मैं उपयोग करना पसंद करता हूं socat- आपकी स्थिति के लिए अनुकूलन करने के लिए बहुत अधिक शक्ति - उदाहरण के लिए, mss को ट्विक करके। (इसके अलावा, यदि आप चाहें तो हँसें, लेकिन मुझे socatतर्क याद रखना आसान है क्योंकि वे लगातार हैं)। इसलिए मेरे लिए, यह बहुत ही सामान्य रूप से हाल ही में है क्योंकि मैं चीजों को नए सर्वरों में ले जा रहा हूं:

host1$ tar cvf - filespec | socat stdin tcp4:host2:portnum

host2$ socat tcp4-listen:portnum stdout | tar xvpf -

उपनाम वैकल्पिक हैं।

— kenorb
स्रोत
2

ऐसा लगता है कि शीर्ष उत्तर में टाइपोस के एक जोड़े हो सकते हैं। यह बेहतर काम कर सकता है:

tar -cf - /path/to/dir | ssh remote_server 'tar -xvf - -C /path/to/remotedir'
— retracile
स्रोत
मैंने पाया कि जब मैं -f विकल्प का उपयोग करता था तो कमांड विफल हो जाती थी।
— 14:11 बजे user11749
@ user11749: उस कमांड में दो-एफ विकल्प हैं, दोनों की आवश्यकता है। आप पृष्ठभूमि में जाने के लिए sf गुजरने के बारे में बात कर रहे हैं?
— रेट्रासिकल जूल
2
  • नेटवर्क फाइल सिस्टम (NFS) और फिर उन्हें जो भी पसंद है, जैसे मिडनाइट कमांडर (mc), Nautilus (सूक्ति से) के साथ कॉपी करें। मैंने अच्छे परिणामों के साथ NFS v3 का उपयोग किया है।
  • सांबा (CIFS) और फिर जो भी आप चाहते हैं उसके साथ फाइल कॉपी करें, लेकिन मुझे नहीं पता कि यह कितना कुशल है।
  • HTTP के साथ wget --mirrorके रूप में इवान एंडरसन ने सुझाव दिया है या किसी अन्य http ग्राहक। सावधान रहें कि कोई गंदा सिम्बल या भ्रामक सूचकांक फ़ाइलें न हों। यदि आपके पास सभी एमपी 3 हैं, तो आपको सुरक्षित होना चाहिए।
  • rsync । मैंने इसे बहुत अच्छे परिणामों के साथ उपयोग किया है और इसकी एक अच्छी विशेषता यह है कि आप बाद में स्थानांतरण को बाधित और फिर से शुरू कर सकते हैं।

मैंने देखा है कि अन्य लोगों ने netcat का उपयोग करने की सिफारिश की है । इसके साथ अपने अनुभव के आधार पर मैं कह सकता हूं कि यह अन्य समाधानों की तुलना में धीमा है।

— क्रिस्टियन सियुपिटु
स्रोत
2

स्कॉट पैक के अद्भुत जवाब के लिए धन्यवाद (मुझे नहीं पता था कि यह पहले सेश के साथ कैसे करना है), मैं इस सुधार की पेशकश कर सकता हूं (यदि bashआपका शेल है)। यह समानांतर संपीड़न, एक प्रगति संकेतक जोड़ देगा और पूरे नेटवर्क लिंक पर अखंडता की जांच करेगा:

tar c file_list |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        tar xC /directory/to/extract/to
    '

pvआपके पाइप के लिए एक अच्छा प्रगति दर्शक कार्यक्रम है और pigzएक समानांतर gzip प्रोग्राम है जो डिफ़ॉल्ट रूप से आपके सीपीयू के रूप में कई थ्रेड्स का उपयोग करता है (मेरा मानना ​​है कि अधिकतम 8 तक)। आप सीपीयू के अनुपात को नेटवर्क बैंडविथ के साथ बेहतर ढंग से फिट करने के लिए संपीड़न स्तर को ट्यून कर सकते हैं और इसे स्वैप कर सकते हैं pxz -9eऔर pxz -dयदि आपके पास बैंडविड्थ के लिए बहुत अधिक सीपीयू है। आपको केवल यह सत्यापित करना होगा कि दोनों रकम पूर्ण होने पर मेल खाते हैं।

यह विकल्प बहुत बड़ी मात्रा में डेटा के साथ-साथ उच्च विलंबता नेटवर्क के लिए उपयोगी है, लेकिन लिंक अस्थिर और ड्रॉप होने पर बहुत उपयोगी नहीं है। उन मामलों में, rsync संभवतः सबसे अच्छा विकल्प है क्योंकि यह फिर से शुरू हो सकता है।

नमूना उत्पादन:

6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -                     ]
 176MiB [9.36MiB/s] [9.36MiB/s] [                                            <=>                                                                        ]
6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -

ब्लॉक डिवाइस के लिए:

dd if=/dev/src_device bs=1024k |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        dd of=/dev/src_device bs=1024k
    '

जाहिर है, सुनिश्चित करें कि वे गिनती =, स्किप =, तलाश =, आदि के साथ समान आकार या सीमा हैं।

जब मैं इस तरह से फाइल सिस्टम को कॉपी करता हूं, तो मैं अक्सर dd if=/dev/zero of=/thefs/zero.dat bs=64k && sync && rm /thefs/zero.dat && umount /thefsसबसे पहले अप्रयुक्त स्थान को शून्य कर देता हूं , जो कि xfer को गति देता है।

— डैनियल सैंटोस
स्रोत
1

मुझे नहीं लगता कि आप तब तक scp से बेहतर करने जा रहे हैं जब तक आप तेजी से नेटवर्क कार्ड स्थापित नहीं करते। यदि आप इंटरनेट पर ऐसा कर रहे हैं, तो यह मदद नहीं करेगा।

मैं rsync का उपयोग करने की सलाह दूंगा । यह कोई तेज़ नहीं हो सकता है, लेकिन कम से कम अगर यह विफल हो जाता है (या आप इसे बंद कर देते हैं क्योंकि यह बहुत लंबा हो रहा है), तो आप फिर से शुरू कर सकते हैं जहां आपने अगली बार छोड़ दिया था।

यदि आप सीधे गीगाबिट ईथरनेट का उपयोग करके 2 मशीनों को कनेक्ट कर सकते हैं, तो यह संभवत: सबसे तेज़ होगा।

— ब्रेंट
स्रोत
मेरे पास उनके बीच एक अप्रयुक्त 100mbps लिंक है
— निकुदेत्रो
1
SCP से बेहतर नहीं करने जा रहे हैं? SCP एक एन्क्रिप्शन कदम के माध्यम से उस सभी डेटा को आगे बढ़ा रहा है। एससीपी इसे कॉपी करने के सबसे धीमे तरीकों में से एक होने जा रहा है!
— इवान एंडरसन
एससीपी डेटा को एन्क्रिप्ट करने के बारे में सच है, लेकिन एन्क्रिप्शन की गति नेटवर्क कनेक्शन की तुलना में तेज़ी से आदेश है, और इस प्रकार नगण्य है।
— ब्रेंट
1

100Mb / s के लिए सैद्धांतिक प्रवाह 12.5 MB / s है, इसलिए 10MB / s पर आप बहुत अच्छा कर रहे हैं।

मैं rsync करने के सुझाव को भी प्रतिध्वनित करूँगा, शायद ssh के माध्यम से। कुछ इस तरह:

rsync -avW -e ssh $SOURCE $USER@$REMOTE:$DEST

100Mb / s पर आपके CPU को डेटा दर की सराहना किए बिना एन्क्रिप्ट / डिक्रिप्ट को संभालने में सक्षम होना चाहिए। और यदि आप डेटा प्रवाह को बाधित करते हैं, तो आपको उस जगह से फिर से शुरू करने में सक्षम होना चाहिए जहां आपने छोड़ा था। इससे पहले कि यह वास्तव में कुछ भी स्थानांतरित करता है, "लाखों" फ़ाइलों के साथ स्टार्टअप को कुछ समय लगेगा।

— डेविड मैकिन्टोश
स्रोत
1

मैंने इसका सामना किया है, सिवाय इसके कि मैं ओरेकल लॉग्स को स्थानांतरित कर रहा था।

यहाँ टूटने है

  • SCP

    inefficient and encrypted (encrypted = slower than unencrypted 
depending on the link and your processor)

  • rsync 

    efficient but typically encrypted (though not necessarily)

  • एफ़टीपी / HTTP

    both seem to be efficient, and both are plaintext.

मैंने बड़ी सफलता के साथ एफ़टीपी का उपयोग किया (जहां महान सफलता जीबी नेटवर्क पर ~ 700Mb / s के बराबर है)। यदि आप 10 एमबी (जो 80 एमबी / एस के बराबर है) प्राप्त कर रहे हैं, तो कुछ गलत है।

आप हमें डेटा के स्रोत और गंतव्य के बारे में क्या बता सकते हैं? क्या यह सिंगल ड्राइव टू सिंगल ड्राइव है? यूएसबी के लिए RAID?

मुझे पता है कि इस सवाल का जवाब पहले से ही है, लेकिन अगर आपका नेटवर्क Gb / s क्रॉसओवर केबल पर धीमी गति से चल रहा है, तो कुछ चीजें बिल्कुल तय हैं।

— मैट सीमन्स
स्रोत
1

आपने उल्लेख नहीं किया है कि क्या दो मशीनें एक ही LAN पर हैं, या यदि एक सुरक्षित चैनल (यानी SSH का उपयोग करना) अनिवार्य है, लेकिन एक और उपकरण जिसका आप उपयोग कर सकते हैं वह है नेटकैट ।

मैं प्राप्त मशीन पर निम्नलिखित का उपयोग करूंगा:

cd <destdir>
netcat -l -p <port> | gunzip | cpio -i -d -m

फिर भेजने वाले पक्ष पर:

cd <srcdir>
find . -type f | cpio -o | gzip -1 | netcat <desthost> <port>

इसके निम्नलिखित फायदे हैं:

  • उस एन्क्रिप्शन के लिए कोई CPU ओवरहेड नहीं है जो ssh के पास है।
  • gzip -1एक सीपीयू को संतृप्त तो यह एक अच्छा व्यापार बंद है, जबकि अधिकतम प्रवाह को बनाए रखने के संपीड़न का एक सा दिए बिना प्रकाश संपीड़न प्रदान करता है। (शायद एमपी 3 डेटा के लिए फायदेमंद नहीं है, लेकिन चोट नहीं करता है।)
  • यदि आप फ़ाइलों को समूहों में विभाजित कर सकते हैं, तो आप समानांतर में दो या अधिक पाइप चला सकते हैं और वास्तव में सुनिश्चित कर सकते हैं कि आप अपने नेटवर्क बैंडविड्थ को संतृप्त कर रहे हैं।

जैसे,

find <dir1> <dir2> -type f | cpio -o | gzip -1 | netcat <desthost> <portone>
find <dir3> <dir4> -type f | cpio -o | gzip -1 | netcat <desthost> <porttwo>

टिप्पणियाँ:

  • जो कुछ भी तरह से आप हस्तांतरण, मैं शायद एक rsync या चल पाएंगे सामंजस्य बाद में सुनिश्चित करने के लिए आप सब कुछ मिल गया।
  • आप इस्तेमाल कर सकते हैं tarके बजाय cpioअगर आप पसंद करते हैं।
  • यहां तक ​​कि अगर आप ssh का उपयोग करना समाप्त करते हैं, तो मैं यह सुनिश्चित करूंगा कि यह स्वयं किसी संपीड़न का उपयोग नहीं कर रहा है, और gzip -1सीपीयू संतृप्ति से बचने के लिए अपने आप से पाइप करें। (या कम से कम संपीड़न 1 पर सेट करें।)
— इवान
स्रोत
1

उचित विकल्पों के साथ एक साधारण एसपीपी आसानी से लैन पर 9-10 एमबी / एस तक पहुंच जाएगा: 

scp -C -c arcfour256 ./local/files.mp3 remoteuser@remoteserver:/opt/remote

उन विकल्पों के साथ यह संभावना है कि थ्रूपुट 4x या 5x से अधिक तेज हो गया, कोई विकल्प नहीं है (डिफ़ॉल्ट)

लेकिन एक लाख छोटी फाइलों के लिए नहीं। क्या आपने अपने समाधान की कोशिश की?
— सजुक
1

यदि आपके पास src साइड में ftp सर्वर है, तो आप ncftpget का उपयोग ncftp साइट से कर सकते हैं । यह छोटी फ़ाइलों के साथ प्रीफेक्ट काम करता है क्योंकि यह आंतरिक रूप से टार का उपयोग करता है।

एक तुलना यह दिखाती है: चलती 1.9GB छोटी फाइलें (33926 फाइलें)

  1. Scp का उपयोग करने में 11m59s लगते हैं
  2. Rsync का उपयोग करने में 7 m10 लगते हैं
  3. Ncftpget का उपयोग करने में 1m20s लगते हैं
— अली निकेतन
स्रोत
1

आप अपने ट्रांसफर को करने के लिए BBCP कमांड का उपयोग करके भी देख सकते हैं। यह एक बफर समानांतर एसएचएस है जो वास्तव में चिल्लाता है। हम आमतौर पर 90% + लाइन-दर प्राप्त कर सकते हैं बशर्ते हम पाइप को खिलाया रख सकें। 

$ bbcp -s 8 -w 64M -N io 'tar -cO srcdirectory' desthostname:'tar -x -C destdir'

आम तौर पर, हम चारों ओर पीड़ित होने से बचने के लिए वास्तविक प्रयास करते हैं। हम ZFS पूल का उपयोग करते हैं जिसे हम हमेशा अधिक डिस्क स्थान "जोड़" सकते हैं। लेकिन कभी-कभी ... आपको बस सामान स्थानांतरित करना होगा। यदि हमारे पास एक "लाइव" फाइलसिस्टम है जिसे पूर्ण-विस्फ़ोट होने पर भी कॉपी करने में घंटों (या दिन) लग सकते हैं .. हम ओले टू स्टेप ज़फ़्स रूटीन भेजते हैं:

  1. एक ZFS स्नैपशॉट बनाएं, और नई मशीन पर नए पूल में स्थानांतरण करें। जब तक लगे तब तक इसे लेने दें।
  2. दूसरा स्नैपशॉट बनाएं, और इसे वृद्धिशील के रूप में भेजें। वृद्धिशील स्नैपशॉट में केवल पहले से (बहुत छोटा) परिवर्तन-सेट शामिल है, इसलिए यह अपेक्षाकृत जल्दी से गुजरता है।
  3. एक बार जब वृद्धिशील स्नैपशॉट पूरा हो जाता है, तो आप मूल को बदल सकते हैं और नई प्रति को काट सकते हैं और आपका "ऑफ़लाइन डाउनटाइम" न्यूनतम रखा जाता है।

हम बीबीसी पर भी अपने zfs डंप भेजते हैं ... यह हमारे नेटवर्क के उपयोग को अधिकतम करता है और स्थानांतरण समय को कम करता है।

BBCP स्वतंत्र रूप से उपलब्ध है, आप इसे Google कर सकते हैं, और यह एक सीधा-सरल संकलन है। बस इसे अपने / usr / लोकल / बिन में दोनों src और डेस्टिनेशन मशीनों पर कॉपी करें और यह बहुत काम आएगा।

— सी। शमीस
स्रोत
1

मुझे लगता है कि मेरा उत्तर यहां थोड़ी देर से है, लेकिन मैंने एक सर्वर पर mc (मिडनाइट कमांडर) का उपयोग करने के साथ अच्छे अनुभव किए, जो SFTP के माध्यम से दूसरे सर्वर से जुड़ने के लिए।

एफ़टीपी के माध्यम से कनेक्ट करने का विकल्प "वाम" और "राइट" मेनू में है, इस तरह पता दर्ज करके:

/#ftp:name@server.xy/

या

/#ftp:name@ip.ad.dr.ess/

आप स्थानीय फ़ाइल सिस्टम पर फ़ाइल संचालन को नेविगेट और कर सकते हैं।

इसकी पृष्ठभूमि में नकल करने के लिए एक अंतर्निहित विकल्प है, लेकिन मैं स्क्रीन कमांड का उपयोग करना पसंद करता हूं और प्रतिलिपि बनाते समय स्क्रीन से अलग करता हूं (मुझे लगता है कि यह तेजी से चलता है तब भी)।

— डब्ल्यू-आकाश
स्रोत
1

RSync विकल्प के @scottpack उत्तर के लिए

अपलोड के उपयोग की प्रगति को प्रदर्शित करने के लिए '--progess' विकल्प के रूप में कमांड में नीचे दिखाए गए अनुसार।

rsync -avW --progress -e ssh /path/to/dir/ remote_server:/path/to/remotedir

यहाँ छवि विवरण दर्ज करें

— दिनेश सनी
स्रोत
1

यहाँ कुछ तकनीकों की तुलना करने के लिए एक त्वरित बेंचमार्क है,

  • स्रोत एक 4-कोर इंटेल (R) Xeon (R) CPU E5-1620 @ 3.60GHz है जिसमें 250 एमबीपीएस और SMA ड्राइव है
  • गंतव्य 6-कोर इंटेल (R) Xeon (R) CPU E-2136 @ 3.30GHz है जिसमें 1 Gbps बैंडविड्थ और SSD ड्राइव है।

फ़ाइलों की संख्या: 9632, कुल आकार: 814 MiB, औसत आकार: 84 KiB

  • RSYNC: 1m40.570s
  • RSYNC + संरचना: 0m26.519s
  • TAR + NETCAT: 1m58.763s
  • TAR + COMPRESSION + NETCAT: 0m28.009s

Tar / netcat के लिए कमांड थी:

Source : tar -cf - /sourcedir/ | nc -v 11.22.33.44 5000
Dest : nc -v -l 5000 | tar -xf -
— Antares
स्रोत
0

rsync या आप इसे एक फ़ाइल के भीतर इसके सभी टार करने की इच्छा कर सकते हैं और फिर scp कर सकते हैं। यदि आपके पास डिस्कस्पेस की कमी है, तो आप सीधे टाश पर टार पाइप कर सकते हैं, जबकि इसे बनाया जा रहा है।

— एडम गिबिन्स
स्रोत
0

यदि आप MP3 और अन्य संपीड़ित फ़ाइलों को भेज रहे हैं, तो आप किसी भी समाधान से बहुत लाभ नहीं लेंगे जो उन फ़ाइलों को और संपीड़ित करने का प्रयास करता है। समाधान कुछ ऐसा होगा जो दोनों सर्वरों के बीच कई कनेक्शन बना सकता है और इस तरह दोनों सिस्टम के बीच बैंडविड्थ पर अधिक तनाव डाल सकता है। एक बार जब यह अधिकतम हो जाता है, तो आपके हार्डवेयर में सुधार के बिना प्राप्त किया जा सकता है। (उदाहरण के लिए, उन सर्वरों के बीच तेज़ नेटवर्क कार्ड।)

— दस कगार जीतो
स्रोत
0

मैंने 1GB फ़ाइल की प्रतिलिपि बनाने के लिए कुछ उपकरणों की कोशिश की। परिणाम नीचे है: HTTP सबसे तेज़, wget -c nc दूसरी पंक्ति में scp सबसे धीमा, और कई बार विफल। Rsync को फिर से शुरू करने का कोई तरीका ssh बैकएंड के रूप में उपयोग नहीं करता है, इस प्रकार एक ही परिणाम है। अंत में, मैं wb -bqc के साथ http के लिए जाऊंगा और इसे कुछ समय दूंगा। आशा है कि यह मदद करता है

— Mijo
स्रोत
क्या आप अंतर्दृष्टि प्रदान करते हैं कि http सबसे तेज़ क्यों है?
— सजुक
0

मुझे BackupPC डिस्क को दूसरी मशीन में कॉपी करना पड़ा।

मैंने rsync का उपयोग किया।

मशीन में 256 एमबी मेमोरी थी।

मैंने जो प्रक्रिया अपनाई वह यह थी:

  • rsyncबिना निष्पादित -H(9 घंटे लगे)
  • जब rsync समाप्त हो गया, तो मैंने cpoolनिर्देशिका को सिंक्रनाइज़ किया और निर्देशिका के साथ शुरू किया pc; मैंने ट्रांसफर काट दिया।
  • फिर ध्वज के rsyncसाथ पुनः आरंभ किया -Hगया, और pcनिर्देशिका में लिंक की गई सभी फ़ाइलों को सही ढंग से स्थानांतरित किया गया (प्रक्रिया को सभी वास्तविक फ़ाइलों को मिला cpoolऔर फिर pcनिर्देशिका से जोड़ा गया ) (3 घंटे लगे)।

अंत में मैं पुष्टि कर सकता df -mथा कि कोई अतिरिक्त जगह खर्च नहीं की गई थी।

इस तरह से मैं मेमोरी और rsync के साथ समस्या को हटा देता हूं। हर समय मैं शीर्ष और ऊपर का उपयोग करके प्रदर्शन को सत्यापित कर सकता हूं और अंत में मैंने 165GB डेटा स्थानांतरित कर दिया।

— हेक्टर
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.