दो कंप्यूटरों के बीच भारी मात्रा में डेटा भेजने का सबसे तेज़ तरीका क्या है? [बन्द है]

111

यह एक ऐसी स्थिति है जिसमें मैं अक्सर हूं:

मेरे पास 320GB हार्ड-ड्राइव के साथ एक स्रोत सर्वर है, और 16GB RAM ( सटीक चश्मा यहां उपलब्ध है , लेकिन जैसा कि यह एक मुद्दा है मैं अक्सर अन्य मशीनों पर भी चलाता हूं, मैं किसी भी काम पर जवाब पसंद करूंगा "उचित" लिनक्स मशीन)
मेरे पास हार्ड-ड्राइव स्पेस के कई टेराबाइट्स के साथ एक बैकअप सर्वर है ( सटीक चश्मा यहां , ऊपर अस्वीकरण देखें)

मैं स्रोत सर्वर से लक्ष्य सर्वर (विशेष रूप से, डेटा /dev/sda) से 320GB डेटा स्थानांतरित करना चाहता हूं ।

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

मैंने इस प्रश्न को ऑनलाइन खोजा, और कई कमांड्स का परीक्षण किया। जो सबसे अधिक बार दिखाई देता है वह यह है:

ssh user@192.168.1.100 'dd bs=16M if=/dev/sda | gzip' > backup_sda.gz

यह कमांड बहुत धीमी साबित हुई है (यह एक घंटे तक चली, केवल डेटा के माध्यम से लगभग 80GB मिली)। 1GB परीक्षण पैकेट के लिए लगभग 1 मिनट और 22 सेकंड का समय लगा, और संपीड़ित न होने पर दो बार तेजी से समाप्त हुआ। परिणाम इस तथ्य से भी तिरछा हो सकते हैं कि हस्तांतरित फ़ाइल स्रोत प्रणाली पर रैम की मात्रा से कम है।

इसके अलावा (और यह 1 जीबी परीक्षण टुकड़ों पर परीक्षण किया गया था), अगर मैं gzipकमांड का उपयोग करता हूं और मुझे समस्याएं मिल रही हैं dd; परिणामी फ़ाइल में एक अलग चेकसम होता है, जब लक्ष्य पर निकाला जाता है, तो इससे अगर वह सीधे पाइप करता है। मैं अभी भी यह पता लगाने की कोशिश कर रहा हूं कि ऐसा क्यों हो रहा है।

networking backup dd file-transfer

— IQAndreas
स्रोत

54

न 'भूल sneakernet

— gwillie

4

क्या आप /dev/sdaछवि या सिर्फ फाइलों के रूप में स्थानांतरित करना चाहते हैं । Rsync क्यों कोई विकल्प नहीं है? क्या /dev/sdaआप ddएड करते समय घुड़सवार हैं ?

— जोधा लेमन सेप

15

आपका प्रदर्शन डेटा (1GB / 80sec, 80GB / 1h) पूरी तरह से मेल खाता है जो हमें 100 एमबीट पर उम्मीद करनी चाहिए। अपने हार्डवेयर की जाँच करें। ... और गेरिट सही है, 320GB बड़ा हो सकता है, लेकिन "भारी मात्रा में डेटा" गलत उम्मीदें जगाता है।

— 13

8

"डिस्क से भरी मालगाड़ी की बैंडविड्थ को कभी कम मत समझो।" .. क्या आप थ्रूपुट, विलंबता या दोनों के कुछ मिश्रण के बारे में पूछ रहे हैं?

— केशलाम

8

मेरे एक दोस्त ने हमेशा कहा: "एक ट्रक पर हार्ड ड्राइव के ढेर के बैंडविड्थ को कभी कम मत समझो"।

— AMADANON इंक।

139

चूंकि सर्वर शारीरिक रूप से एक दूसरे के बगल में हैं, और आपने उन टिप्पणियों में उल्लेख किया है, जिनके लिए आपकी शारीरिक पहुंच है, सबसे तेज़ तरीका यह होगा कि पहले कंप्यूटर से हार्ड-ड्राइव को बाहर निकालें, दूसरे में रखें, और फ़ाइलों को स्थानांतरित करें। SATA कनेक्शन पर।

— ब्लूराजा - डैनी पफ्लुघोफ्ट
स्रोत

15

+1: भौतिक के माध्यम से स्थानांतरित करना सबसे तेज़ मार्ग प्रतीत होता है, भले ही इसका मतलब है कि कहीं से एक बड़ी बाहरी हार्ड ड्राइव प्राप्त करना। यह £ 40 के बारे में है, और आप शायद पहले ही समय में इतना खर्च कर चुके हैं,

— डेवॉर्ड

3

मैं इस विचार से पूरी तरह असहमत हूं अगर किसी को गीगाबिट नेटवर्क में पूरी गति मिल रही है। एक एचपी जनरल 7 माइक्रोसेवर के बीच एक Zyxel गीगाबिट स्विच पर NFS / SMB पर परीक्षण, और एक पेंटियम G630 मशीन मुझे ~ 100MB / s हस्तांतरण देता है। (जब तक मैं ड्राइव प्लेटर्स के बाहरी किनारे को नहीं छोड़ता।) इसलिए मुझे लगता है कि यह वास्तविक रूप से 3 घंटे के भीतर किया जाएगा। जब तक आप SSD या अत्यंत उच्च प्रदर्शन ड्राइव / स्टोरेज का उपयोग नहीं कर रहे हैं, मुझे नहीं लगता कि 2 प्रतियाँ 100MB / s के थ्रूपुट का उत्पादन कर सकती हैं, इसके लिए प्रत्येक कॉपी ऑपरेशन को 200MB / s को भी तोड़ने की आवश्यकता होगी।

— 1

3

@ आकार: स्पष्ट रूप से आप एक अस्थायी पर प्रतिलिपि नहीं बनाते हैं। यह एक बुरा विचार था, जो हर किसी के बारे में बात नहीं कर रहा था। स्रोत ड्राइव को लक्ष्य मशीन से जोड़ने का बिंदु SATA-> SATA के साथ जाना है dd(या एक फाइलसिस्टम ट्री कॉपी)।

— पीटर कॉर्ड्स

10

"हार्ड ड्राइव से भरे ट्रक के बैंडविड्थ को कभी कम मत समझो। हालांकि एक विलंबता का एक नरक"

— केविन

3

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

— पीटर Cordes

69

netcat इस तरह की स्थितियों के लिए महान है जहां सुरक्षा एक मुद्दा नहीं है:

# on destination machine, create listener on port 9999
nc -l 9999 > /path/to/outfile

# on source machine, send to destination:9999
nc destination_host_or_ip 9999 < /dev/sda
# or dd if=/dev/sda | nc destination_host_or_ip 9999

ध्यान दें, यदि आप ddGNU कोरुटिल्स का उपयोग कर रहे हैं, तो आप SIGUSR1इस प्रक्रिया को भेज सकते हैं और यह प्रगति को stderr पर छोड़ देगा। बीएसडी के लिए dd, का उपयोग करें SIGINFO।

प्रतिलिपि के दौरान प्रगति रिपोर्टिंग में pv और भी अधिक सहायक है:

# on destination
nc -l 9999 | pv > /path/to/outfile

# on source
pv /dev/sda | nc destination_host_or_ip 9999
# or dd if=/dev/sda | pv | nc destination_host_or_ip 9999

— zackse
स्रोत

2

दूसरे उदाहरण के लिए, ddभी आवश्यक है, या अपने दम पर ठीक इलाज कर सकते हैं pv/ कर सकते हैं? (मैंने देखा है कि कुछ कमांड्स "थ्रो अप" जब किसी विशेष फाइल को पढ़ने की कोशिश की जाती है, जैसे कि एक या बाइट्स वाली फाइलें )nc/dev/sda0x00

— IQAndreas

5

@ user1794469 संपीड़न मदद करेगा? मैं सोच रहा हूं कि नेटवर्क वह जगह नहीं है जहां अड़चन है।

— IQAndreas सेप

17

भूल जाते हैं कि bashएक में और क्रमशः netcat से पाइपिंग के बजाय > /dev/tcp/ आईपी  / पोर्ट और < /dev/tcp/ आईपी  / पोर्ट पुनर्निर्देशन का उपयोग कर सकते हैं।

— इंनिस मिसी

5

अच्छा उत्तर। गीगाबिट ईथरनेट अक्सर हार्ड ड्राइव की गति से अधिक तेज होता है, इसलिए संपीड़न बेकार है। कई फ़ाइलों पर विचार करने के लिए tar cv sourcedir | pv | nc dest_host_or_ip 9999और स्थानांतरित करने के लिए cd destdir ; nc -l 9999 | pv | tar xv। कई बदलाव संभव हैं, आप उदाहरण के लिए .tar.gzप्रतियों के बजाय एक गंतव्य स्थान पर रखना चाह सकते हैं । यदि आप निर्देशिका को निर्देशिका में कॉपी करते हैं, तो अतिरिक्त सुरक्षा के लिए आप बाद में एक rsync प्रदर्शन कर सकते हैं, उदाहरण के लिए भाग्य से rsync --inplace -avP user@192.168.1.100:/path/to/source/. /path/to/destination/.यह गारंटी होगी कि सभी फाइलें वास्तव में प्रतियां हैं।

— स्टीफन गौरिचोन

3

IPv4 का उपयोग करने के बजाय आप IPv6 का उपयोग करके एक बेहतर थ्रूपुट प्राप्त कर सकते हैं क्योंकि इसमें बड़ा पेलोड है। आप इसे कॉन्फ़िगर भी नहीं करते हैं, अगर मशीनें IPv6 सक्षम हैं, तो संभवतः उनके पास पहले से ही IPv6 लिंक-स्थानीय पता है

— डेविड कोस्टा

33

तेजी से संपीड़न का उपयोग करें ।
- जो भी आपका स्थानांतरण माध्यम है - विशेष रूप से नेटवर्क या यूएसबी के लिए - आप रीड, कैश और राइट के लिए डेटा फटने के साथ काम करेंगे , और ये बिल्कुल सिंक में नहीं होंगे।
- डिस्क फर्मवेयर, डिस्क कैश, और कर्नेल / राम कैश इसके अलावा, अगर आप भी किसी तरह से सिस्टम 'सीपीयू को रोजगार प्रति विमर्श डेटा की मात्रा को ध्यान केंद्रित कर सकते हैं फट तो आप ऐसा करना चाहिए ।
- सभी में कोई भी संपीड़न एल्गोरिथ्म स्वचालित रूप से जितनी जल्दी हो सके इनपुट के विरल रन को संभाल लेगा, लेकिन बहुत कम हैं जो नेटवर्क के माध्यम से बाकी हिस्सों को संभालेंगे।
- lz4 यहाँ आपका सबसे अच्छा विकल्प है:
  
  LZ4 एक बहुत तेजी से दोषरहित संपीड़न एल्गोरिथ्म है, जो कोर-कोर सीपीयू के साथ स्केलेबल 400 एमबी / प्रति कोर पर संपीड़न गति प्रदान करता है। इसमें मल्टी-GB / s प्रति कोर की गति के साथ एक अत्यंत तेज डिकोडर भी है, जो आमतौर पर मल्टी-कोर सिस्टम पर रैम की गति सीमा तक पहुंचता है।
अधिमानतः अनावश्यक रूप से तलाश न करें ।
- इससे गेज करना मुश्किल हो सकता है।
- यदि आप जिस डिवाइस से कॉपी करते हैं, उस पर बहुत सारी खाली जगह है, और डिवाइस को हाल ही में शून्य नहीं किया गया है, लेकिन सभी स्रोत फ़ाइल-सिस्टम (कॉपी) को कॉपी किया जाना चाहिए, तो संभवत: यह पहली बार करने के लिए आपके लायक है। कुछ इस तरह:
```
</dev/zero tee >empty empty1 empty2; sync; rm empty*
```
- लेकिन यह इस बात पर निर्भर करता है कि आपको किस स्तर पर स्रोत पढ़ना चाहिए। यह आमतौर पर डिवाइस को अपनी /dev/some_diskडिवाइस फ़ाइल से शुरू से अंत तक पढ़ने के लिए वांछनीय है , क्योंकि फाइल-सिस्टम स्तर पर पढ़ने में आम तौर पर बैक-एंड-साइड और डिस्क के आसपास गैर-क्रमिक रूप से मांग करना शामिल होगा। और इसलिए आपकी रीड कमांड कुछ इस तरह होनी चाहिए:
```
</dev/source_device lz4 | ...
```
- हालाँकि, यदि आपके स्रोत फ़ाइल-सिस्टम को पूरी तरह से स्थानांतरित नहीं किया जाना चाहिए, तो फ़ाइल-सिस्टम स्तर पर पढ़ना काफी अपरिहार्य है, और इसलिए आपको अपनी इनपुट सामग्री को एक स्ट्रीम में बॉल करना चाहिए। paxआम तौर पर उस मामले में सबसे अच्छा और सबसे सरल समाधान है, लेकिन आप भी विचार कर सकते हैं mksquashfs।
```
pax -r /source/tree[12] | lz4 | ...
mksquashfs /source/tree[12] /dev/fd/1 -comp lz4 | ...
```
के साथ एन्क्रिप्ट न करेंssh ।
- एक विश्वसनीय माध्यम में एन्क्रिप्शन ओवरहेड जोड़ना अनावश्यक है, और निरंतर ट्रांसफर की गति के लिए गंभीर रूप से हानिकारक हो सकता है जिसमें डेटा रीड को दो बार पढ़ने की आवश्यकता होती है ।
- PRNG पढ़ने डेटा की जरूरत है, या इसके बारे में कम से कम कुछ, अनियमितता बनाए रखने के लिए।
- और निश्चित रूप से आपको डेटा भी स्थानांतरित करने की आवश्यकता है।
- आपको एन्क्रिप्शन ओवरहेड को स्वयं स्थानांतरित करने की भी आवश्यकता है - जिसका अर्थ है प्रति फटने वाले कम डेटा के लिए अधिक कार्य ।
- और इसलिए आपको एक साधारण नेटवर्क कॉपी के लिए netcat( जैसा कि मैं पसंद करता हूं, nmapपरियोजना की अधिक सक्षमncat ) का उपयोग करना चाहिए , जैसा कि कहीं और दिया गया है:
```
###  on tgt machine...
nc -l 9999 > out.lz4
###  then on src machine...
... lz4 | nc tgt.local 9999
```

— mikeserv
स्रोत

1

शानदार जवाब। एक मामूली व्याकरणिक बिंदु - "डेटा की मात्रा को कम करें जो प्रति फटने की आवश्यकता है" - मुझे लगता है कि आप सूचना घनत्व को बढ़ाने के लिए संपीड़न का उपयोग कर रहे हैं क्योंकि 'बर्स्ट' निश्चित-चौड़ाई हैं और इसलिए बदले हुए डेटा की मात्रा स्थिर रहती है हालांकि प्रति फट गई जानकारी भिन्न हो सकती है।

— अभियंता डोलरी

@EngineerDollery - हाँ, वह गूंगा था। मुझे लगता है कि यह बेहतर है,

— mikeserv

@IQAndreas - मैं गंभीरता से इस जवाब पर विचार करूंगा। व्यक्तिगत रूप से मैं पिग का उपयोग करता हूं, और गति में वृद्धि आश्चर्यजनक है । समानता एक बहुत बड़ी जीत है; सीपीयू डेटा पाइपलाइन के किसी भी अन्य भाग की तुलना में बहुत तेज है, इसलिए मुझे संदेह है कि समानांतर संपीड़न आपको धीमा कर देगा (गज़िप समानांतर नहीं है)। आपको यह उपवास पर्याप्त लग सकता है कि हार्ड ड्राइव को चलाने के लिए कोई प्रोत्साहन नहीं है; मुझे आश्चर्य नहीं होगा अगर यह समग्र रूप से तेज हो (डिस्क स्वैप समय सहित)। आप संपीड़न के साथ और बिना बेंचमार्क कर सकते हैं। किसी भी स्थिति में, BlueRaja का डिस्कस्वाप उत्तर या यह आपका स्वीकृत उत्तर होना चाहिए।

— माइक एस

तेजी से संपीड़न एक उत्कृष्ट सलाह है। यह ध्यान दिया जाना चाहिए, हालांकि, यह केवल तभी मदद करता है जब डेटा यथोचित रूप से संपीड़ित हो, जिसका अर्थ है, उदाहरण के लिए, कि यह पहले से ही संपीड़ित प्रारूप में नहीं होना चाहिए।

— वाल्टर ट्रॉस

@WalterTross - यदि कोई इनपुट संपीड़ित है, तो अनुपात में कोई फर्क नहीं पड़ता है, इसलिए जब तक कि सम्पीडन कार्य अंतरण कार्य को बेहतर बनाता है । एक आधुनिक चार-कोर प्रणाली पर एक lz4काम को आसानी से विस्तृत-खुले गीग को भी गति देना चाहिए, और यूएसबी 2.0 एक मौका नहीं खड़ा करता है। इसके अलावा, lz4केवल तब काम करने के लिए डिज़ाइन किया गया था जब यह होना चाहिए - यह आंशिक रूप से इतनी तेज़ है क्योंकि यह जानता है कि कब संपीड़न का प्रयास किया जाना चाहिए और कब नहीं करना चाहिए। और अगर यह एक डिवाइस-फाइल ट्रांसफर की जा रही है, तो प्रिकॉम्प्रेस्ड इनपुट कुछ भी वैसे भी कंप्रेस कर सकता है, अगर सोर्स फाइलसिस्टम में कोई विखंडन हो।

— 15

25

कई सीमाएं हैं जो हस्तांतरण की गति को सीमित कर सकती हैं।

1Gbps पाइप पर अंतर्निहित नेटवर्क ओवरहेड है। आमतौर पर, यह ACTUAL थ्रूपुट को 900Mbps या उससे कम कर देता है। फिर आपको यह याद रखना होगा कि यह द्विदिश ट्रैफिक है और आपको 900Mbps से कम की उम्मीद करनी चाहिए।
भले ही आप "नए-ish राउटर" का उपयोग कर रहे हों, क्या आप निश्चित हैं कि राउटर 1Gbps का समर्थन करता है? सभी नए राउटर 1Gbps का समर्थन नहीं करते हैं। इसके अलावा, जब तक कि यह एंटरप्राइज-ग्रेड राउटर नहीं है, तो आप संभावित रूप से राउटर के लिए अतिरिक्त ट्रांसमिट बैंडविड्थ खो सकते हैं। हालाँकि मुझे नीचे जो मिला है, उसके आधार पर ऐसा लगता है कि आप 100 एमबीपीएस से ऊपर हैं।
आपके नेटवर्क को साझा करने वाले अन्य उपकरणों से नेटवर्क की भीड़ हो सकती है। क्या आपने सीधे अटैच केबल का उपयोग करने की कोशिश की है जैसा कि आपने कहा था कि आप ऐसा करने में सक्षम थे?
आप अपने डिस्क IO की किस राशि का उपयोग कर रहे हैं? इसी तरह, आप नेटवर्क द्वारा नहीं, बल्कि डिस्क ड्राइव द्वारा सीमित किए जा रहे हैं। ज्यादातर 7200rpm HDDs केवल 40MB / s के आसपास मिलेंगे। क्या आप सभी पर छापे का उपयोग कर रहे हैं? क्या आप SSDs का उपयोग कर रहे हैं? आप दूरस्थ छोर पर क्या उपयोग कर रहे हैं?

अगर यह बैकअप के लिए फिर से चलाने की उम्मीद है तो मैं rsync का उपयोग करने का सुझाव देता हूं। आप दूसरे छोर पर फ़ाइलज़िला जैसे डाउनलोडर का उपयोग करके भी scp, ftp (s) या http कर सकते हैं क्योंकि यह ssh / http / https / ftp कनेक्शन को समानांतर बनाएगा। यह बैंडविड्थ बढ़ा सकता है क्योंकि अन्य समाधान एक एकल पाइप पर हैं। एक एकल पाइप / धागा अभी भी इस तथ्य से सीमित है कि यह एकल-थ्रेडेड है, जिसका अर्थ है कि यह सीपीयू बाध्य भी हो सकता है।

Rsync के साथ, आप अपने समाधान की जटिलता की एक बड़ी मात्रा को निकालते हैं और साथ ही संपीड़न, अनुमति संरक्षण और आंशिक स्थानांतरण की अनुमति देते हैं। कई अन्य कारण हैं, लेकिन यह आम तौर पर बड़े उद्यमों की पसंदीदा बैकअप विधि (या बैकअप सिस्टम चलाता है) है। Commvault वास्तव में बैकअप के लिए वितरण तंत्र के रूप में अपने सॉफ्टवेयर के नीचे rsync का उपयोग करता है।

80GB / h के आपके दिए गए उदाहरण के आधार पर, आप लगभग 177Mbps (22.2MB / s) प्राप्त कर रहे हैं। मुझे लगता है कि आप आसानी से rsync के साथ दो बक्से के बीच एक समर्पित ईथरनेट लाइन पर इसे दोगुना कर सकते हैं क्योंकि मैंने इसे गीगाबिट पर rsync के साथ अपने स्वयं के परीक्षणों में प्राप्त करने में कामयाब रहा है।

— Khrystoph
स्रोत

12

के लिए +1 rsync। यह पहली बार जब आप इसे चलाते हैं तो यह तेज नहीं हो सकता है, लेकिन यह निश्चित रूप से सभी बाद के समय के लिए होगा।

— Skrrp

4

> ज्यादातर 7200rpm HDDs केवल 40MB / s के आसपास मिलेंगे। IME आपको आधुनिक ड्राइव के साथ 100MB / s अनुक्रमिक पर देखने की अधिक संभावना है (और इसमें ~ 5k ड्राइव शामिल हैं)। हालाँकि, यह एक पुरानी डिस्क हो सकती है।

— बॉब

2

@ याकूब: वे आधुनिक अभी भी प्रति मिनट केवल 5400 परिपत्र ट्रैक पढ़ सकते हैं। ये डिस्क अभी भी तेज़ हैं क्योंकि प्रत्येक ट्रैक में मेगाबाइट से अधिक है। इसका मतलब है कि वे भी काफी बड़े डिस्क हैं, एक छोटी 320 जीबी डिस्क प्रति ट्रैक पर बहुत अधिक किलोबाइट नहीं पकड़ सकती है, जो जरूरी उनकी गति को सीमित करती है।

— 17

1

40MB / s निश्चित रूप से पिछले दशक में किए गए किसी भी ड्राइव के लिए अनुक्रमिक पढ़ने के लिए बहुत निराशावादी है। जैसा कि बॉब कहते हैं, वर्तमान 7200RPM ड्राइव 100MB / s से अधिक हो सकती है।

— हॉब्स

3

गिगाबिट ईथरनेट 1000 mbps फुल डुप्लेक्स है । आपको प्रत्येक दिशा में 1000mbps (या, जैसा कि आप कहते हैं, लगभग 900mbps) मिलता है । दूसरा ... हार्ड ड्राइव अब नियमित रूप से 100 एमबी / सेकंड प्राप्त करते हैं। 40 एमबी / सेकंड धीमा है, जब तक कि यह एक दशक पुरानी ड्राइव नहीं है।

— derobert

16

हम नियमित रूप से इससे निपटते हैं।

हम जिन दो मुख्य विधियों का उपयोग करते हैं वे हैं:

SATA / eSATA / sneakernet
डायरेक्ट एनएफएस माउंट, फिर स्थानीय cpयाrsync

पहला इस बात पर निर्भर करता है कि ड्राइव को शारीरिक रूप से स्थानांतरित किया जा सकता है या नहीं। ऐसी स्थिति हर बार नहीं होती है।

दूसरा आश्चर्यजनक रूप से अच्छा काम करता है। आम तौर पर हम प्रत्यक्ष एनएफएस माउंट के साथ आसानी से 1 जीबीपीएस कनेक्शन को अधिकतम करते हैं। आप कहीं भी एसटीपी के साथ इसके करीब नहीं पहुंचेंगे, ssh पर dd, या कुछ भी समान (आपको अक्सर अधिकतम दर 100mpbs के करीब मिलेगी)। यहां तक कि बहुत तेज मल्टीकोर प्रोसेसर पर आप दो मशीनों में से सबसे धीमी गति से कोर में से एक के क्रिप्टो थ्रूपुट पर एक टोंटी को मारेंगे, जो अनएन्क्रिप्टेड नेटवर्क माउंट पर फुल-बोर सीपी या आरएसक्यूएन की तुलना में निराशाजनक रूप से धीमा है। कभी-कभी आप थोड़ी देर के लिए आयोप्स की दीवार से टकराएंगे और अधिक विशिष्ट ~ 110 एमबी / एस के बजाय ~ 53 एमबी / एस पर अटक सकते हैं, लेकिन यह आमतौर पर तब तक कम रहता है जब तक कि स्रोत या गंतव्य वास्तव में नहीं होता हैएकल ड्राइव, फिर आप ड्राइव की निरंतर दर से सीमित हो सकते हैं (जो यादृच्छिक कारणों के लिए पर्याप्त रूप से भिन्न होता है जो आपको तब तक पता नहीं चलेगा जब तक आप वास्तव में इसे आजमा नहीं लेते) - meh।

एनएफएस एक अपरिचित डिस्ट्रो पर स्थापित करने के लिए थोड़ा कष्टप्रद हो सकता है, लेकिन आम तौर पर बोलते हुए यह पाइपों को पूरी तरह से भरने का सबसे तेज़ तरीका रहा है। पिछली बार जब मैंने यह 10 जीबीपीएस से अधिक किया था तो मुझे वास्तव में कभी पता नहीं चला कि क्या यह कनेक्शन को अधिकतम करता है, क्योंकि कुछ कॉफी हड़पने से पहले वापस आने से पहले स्थानांतरण समाप्त हो गया था - इसलिए वहां कुछ प्राकृतिक सीमा हो सकती है। यदि आपके पास स्रोत और गंतव्य के बीच कुछ नेटवर्क डिवाइस हैं, तो आप नेटवर्क के स्लिंकी प्रभाव से कुछ मामूली देरी या हिचकी का सामना कर सकते हैं, लेकिन आम तौर पर यह पूरे कार्यालय में काम करेगा (अन्य ट्रैफ़िक को इसे चलाने वाले) या डेटासेंटर के एक छोर से अन्य (जब तक कि आपके पास किसी प्रकार का फ़िल्टरिंग / निरीक्षण नहीं होता है, आंतरिक रूप से, जिस स्थिति में सभी दांव बंद हैं )।

संपादित करें

मैंने संपीड़न के बारे में कुछ बकबक देखा ... कनेक्शन को संपीड़ित न करें। यह आपको उसी तरह धीमा कर देगा जिस तरह से एक क्रिप्टो लेयर होगा। यदि आप कनेक्शन को संकुचित करते हैं, तो अड़चन हमेशा एक ही कोर होगी (और आपको उस कोर बस का विशेष रूप से अच्छा उपयोग भी नहीं मिल रहा होगा)। आपकी स्थिति में सबसे धीमी बात यह है कि एक 1gbps या उच्चतर कनेक्शन पर एक दूसरे के बगल में बैठे दो कंप्यूटरों के बीच एक एन्क्रिप्टेड, संपीड़ित चैनल का उपयोग करना है।

भविष्य प्रूफिंग

यह सलाह 2015 के मध्य की है। यह लगभग निश्चित रूप से बहुत अधिक वर्षों के लिए मामला नहीं होगा। तो नमक के एक दाने के साथ सब कुछ ले लो, और अगर आप नियमित रूप से इस कार्य का सामना करते हैं, तो कल्पना करने के बजाय वास्तविक भार पर कई तरीकों का प्रयास करें, आपको सैद्धांतिक आशाओं के करीब कुछ भी मिलेगा, या यहां तक कि वेब के जैसी चीजों के लिए विशिष्ट संपीड़न / क्रिप्टो थ्रूपुट दरों को भी देखा जाएगा। ट्रैफ़िक, जिनमें से अधिकांश पाठात्मक (प्रोटिप) है: बल्क ट्रांसफ़र में आमतौर पर मुख्यतः चित्र, ऑडियो, वीडियो, डेटाबेस फ़ाइल, बाइनरी कोड, ऑफ़िस फ़ाइल प्रारूप आदि शामिल होते हैं, जो पहले से संपीड़ित होते हैं।अपने तरीके से और अभी तक एक और संपीड़न दिनचर्या के माध्यम से चलाने से बहुत कम लाभ, संपीड़न ब्लॉक आकार, जो लगभग आपके पहले से संकुचित बाइनरी डेटा के साथ संरेखित नहीं करने की गारंटी है ...)।

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

परंतु...

समय परिवर्तन और संपीड़न और एन्क्रिप्शन के खिलाफ मेरी सिफारिश नहीं होगी। मैं वास्तव में इस सलाह के लिए बहुत जल्द ही सामान्य मामले में पलट जाना पसंद करूंगा । यह मेरे जीवन को आसान बना देगा।

— zxq9
स्रोत

1

@jofel केवल जब नेटवर्क की गति प्रोसेसर के संपीड़न थ्रूपुट की तुलना में धीमी होती है - जो 1gpbs या उच्चतर कनेक्शन के लिए सच नहीं है। विशिष्ट मामले में, हालांकि, नेटवर्क अड़चन है, और संपीड़न प्रभावी ढंग से चीजों को गति देता है - लेकिन यह वह स्थिति नहीं है जो ओपी का वर्णन करता है।

— zxq9

2

lz4तेजी से टोंटी के लिए पर्याप्त नहीं है, लेकिन आप प्रतिलिपि के साथ क्या करना चाहते हैं इसके आधार पर, आपको इसे असम्पीडित करने की आवश्यकता हो सकती है। lzop बहुत तेज़ है, भी। मेरे i5-2500k Sandybridge (3.8GHz) पर, lz4 < /dev/raid0 | pv -a > /dev/null~ 180MB / s इनपुट, ~ 105MB / s आउटपुट पर जाता है, जो सिर्फ गीगा के लिए सही है। सीपीयू पर प्राप्त पक्ष को कम करना और भी आसान है।

— पीटर कॉर्ड्स

1

इसके अलावा, ज्यादातर सर्वर प्रोसेसर चलाने (या किसी भी स्वाद के कई बिजनेस-ग्रेड सिस्टम, कम से कम जिसे मैं देखने के लिए उपयोग किया जाता है) की तुलना में 3.8GHz काफी तेज़ है। डेटा केंद्रों में बहुत कम घड़ी की गति के साथ बहुत अधिक कोर कोर देखना अधिक आम है। स्थानांतरण भार का समांतरिकरण लंबे समय तक एक मुद्दा नहीं रहा है , इसलिए हम ज्यादातर मामलों में एक ही कोर की अधिकतम गति के साथ फंस गए हैं - लेकिन मुझे उम्मीद है कि यह अब बदल जाएगा कि क्लॉकस्पीड आमतौर पर अधिकतम हो जाते हैं लेकिन नेटवर्क गति अभी भी है उनके मैक्सिमम को मारने से पहले जाने का लंबा रास्ता।

— zxq9

2

मैं संपीड़न के बारे में आपकी टिप्पणियों से पूरी तरह असहमत हूं। यह पूरी तरह से डेटा की संपीड़ितता पर निर्भर करता है। यदि आप 99.9% संपीड़न अनुपात प्राप्त कर सकते हैं, तो ऐसा करना मूर्खतापूर्ण नहीं होगा - जब आप 100MB स्थानांतरित करने के साथ दूर हो सकते हैं तो 100GB क्यों स्थानांतरित करें? मैं सुझाव नहीं दे रहा हूं कि इस प्रश्न के लिए संपीड़न का यह स्तर है, बस यह दिखा रहा है कि इस मामले पर केस के आधार पर विचार किया जाना है और कोई पूर्ण नियम नहीं हैं।

— इंजीनियर डेली

1

@EngineerDollery यह थोक हस्तांतरण में बाहर खेलने नहीं करता है बिल्कुल असली दुनिया में। मैं लगभग हर दिन ऐसा करता हूं और विभिन्न तरीकों और सेटिंग्स का परीक्षण किया है। अज्ञात डेटा के सामान्य मामले बड़े थोक स्थानान्तरण (कुछ भी आप पर संपीड़न ट्यूनिंग परीक्षण चलाने के लिए समय नहीं है - जो अभ्यास किसी भी डाटा सेंटर में लगभग सब कुछ, कॉर्पोरेट ढांचे, लघु व्यवसाय सर्वर, या घर नेटवर्क में इसका मतलब है) में कर रहे हैं ज्यादा 1 जीबीपीएस या उससे अधिक कनेक्शन पर तेजी से। कोशिश करके देखिए। पाठ आमतौर पर संपीड़न के लिए सबसे अच्छा मामला है। पाठ में एक सामान्य थोक हस्तांतरण पेलोड का एक छोटा सा अंश शामिल है।

— zxq9

6

एक निफ्टी टूल जो मैंने अतीत में इस्तेमाल किया है bbcp। के रूप में यहां देखी गई: https://www.slac.stanford.edu/~abh/bbcp/ ।

Http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm भी देखें

मेरे पास इस उपकरण के साथ बहुत तेज़ स्थानांतरण गति है।

— रहस्यमयी आत्मा
स्रोत

1

इस उत्तर की दूसरी कड़ी यह बताती है कि कर्नेल मापदंडों को उच्च गति तक कैसे पहुंचाया जाए। लेखक को 10G लिंक्स में 800 मेगाबाइट प्रति सेकंड और कुछ चीजें 1Gbps लिंक पर लागू होती हैं।

— स्टीफन गौरिचोन

5

यदि आपको किसी तरह से पहला पास मिलता है (तार / छलनी / जो भी हो), तो आप rsyncकुछ निश्चित विकल्पों पर गौर कर सकते हैं जो बाद के स्थानान्तरण को गति प्रदान कर सकते हैं। जाने का एक बहुत अच्छा तरीका होगा:

rsync -varzP sourceFiles destination

विकल्प हैं: क्रिया, संग्रह मोड, पुनरावर्ती, संपीड़ित, आंशिक प्रगति

— बनी को रोकना
स्रोत

2

Rsync netcat की तुलना में अधिक विश्वसनीय है, लेकिन संग्रह का तात्पर्य पुनरावर्ती है, इसलिए r निरर्थक है।

— तन्नाथ

इसके अलावा, -zआपके CPU और आपके द्वारा संसाधित किए जा रहे डेटा के आधार पर अविश्वसनीय रूप से धीमा हो सकता है। मैंने संपीड़न को अक्षम करते समय 30 एमबी / एस से 125 एमबी / एस तक जाने का अनुभव किया है।

— lindhe

4

टिप्पणी करने के लिए मूल पोस्टर की जिद पर जवाब देने के लिए जोड़ा गया, हालांकि मुझे यकीन नहीं है कि यह विशिष्ट परिस्थितियों में सबसे तेज है।

bashएक विशेष पुनर्निर्देशन सिंटैक्स है:
आउटपुट के लिए: > /dev/tcp/ आईपी  / पोर्ट
इनपुट के लिए: < /dev/tcp/ आईपी  / पोर्ट
आईपी प्रतिबंध या तो बिंदीदार-दशमलव आईपी या एक होस्टनाम होना चाहिए; पोर्ट प्रतिबंध या तो एक दशमलव संख्या या पोर्ट नाम से होना चाहिए /etc/services।

कोई वास्तविक /dev/tcp/निर्देशिका नहीं है। यह एक विशेष सिंटैक्टिक कीचड़ है जो bashटीसीपी सॉकेट बनाने के लिए आदेश देता है, इसे निर्दिष्ट गंतव्य से कनेक्ट करता है, और फिर वही काम करता है जो एक सामान्य फ़ाइल पुनर्निर्देशन करता है (अर्थात्, संबंधित मानक धारा को डुबकी 2 (2) का उपयोग करके सॉकेट से बदल देता है)।

इसलिए, कोई सीधे टीसीपी के माध्यम से ddया tarस्रोत मशीन से डेटा स्ट्रीम कर सकता है । या, इसके विपरीत, tarटीसीपी के माध्यम से सीधे या कुछ के लिए डेटा स्ट्रीम करने के लिए । किसी भी मामले में, एक अतिरंजित netcat को समाप्त कर दिया जाता है।

Netcat के बारे में नोट्स

नहीं है शास्त्रीय netcat और GNU netcat के बीच वाक्य रचना में असंगतता । मैं जिस शास्त्रीय वाक्य रचना का आदी हूँ, उसका उपयोग करूँगा। GNU netcat के -lpसाथ बदलें -l।

इसके अलावा, मैं अनिश्चित हूं कि क्या GNU नेटकैट -qस्विच को स्वीकार करता है ।

डिस्क छवि स्थानांतरित करना

(ज़ैकसे के उत्तर की पंक्तियों के साथ।)
गंतव्य पर:

nc -lp 9999 >disk_image

स्रोत पर:

dd if=/dev/sda >/dev/tcp/destination/9999

के साथ एक tar.gz संग्रह बनाना `tar`

गंतव्य पर:

nc -lp 9999 >backup.tgz

स्रोत पर:

tar cz files or directories to be transferred >/dev/tcp/destination/9999

बदलें .tgzके साथ .tbzऔर czसाथ cjएक पाने के लिए bzip2-compressed संग्रह।

फाइल सिस्टम में तत्काल विस्तार के साथ स्थानांतरण

के साथ भी tar।
गंतव्य पर:

cd backups
tar x </dev/tcp/destination/9999

स्रोत पर:

tar c files or directories to be transferred |nc -q 1 -lp 9999

यह बिना काम करेगा -q 1, लेकिन डेटा खत्म होने पर नेटकैट अटक जाएगा। सिंटैक्स और केविट के स्पष्टीकरण के लिए टार (1) देखें tar। अगर वहाँ उच्च अतिरेक (कम एन्ट्रापी), तो संपीड़न के साथ कई फ़ाइलें (ई। जी। कर रहे हैं czऔर xzके बजाय cऔर x) करने की कोशिश की जा सकती है, लेकिन अगर फ़ाइलों प्रतीक हैं और नेटवर्क पर्याप्त तेज़ है, यह केवल प्रक्रिया को धीमा होगा। संपीड़न के बारे में विवरण के लिए माइकसर्व का उत्तर देखें।

वैकल्पिक शैली (गंतव्य पोर्ट सुनता है)

गंतव्य पर:

cd backups
nc -lp 9999 |tar x

स्रोत पर:

tar c files or directories to be transferred >/dev/tcp/destination/9999

— इंनिसिस मिस्सी
स्रोत

वास्तव में एक सॉकेट पर बैश वास्तव में "सुन" नहीं सकता है, किसी फ़ाइल को प्रतीक्षा करने और प्राप्त करने के लिए: unix.stackexchange.com/questions/49936/ ... ताकि आपको कनेक्शन के कम से कम एक आधे के लिए कुछ और उपयोग करना पड़े ...

— रॉगरडपैक

3

सीधे कनेक्शन के बारे में सुझावों को आज़माएं और एन्क्रिप्टेड प्रोटोकॉल जैसे ssh से बचें। तब यदि आप अभी भी हर बिट प्रदर्शन को बाहर निकालना चाहते हैं, तो इस साइट को एक रीडिंग दें: https://fasterdata.es.net/host-tuning/linux/ अपनी टीसीपी विंडो को अनुकूलित करने के बारे में कुछ सलाह के लिए।

— ब्रैंडन ज़ेवियर
स्रोत

2

मैं इस स्क्रिप्ट का उपयोग करूँगा जो मैंने लिखा था कि socatपैकेज की आवश्यकता है ।

स्रोत मशीन पर:

tarnet -d wherefilesaretosend pass=none 12345 .

लक्ष्य मशीन पर:

tarnet -d wherefilesaretogo pass=none sourceip/12345

यदि vbufपैकेज (डेबियन, उबंटू) है तो फ़ाइल भेजने वाले को डेटा प्रगति दिखाई देगी। फ़ाइल रिसीवर दिखाएगा कि कौन सी फाइलें प्राप्त हुई हैं। पास = विकल्प का उपयोग किया जा सकता है जहां डेटा उजागर हो सकता है (धीमा)।

संपादित करें:

-nसंपीड़न को अक्षम करने के लिए विकल्प का उपयोग करें , यदि सीपीयू एक बोतल गर्दन है।

— Skaperen
स्रोत

2

यदि बजट मुख्य चिंता का विषय नहीं है, तो आप ड्राइव को Intel Xeon E5 12 कोर "ड्राइव कनेक्टर" से जोड़ने का प्रयास कर सकते हैं। यह कनेक्टर आमतौर पर इतना शक्तिशाली होता है, कि आप इस पर अपना वर्तमान सर्वर सॉफ्टवेयर भी चला सकते हैं। दोनों सर्वरों से!

यह एक मजेदार जवाब की तरह लग सकता है, लेकिन आपको वास्तव में इस बात पर विचार करना चाहिए कि आप सर्वर के बीच डेटा क्यों ले जा रहे हैं और यदि साझा मेमोरी और स्टोरेज वाला कोई बड़ा काम हो सकता है।

वर्तमान चश्मे के बारे में निश्चित नहीं है, लेकिन धीमी गति डिस्क गति द्वारा सीमित हो सकती है, नेटवर्क नहीं?

— user133111
स्रोत

1

यदि आप केवल बैकअप के बारे में परवाह करते हैं, और हार्ड ड्राइव की बाइट कॉपी के लिए बाइट के बारे में नहीं, तो मैं बैकअपपीसी की सिफारिश करूंगा। http://backuppc.sourceforge.net/faq/BackupPC.html यह सेटअप करने के लिए एक दर्द का एक सा है, लेकिन यह बहुत जल्दी स्थानांतरित करता है।

लगभग 500G डेटा के लिए मेरा प्रारंभिक स्थानांतरण समय लगभग 3 घंटे था। इसके बाद के बैकअप लगभग 20 सेकंड में होते हैं।

यदि आपकी दिलचस्पी बैकअप में नहीं है, लेकिन चीजों को सिंक करने की कोशिश कर रहे हैं तो rsync या unison आपकी आवश्यकताओं के अनुसार बेहतर होंगे।

हार्ड डिस्क की बाइट कॉपी के लिए एक बाइट आमतौर पर बैकअप उद्देश्यों के लिए एक भयावह विचार है (कोई वृद्धि नहीं, कोई अंतरिक्ष की बचत नहीं है, ड्राइव उपयोग में नहीं हो सकती है, आपको "खाली स्थान" का बैकअप लेना होगा, और आपको कचरा वापस करना होगा (जैसे 16 G स्वैप फाइल या 200G कोर डंप या कुछ ऐसे)। rsync (या बैकपेक या अन्य) का उपयोग करके आप समय में "स्नैपशॉट" बना सकते हैं, ताकि आप 30 मिनट पहले "आपकी फाइल सिस्टम की तरह दिखे" पर जा सकें। बहुत कम ओवरहेड।

उस ने कहा, यदि आपकी वास्तव में बाइट कॉपी के लिए एक बाइट को स्थानांतरित करना है तो आपकी समस्या स्थानांतरण में झूठ बोलने वाली है, न कि ड्राइव से डेटा प्राप्त करने में। 400G रैम के साथ 320G फाइल ट्रांसफर में बहुत अधिक समय लगने वाला है। एन्क्रिप्ट किए गए प्रोटोकॉल का उपयोग करना एक विकल्प है, लेकिन कोई बात नहीं, आपके बस वहां बैठने और कई घंटों (नेटवर्क पर) इंतजार करना होगा।

— coteyr
स्रोत

1

400G RAM डेटा ट्रांसफर को कैसे तेज करता है?

— स्केपरन

यकीन नहीं था कि यह इरादा था, लेकिन मैंने इसे "RAM से RAM ट्रांसफर के लिए किसी भी माध्यम को धीमा करने के लिए जा रहा है" के रूप में पढ़ा, बल्कि "400 GB RAM खरीदें और आपका HDD से HDD ट्रांसफर तेजी से आगे बढ़ेगा"।

— माइकल

हाँ ,, राम तुम्हारे लिए बफर होगा, और यह तेजी से प्रतीत होगा। आप सभी तरह से रैम बफरिंग के साथ एक HD से HD ट्रांसफर कर सकते हैं और यह बहुत तेज़ लगेगा। यह डिस्क में फ्लश करने के लिए भी काफी एक वील लेगा, लेकिन HD से RAM तक रैम से HD तेज है तो HD से HD। (ध्यान रखें कि आपको HD से RAM को RAM से HD तक किसी भी तरह से करना है लेकिन यदि आपके पास कम है तो RAM के आपके संपूर्ण स्थानांतरण आकार को आपको सेगमेंट में "फ्लश" करना होगा।)

— coteyr

डालने का एक और तरीका यह है कि संपीड़ित करने या यहां तक कि पूरे स्रोत को भेजने के लिए राम को पढ़ना होगा। यदि यह एक बार में पूरी तरह से फिट नहीं होता है, तो इसे एक सेगमेंट को पढ़ना, भेजना, खंड को छोड़ना, तलाश करना, सेगमेंट को पढ़ना आदि शामिल है। यदि यह एक ही बार में फिट बैठता है तो इसे सिर्फ एक समय में पढ़ना होगा। गंतव्य पर समान।

— coteyr

1

HD से RAM से HD तक तेज है तो HD से HD जल्दी कैसे हो सकता है?

— AL

1

कार्यक्रम के बावजूद, मैंने आमतौर पर पाया है कि किसी नेटवर्क पर फ़ाइलों को "खींचने" से "धक्का" की तुलना में तेज है। यानी डेस्टिनेशन कंप्यूटर में लॉग इन करना और रीड करना सोर्स कंप्यूटर में लॉग इन करने और राइट करने से ज्यादा तेज है।

इसके अलावा, यदि आप एक मध्यवर्ती ड्राइव का उपयोग करने जा रहे हैं, तो इस पर विचार करें: एक बाहरी ड्राइव प्राप्त करें (या तो एक पैकेज के रूप में, या डॉकिंग स्टेशन में प्लग किया गया एक अलग ड्राइव) जो यूएसबी के बजाय ईएसएटीए का उपयोग करता है। फिर प्रत्येक दो कंप्यूटरों पर या तो एक ईएसएटीए पोर्ट के साथ एक कार्ड स्थापित करें, या एक साधारण एडाप्टर केबल प्राप्त करें जो आंतरिक एसएटीए पोर्ट में से एक बाहरी ईएसएटीए कनेक्टर में लाता है। फिर ड्राइव को स्रोत कंप्यूटर में प्लग करें, ड्राइव को पावर करें, और ऑटो-माउंट करने के लिए इसकी प्रतीक्षा करें (आप मैनऑली माउंट कर सकते हैं, लेकिन यदि आप बार-बार ऐसा कर रहे हैं तो आप इसे अपने fstab फ़ाइल में डाल सकते हैं)। फिर कॉपी; आप एक आंतरिक ड्राइव के समान गति से लिख रहे होंगे। फिर ड्राइव को अनमाउंट करें, पावर डाउन करें, दूसरे कंप्यूटर में प्लग करें, पावर अप करें, ऑटो-माउंट की प्रतीक्षा करें और पढ़ें।

— माइक सियाराल्दी
स्रोत

2

क्या आप बता सकते हैं कि आप "फाइल" कैसे खींच रहे हैं? आप किन उपयोगिताओं का उपयोग कर रहे हैं, और क्या आप इस प्रभाव को दिखाते हुए कोई नमूना प्रदान कर सकते हैं?

— एसटीडब्ल्यू

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

— माइक सियाराल्डी

यह प्रतिलिपि लिनक्स जीपी कमांड के साथ आ GUI फ़ाइल प्रबंधक, या फ़ाइलों की नकल करने के किसी अन्य तरीके से की जा सकती है। मुझे लगता है कि खींचने से काम तेजी से होता है क्योंकि लेखन पढ़ने की तुलना में धीमा होता है, और गंतव्य डिस्क पर कैसे लिखना है, इस पर अधिक निर्णय उसी कंप्यूटर पर किया जा रहा है जिससे ड्राइव जुड़ा हुआ है, इसलिए कम ओवरहेड है। लेकिन शायद यह अधिक आधुनिक प्रणालियों के मामले में नहीं है।

— माइक सियाराल्डी

1

मैं आपको एनआईसी-टीमिंग को देखने की सिफारिश करने जा रहा हूं। इसमें समानांतर में चल रहे कई नेटवर्क कनेक्शन का उपयोग करना शामिल है। यह मानते हुए कि आपको वास्तव में 1Gb से अधिक स्थानांतरण की आवश्यकता है, और यह कि 10Gb निषेधात्मक है, NIC-teaming द्वारा प्रदान किए गए 2Gbs एक मामूली लागत होगी, और आपके कंप्यूटर में पहले से ही अतिरिक्त पोर्ट हो सकते हैं।

— बायरन जोन्स
स्रोत

यदि आप LACP (लिंक एकत्रीकरण नियंत्रण प्रोटोकॉल) की बात कर रहे हैं, तो आपको गति में वृद्धि देखने को नहीं मिलेगी। यह अतिरेक प्रदान करता है और अधिक समवर्ती कनेक्शनों की सेवा करने की कुछ क्षमता है, लेकिन यह इस प्रकार के हस्तांतरण के लिए गति को बढ़ावा नहीं देगा।

— STW

@STW: एक मशीन में दो लिंक को एक 2gbit लिंक में बदलने के लिए स्विच समर्थन की आवश्यकता होती है, लेकिन यह संभव है। केवल तभी मदद मिलेगी जब दोनों मशीनों में स्विच के लिए 2gbit लिंक हो, हालाँकि। यदि आपके पास दो केबल चल रहे हैं NIC <-> NIC, जिसमें कोई स्विच नहीं है, तो यह भी काम करना चाहिए, लेकिन बहुत उपयोगी नहीं है (जब तक कि आपके पास इंटरनेट से कनेक्ट रखने के लिए एक मशीन में 3rd NIC न हो)।

— पीटर कॉर्ड्स

स्विच में इस सुविधा का कोई विशिष्ट नाम है?

— एसटीडब्ल्यू

एनआईसी-टीमिंग, ईथरचैनेल, आदि के कई रूप हैं। एसटीडब्ल्यू कुछ कॉन्फ़िगरेशन के लिए सही है, इससे मदद नहीं मिलेगी, लेकिन कुछ कॉन्फ़िगरेशन के लिए, यह होगा। यह नीचे आता है कि बंधुआ चैनल एकल आईपी सॉकेट के लिए प्रदर्शन को गति देता है या नहीं। आपको यह निर्धारित करने के लिए कि क्या यह आपके लिए एक व्यवहार्य समाधान है, आपको बारीकियों पर शोध करना होगा।

— बायरन जोन्स

802.3 एक खुला मानक है जिसे आप अपने स्विच पर देखेंगे। एक त्वरित हैक के रूप में, हालांकि, आप बस नेटवर्क में अतिरिक्त एनआईसी कनेक्ट कर सकते हैं, और उन्हें निजी पता स्थान में अलग-अलग सबनेट पर उचित आईपी पते दे सकते हैं। (होस्ट 1 पोर्ट ए एंड होस्ट 2 पोर्ट एक गेट सबनेट, होस्ट 1 पोर्ट बी और होस्ट 2 पोर्ट बी एक और सबनेट मिलता है)। फिर सिर्फ ट्रांसफर करने के लिए दो समानांतर नौकरियां चलाएं। यह Etherchannel, 802.3ad, आदि के इन्स और बहिष्कार को सीखने की तुलना में बहुत सरल होगा

— Dan Pritts

1

FWIW, मैंने हमेशा इसका उपयोग किया है:

tar -cpf - <source path> | ssh user@destserver "cd /; tar xf -"

इस पद्धति के बारे में यह है कि यह मशीनों के बीच फ़ाइल / फ़ोल्डर की अनुमति बनाए रखेगा (दोनों में समान उपयोगकर्ता / समूह मौजूद है) (इसके अलावा मैं आमतौर पर वर्चुअल डिस्क छवियों की प्रतिलिपि बनाने के लिए ऐसा करता हूं क्योंकि मैं स्पार्स फ़ाइलों को संभालने के लिए -S पैरामीटर का उपयोग कर सकता हूं। )

बस दो व्यस्त सर्वरों के बीच यह परीक्षण किया और 216s (लगभग 64 एमबी / एस) में 14GB प्रबंधित - समर्पित मशीनों और / या संपीड़न के बीच बेहतर कर सकता है ... YMMV

$ date; tar -cpf - Installers | ssh elvis "cd /home/elvis/tst; tar xf -"; date
Wed Sep  9 15:23:37 EDT 2015
Wed Sep  9 15:27:13 EDT 2015

$ du -s Installers
14211072   Installers

— ttstooge
स्रोत

1

जब तक आप फाइलसिस्टम फोरेंसिक्स नहीं करना चाहते हैं, तब तक आपके रिक्त स्थान को कॉपी करने से बचने के लिए अपने फाइल सिस्टम के लिए डंप / रीस्टोर प्रोग्राम का उपयोग करें, जो एफएस का उपयोग नहीं कर रहा है। आपके पास क्या फाइल सिस्टम है, इसके आधार पर, यह आमतौर पर सभी मेटाडेटा को संरक्षित करेगा , जिसमें शामिल है ctime। हालाँकि, फिर से फाइलसिस्टम (xfs, ext4, ufs ...) के आधार पर इनकोड संख्या बदल सकती है।

पुनर्स्थापना लक्ष्य लक्ष्य प्रणाली पर एक फ़ाइल हो सकती है।

यदि आप विभाजन तालिका के साथ एक पूर्ण डिस्क छवि चाहते हैं, तो आप ddविभाजन तालिका / बूटलोडर्स / सामान प्राप्त करने के लिए डिस्क का पहला 1M कर सकते हैं , लेकिन फिर xfsdumpविभाजन।

मैं आपकी जानकारी-डंप से यह नहीं बता सकता कि आपके पास वास्तव में किस तरह की फाइलसिस्टम है। अगर यह BSD ufs है, तो मुझे लगता है कि एक डंप / रिस्टोर प्रोग्राम है। यदि यह ZFS, अच्छी तरह से IDK है, तो कुछ हो सकता है।

आम तौर पर पूर्ण-प्रतिलिपि डिस्क आसपास की स्थिति में सुधार की स्थितियों को छोड़कर कुछ के लिए बहुत धीमी है। आप उस तरह से वृद्धिशील बैकअप नहीं कर सकते।

— पीटर कॉर्डेस
स्रोत

1

आप एक साझा संग्रहण के लिए सिस्टम सेटअप भी कर सकते हैं!

मैं विचार कर रहा हूं कि ये एक-दूसरे के बगल में हैं, और आप बार-बार ऐसा करने की संभावना रखते हैं ...।

— user133526
स्रोत

1

एक ईथरनेट क्रॉसओवर केबल के बारे में कैसे? वायरलेस गति पर निर्भर होने के बजाय आप अपने एनआईसी की वायर्ड गति पर छाया हुआ है।

यहाँ उस तरह के समाधान के कुछ उदाहरणों के साथ एक समान प्रश्न है।

जाहिरा तौर पर सिर्फ एक ठेठ ईथरनेट केबल आजकल पर्याप्त होगा। स्पष्ट रूप से बेहतर आपका एनआईसी तेजी से हस्तांतरण है।

संक्षेप में, यदि कोई नेटवर्क सेटअप आवश्यक है, तो यह केवल आपके सर्वर और बैकअप कंप्यूटर के लिए स्थैतिक आईपी सेट करने के लिए सीमित होना चाहिए जिसमें सबनेट मास्क 255.255.255.0 हो

सौभाग्य!

संपादित करें:

@ क्रिस्टोफ ने अपने जवाब में इस पर बात की

यह गति दर में सुधार कैसे करेगा? क्या आप कृपया इसे अपना उत्तर बता सकते हैं?

— AL

1

यह संभावित रूप से गति में सुधार करेगा क्योंकि आपको मध्यवर्ती नेटवर्क को धीमा करने के बारे में चिंता करने की आवश्यकता नहीं होगी। "विशिष्ट" बनाम "क्रॉसओवर" ईथरनेट केबल के बारे में - 1Gb ईथरनेट आवश्यक रूप से ऑटो-क्रॉसओवर होगा। एचपी ईथरनेट स्विच 100Mb पर ऐसा करेगा। अन्य ब्रांड, आम तौर पर नहीं, और यदि आप 100Mb पर अटक गए हैं तो आपको क्रॉसओवर की आवश्यकता होगी।

— डेन प्रिट्स

1

कई लोग सलाह देते हैं कि आप ssh को छोड़ दें क्योंकि एन्क्रिप्शन आपको धीमा कर देगा। आधुनिक सीपीयू वास्तव में 1Gb पर काफी तेज हो सकता है, लेकिन OpenSSH को इसके आंतरिक विंडोिंग कार्यान्वयन की समस्या है जो काफी धीमा हो सकता है।

यदि आप ssh के साथ ऐसा करना चाहते हैं, तो HPN SSH पर एक नज़र डालें । यह विंडोिंग की समस्याओं को हल करता है और मल्टीथ्रेडेड एन्क्रिप्शन को जोड़ता है। दुर्भाग्य से आपको क्लाइंट और सर्वर दोनों पर ssh का पुनर्निर्माण करना होगा।

— दान प्रीत
स्रोत

0

ठीक है मैंने "बहुत बड़े पाइप" (10Gbe) वाले दो कंप्यूटरों के लिए इस प्रश्न का उत्तर देने का प्रयास किया है जो एक दूसरे के "करीब" हैं।

आपके द्वारा यहां चलने वाली समस्या है: सीपीयू में सबसे अधिक संपीड़न टोंटी होगा, क्योंकि पाइप इतने बड़े होते हैं।

प्रदर्शन 10GB फ़ाइल (6 जीबी नेटवर्क कनेक्शन [लिंडोड], असंपीड़ित डेटा) को स्थानांतरित करने के लिए:

$  time bbcp 10G root@$dest_ip:/dev/null
0m16.5s 

iperf:

server: $ iperf3 -s -F /dev/null
client:
$ time iperf3 -c $dest_ip -F 10G -t 20 # -t needs to be greater than time to transfer complete file
0m13.44s
(30% cpu)

netcat (1.187 openbsd):

server: $ nc -l 1234 > /dev/null
client: $ time nc $dest_ip 1234 -q 0 < 10G 
0m13.311s
(58% cpu)

scp:

$ time /usr/local/bin/scp 10G root@$dest_ip:/dev/null
1m31.616s
scp with hpn ssh patch (scp -- hpn patch on client only, so not a good test possibly): 
1m32.707s

socat:

server:
$ socat -u TCP-LISTEN:9876,reuseaddr OPEN:/dev/null,creat,trunc
client:
$ time socat -u FILE:10G TCP:$dest_ip:9876
0m15.989s

और 10 Gbe पर दो बक्से, netcat के थोड़े पुराने संस्करण (सेंटो 6.7), 10GB फ़ाइल:

nc: 0m18.706s (100% cpu, v1.84, no -q option
iperf3: 0m10.013s (100% cpu, but can go up to at least 20Gbe with 100% cpu so not sure it matters)
socat: 0m10.293s (88% cpu, possibly maxed out)

इसलिए एक उदाहरण पर netcat ने दूसरे सोसाइटी पर कम सीपीयू का इस्तेमाल किया, इसलिए वाईएमएमवी।

Netcat के साथ, अगर इसमें "-N -q 0" विकल्प नहीं है, तो यह छोटी फ़ाइलों को स्थानांतरित कर सकती है, सावधान रहें ... "-w 10" जैसे अन्य विकल्प भी परिणामित फ़ाइलों में हो सकते हैं।

इन सभी मामलों में जो कुछ हो रहा है, वह यह है कि सीपीयू का अधिकतम इस्तेमाल किया जा रहा है, नेटवर्क का नहीं। scpलगभग 230 एमबी / एस पर अधिकतम, 100% उपयोग पर एक कोर को पेगिंग।

Iperf3 दुर्भाग्य से दूषित फाइलें बनाता है। नेटकैट के कुछ संस्करण पूरी फ़ाइल को स्थानांतरित नहीं करते हैं, बहुत ही अजीब है। विशेष रूप से इसके पुराने संस्करण।

"पाइप के रूप में गज़िप को नेटकैट" या "मबफ़र" के विभिन्न अवतारों ने भी गज़िप या मबफ़र के साथ सीपीयू को अधिकतम करने के लिए लग रहा था, इसलिए इस तरह के बड़े पाइपों के साथ तेजी से हस्तांतरण नहीं हुआ। lz4 मदद कर सकता है इसके अलावा, मैंने जो कुछ gzip पाइप सामान का प्रयास किया, उसके परिणामस्वरूप बहुत बड़ी (> 4 GB) फ़ाइलों के लिए दूषित स्थानान्तरण हो गया, इसलिए वहां से सावधान रहें :)

एक और चीज जो विशेष रूप से उच्च विलंबता (?) के लिए काम कर सकती है वह है tcp सेटिंग्स को ट्यून करना। यहाँ एक गाइड है जो सुझाए गए मूल्यों का उल्लेख करता है:

http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm और https://fasterdata.es.net/host-tuning/linux/ (दूसरे उत्तर से) संभवतः IRR सेटिंग्स: https://fasterdata.es .net / मेजबान ट्यूनिंग / 100g ट्यूनिंग /

लाइनोड से सुझाव, /etc/sysctl.conf में जोड़ें:

net.core.rmem_max = 268435456 
net.core.wmem_max = 268435456 
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.core.netdev_max_backlog = 250000
net.ipv4.tcp_no_metrics_save = 1
net.core.default_qdisc = fq

इसके अतिरिक्त, वे आपको चलाना चाहेंगे:

 /sbin/ifconfig eth0 txqueuelen 10000

यह सुनिश्चित करने के लिए कि परिवर्तन के बाद दोहरी जाँच के लायक भी नुकसान नहीं पहुंचाता है।

खिड़की के आकार को ट्यून करने लायक भी हो सकता है: https://iperf.fr/iperf-doc.php#tuningtcp

धीमी (एर) कनेक्शन के साथ संपीड़न निश्चित रूप से मदद कर सकता है। यदि आपके पास बड़े पाइप हैं, तो बहुत तेजी से संपीड़न आसानी से संपीड़ित डेटा के साथ मदद कर सकता है , यह कोशिश नहीं की है।

"हार्ड ड्राइव को सिंक करने" के लिए मानक उत्तर फाइलों को rsync करना है, जो जहां संभव हो वहां स्थानांतरण से बचता है।

एक अन्य विकल्प: "समानांतर एससीपी" (किसी तरह या अन्य) का उपयोग करें, फिर यह अधिक कोर का उपयोग करेगा ...

— rogerdpack
स्रोत

दो कंप्यूटरों के बीच भारी मात्रा में डेटा भेजने का सबसे तेज़ तरीका क्या है? [बन्द है]

Netcat के बारे में नोट्स

डिस्क छवि स्थानांतरित करना

के साथ एक tar.gz संग्रह बनाना tar

फाइल सिस्टम में तत्काल विस्तार के साथ स्थानांतरण

वैकल्पिक शैली (गंतव्य पोर्ट सुनता है)

के साथ एक tar.gz संग्रह बनाना `tar`