55GB छवियों को नए सर्वर पर स्थानांतरित करने का सबसे तेज़ तरीका

Question

वर्तमान में मेरे पास दो CentOS सर्वर हैं। मुझे यह जानने की ज़रूरत है कि छवियों के निर्देशिका को "टार" करने का सबसे तेज़ तरीका क्या और कैसे होगा?

क्या यह सबसे तेज़ तरीका है जो मैंने अभी सुझाया है, क्योंकि टाररिंग हमेशा के लिए ले रहा है ... मैंने कमांड चलाया:

tar cvf imagesbackup.tar images

और मैं इसे खत्म करने जा रहा था।

मुझे पता है कि क्या कोई तेज़ तरीका है। मेरे पास दोनों मशीनों के लिए रिमोट / एसएसएच एक्सेस है।

Comments

Sneakernet?

— निक टी

देखें unix.stackexchange.com/questions/227951/...

— rogerdpack

Answer 1

अपने स्थानीय डिस्क पर लिखने के लिए टार का उपयोग करने के बजाय, आप ssh का उपयोग करके नेटवर्क पर दूरस्थ सर्वर पर सीधे लिख सकते हैं।

server1$ tar -zc ./path | ssh server2 "cat > ~/file.tar.gz"

कोई भी स्ट्रिंग जो आपके "ssh" कमांड का अनुसरण करती है, उसे इंटरेक्टिव लॉगऑन के बजाय रिमोट सर्वर पर चलाया जाएगा। आप SSH के माध्यम से उन दूरदराज के कमांड से इनपुट / आउटपुट को पाइप कर सकते हैं जैसे कि वे स्थानीय थे। उद्धरणों में कमांड डालने से किसी भी भ्रम से बचा जाता है, खासकर जब पुनर्निर्देशन का उपयोग किया जाता है।

या, आप दूसरे सर्वर पर सीधे टार फाइल निकाल सकते हैं:

server1$ tar -zc ./path | ssh server2 "tar -zx -C /destination"

शायद ही कभी इस्तेमाल किया -Cविकल्प पर ध्यान दें । इसका अर्थ है "कुछ भी करने से पहले इस निर्देशिका में परिवर्तन।"

या, शायद आप गंतव्य सर्वर से "पुल" करना चाहते हैं:

server2$ tar -zx -C /destination < <(ssh server2 "tar -zc -C /srcdir ./path")

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

मैं आसानी से इस प्रकार के रूप में ऊपर लिखा हो सकता है:

server2$ tar -zx -C /destination -f <(ssh server2 "tar -zc -C /srcdir ./path")

या निम्नानुसार है:

server2$ ssh server2 "tar -zc -C /srcdir ./path" | tar -zx -C /destination

या, आप अपने आप को कुछ दुख से बचा सकते हैं और बस rsync का उपयोग करें:

server1$ rsync -az ./path server2:/destination/

अंत में, याद रखें कि स्थानांतरण से पहले डेटा को संपीड़ित करने से आपकी बैंडविड्थ कम हो जाएगी, लेकिन बहुत तेज़ कनेक्शन पर, यह वास्तव में ऑपरेशन को अधिक समय ले सकता है । यदि: यह इसलिए है क्योंकि आपके कंप्यूटर काफी तेजी से ऊपर रखने के लिए संपीड़ित करने के लिए सक्षम नहीं हो सकता है संपीड़ित 100 एमबी लेता है लंबे समय तक की तुलना में यह करने के लिए ले जाएगा भेज 100 एमबी, तो यह तेज है यह असम्पीडित भेजने के लिए।

वैकल्पिक रूप से, आप अपने आप को gzip करने के लिए पाइपिंग पर विचार कर सकते हैं (बजाय -z विकल्प का उपयोग करके) ताकि आप एक संपीड़न स्तर निर्दिष्ट कर सकें। यह मेरा अनुभव है कि कंप्रेसिबल डेटा के साथ फास्ट नेटवर्क कनेक्शन पर, स्तर 2 या 3 पर गज़िप का उपयोग करना (डिफ़ॉल्ट 6 है) ज्यादातर मामलों में सबसे अच्छा समग्र थ्रूपुट देता है। इस तरह:

server1$ tar -c ./path | gzip -2 | ssh server2 "cat > ~/file.tar.gz"

Comments

Rsync ने खूबसूरती से काम किया - मक्खी पर संपीड़ित करता है, पूरे फ़ोल्डरों को कॉपी करता है, टूटी लिंक पर फिर से शुरू होता है। सभी एक साधारण आदेश में। इसे प्यार करना। ये वो विकल्प हैं जो मुझे उपयोगी लगे: z: compress r: recurse = copy subfolder v: verbose। मेरा रुपी आदेश उदाहरण: rsync -azvr / src-path / username @ dest_server: / dest / path /

— Bastion

Answer 2

मैं इसे अपने ऊपर rsync करने के लिए ललचाऊंगा - यह कम्प्रेशन करता है और लिंक लॉस को अच्छी तरह से हैंडल करता है।

Comments

rsync बिल्कुल सही उपकरण है।

— रिच

+1 - या rsync!

— इवान एंडरसन

+1, बस ढेर करने के लिए। साथ ही, मुझे वास्तव में rsync पसंद है।

— स्टीवन सोमवार

लेकिन rsync का उपयोग करते समय आपको डेटा को वैसे भी मैन्युअल रूप से संपीड़ित करना होगा (यदि आप अपने डेटा को संपीड़ित करना चाहते हैं)

— wlk

आप rsync के साथ संपीड़ित फ़ाइल को कैसे संग्रहीत कर सकते हैं?

— डोलन एंटेनुची

Answer 3

यदि आप बस उन्हें टारगेट करते हैं और कुछ नहीं तो यह केवल न्यूनतम गति प्राप्त करने के साथ टन बर्बाद करेगा।

तो बस cvf स्विच के साथ फ़ाइलों को टारगेट करने से प्रभावी रूप से उस समय का खर्च आएगा जिसमें सभी 55GB छवियों को पढ़ने और डिस्क पर वापस लिखने के लिए समय लगता है। (प्रभावी रूप से यह और भी अधिक समय व्यर्थ होगा क्योंकि वहाँ काफी उपरि होगी)।

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

तार पर एक विशाल टार आर्किव को स्थानांतरित करने से सबसे बड़ा नुकसान यह है कि अगर कुछ गलत होता है तो इसका मतलब हो सकता है कि आपको शुरू करना होगा।

मैं इस तरह से उपयोग करेगा:

md5sum /images/* > md5sum.txt
scp -r images/* user@host:/images/

नए सर्वर पर

md5sum /images/* > md5sum_new.txt

और फिर बस diff। और चूंकि एससीपी मक्खी पर संपीड़न का समर्थन करता है इसलिए अलग अभिलेखागार की कोई आवश्यकता नहीं है।

संपादित करें

मैं MD5 जानकारी रखता हूँ क्योंकि यह ओपी के लिए उपयोगी था। लेकिन एक टिप्पणी ने मुझे नई अंतर्दृष्टि के साथ मारा। इसलिए थोड़ी खोज ने इस उपयोगी जानकारी को प्रदान किया। कृपया ध्यान दें कि यहाँ विषय एसएफटीपी नहीं है जो सीधे एससीपी नहीं है ।

एफ़टीपी के विपरीत, एसएफटीपी फाइलों के हस्तांतरण में ओवरहेड को जोड़ता है। जैसे ही क्लाइंट और सर्वर के बीच फाइल ट्रांसफर होती है, इसे "पैकेट" नाम के छोटे विखंडू में तोड़ दिया जाता है। उदाहरण के लिए, मान लें कि प्रत्येक पैकेट 32KB है। SFTP प्रोटोकॉल प्रत्येक 32KB फ़ाइल पर एक चेकसम करता है जैसा कि इसे भेजा गया है, और उस पैकेट के साथ उस चेकसम को भी शामिल करता है। रिसीवर उस पैकेट को प्राप्त करता है और डेटा को डिक्रिप्ट करता है, और फिर चेकसम को सत्यापित करता है। चेकसम खुद CRC32 चेकसम की तुलना में "मजबूत" है। (क्योंकि SFTP 128-बिट या उच्चतर चेकसम का उपयोग करता है, जैसे MD5 या SHA, और क्योंकि यह प्रत्येक पैकेट पर किया जाता है, एक बहुत बारीक अखंडता जाँच है जो हस्तांतरण के भाग के रूप में पूरी होती है।) इस प्रकार, प्रोटोकॉल। अपने आप में धीमी है (अतिरिक्त उपरि की वजह से), लेकिन एक हस्तांतरण का सफल समापन का मतलब है, वास्तव में,

Comments

बहुत बहुत धन्यवाद, md5sum क्या कर रहा है? और क्या अंतर है? धन्यवाद, अब प्रदर्शन!

— एंड्रयू फैशन 12

md5sum (या md5) फाइलों का एक चेकसम लेता है। डिफ को फाइलों में अंतर के लिए लगता है (आदमी अलग है)। चेकसम एक स्ट्रिंग, एक हैश बनाता है, कि अगर फ़ाइल को ट्रांज़िट में बदल दिया गया है ... थोड़ा फ़्लिप किया गया, एक त्रुटि ... जब आप इसे दूसरी तरफ फिर से ले जाएंगे तो मेल नहीं खाएगा। बड़ी फ़ाइलों के लिए आपके पास त्रुटियों का एक बढ़ा मौका है। इसीलिए जब आप ऐसी साइटों को देखते हैं जो आपको डाउनलोड करने देती हैं। तो आपके पास अक्सर यह सुनिश्चित करने के लिए आपकी डाउनलोड की गई फ़ाइल की तुलना करने के लिए एमडी 5 चेकसम होता है कि यह मेल खाता है और भ्रष्ट नहीं है।

— बार्ट सिल्वरस्ट्रिम

scp एन्क्रिप्टेड है और लाइन पर अखंडता की गारंटी देता है। अभी भी थोड़ा सा मौका है कि डेटा स्मृति में या निश्चित रूप से डिस्क पर भ्रष्ट था, लेकिन यह बहुत दुर्लभ है।

— रयान बैर

क्या SFTP चेकसम का ओवरहेड वास्तव में किसी भी व्यावहारिक अर्थ में मायने रखता है? मैं ऐसा सोच भी नहीं सकता। प्रत्येक 32768 के लिए 4 बाइट्स महत्वपूर्ण नहीं है। यह 128 केबी प्रति जीबी है। यह कहते हुए कि "धीमी" एक उबाऊ सैद्धांतिक अर्थ को छोड़कर किसी भी चीज में एक अतिरंजना की तरह लगता है।

— अंडरस्कोर_ड

Answer 4

Pacey के md5sum सुझाव के शीर्ष पर, मैं निम्नलिखित प्रयोग करूँगा:

गंतव्य पर: nc -w5 -l -p 4567 | tar -xvf -

फिर स्रोत पर: tar -cvf - /path/to/source/ | nc -w5 destinationserver 4567

यह अभी भी एक टार / अनटार है, और कोई एन्क्रिप्शन नहीं है, लेकिन यह दूसरे सर्वर के लिए प्रत्यक्ष है। उन दोनों को अग्रानुक्रम में शुरू करें ( -w5आपको 5 सेकंड का अनुग्रह देता है।) और इसे चलते हुए देखें। यदि बैंडविड्थ तंग है, दोनों छोर पर टार में -z जोड़ें।

Comments

मुझे लगता है कि यह पहला तरीका है कि पहले उसे गंतव्य पर (सॉकेट खोलने के लिए) और फिर स्रोत पर (डिस्पैच करने के लिए)

— चलना है

गंतव्य सर्वर के स्थान पर, क्या मैं बस root@1.1.1.1 डालूं?

— एंड्रयू फैशन

नहींं, बस आईपी। netcat TCP के अलावा किसी प्रोटोकॉल का उपयोग नहीं कर रहा है :) यह कमांड ऊपर दी गई सभी कमांड का सबसे तेज भी होगा। स्रोत पर प्रति फ़ाइल बिल्कुल पढ़ा जाता है, फ़ाइलों को स्थानांतरित करने के लिए सटीक न्यूनतम नेटवर्क ट्रैफ़िक, और गंतव्य पर प्रति फ़ाइल एक बिल्कुल लिखना। यदि आपके पास सीपीयू साइकल है, तो -z फ्लैग (कम्प्रेशन के लिए) को जोड़ने से इसमें और तेजी आएगी, क्योंकि कम नेटवर्क डेटा ट्रांसफर करना पड़ता है।

— जेफ मैकजंकिन

@ user36845 - सच। मैं ऊपर दिए गए आदेश के साथ एक कालानुक्रम का अर्थ नहीं लगा रहा था, लेकिन आप सही हैं, सॉकेट को पहले खोलने की आवश्यकता होगी। मैं इसे स्पष्ट करने के लिए संपादित करूँगा। :)

— 18

मैं अनिश्चित हूं कि ssh / scp 125MB / s से 133MB / s पर कैपिंग क्यों कर रहा था, लेकिन netcat उस डेटा को ~ 380MB / s आसानी से (उसी लिंक) पर पाइप कर सकता है

— ThorSummoner

Answer 5

एक बिंदु - सभी मेजबानों में rsync नहीं है और हो सकता है कि मेजबान के पास टार के विभिन्न संस्करण हों। इस कारण से, कोई भी पहले-उपेक्षित cpio का उपयोग करके कॉल के पहले पोर्ट के रूप में सिफारिश कर सकता है।

आप मेजबान के बीच फ़ाइल / निर्देशिका संरचनाओं की तदर्थ प्रतिकृति करने के लिए ssh पर cpio कर सकते हैं। इस तरह से आपके पास बेहतर नियंत्रण है जो देखने के लिए भेजा जाता है क्योंकि आपको "फीड" cpio, नॉम-नॉम की आवश्यकता होती है। यह अधिक तर्क-पोर्टेबल भी है, cpio बहुत कुछ नहीं बदलता है - यह एक महत्वपूर्ण बिंदु है यदि आप एक विषम वातावरण में कई मेजबानों की देखरेख कर रहे हैं।

उदाहरण की प्रतिलिपि / निर्यात / घर और दूरस्थ मेजबान के लिए उपखंड:

cd /export/ find . home -print | cpio -oaV | ssh 10.10.10.10 'cd /export/home; cpio -imVd'

उपर्युक्त दूरस्थ मेजबान पर / निर्यात / घर और किसी भी सबदिर्स की सामग्री / निर्यात / घर की नकल करेगा।

उम्मीद है की यह मदद करेगा।

Comments

उन्होंने उल्लेख किया कि यह दो CentOS बॉक्स थे, इसलिए उनके पास rsync होगा और टार के संगत संस्करणों को फ़ाइल करेगा। Rsync जैसे उपकरण cpio :) जैसे टूल को बदलने के लिए बनाए गए थे। आप cpio के साथ "फिर से शुरू" नहीं कर सकते हैं, कम से कम यह जाने बिना कि आप कहां से शुरू करना चाहते हैं और अपने खोज को उपयुक्त रूप से फ़िल्टर करें। जो एक अनावश्यक समय ओवरहेड है। कहा जा रहा है कि, 'पुराने' UNIX बॉक्स के लिए उपयोगी जानकारी :)

— रफीक मनियर

हाँ, उस cammand ने मुझे खो दिया है

— एंड्रयू फैशन

Answer 6

मेरे पास आपकी पहुंच है, आपके पास rsync पहुंच है।

rsync -av -e ssh /storage/images/ user@[ip or domain name]:/storage/images/

या

rsync -av -e "ssh -l user" /storage/images/ [ip or domain name]:/storage/images/

यदि आपको "rsync त्रुटि" जैसी कोई त्रुटि प्राप्त होती है: कुछ फ़ाइलों को main.c (977) [प्रेषक = 2.6.9] पर स्थानांतरित नहीं किया जा सकता (कोड 23), अपने उपयोगकर्ता और समूहों को सर्वर के बीच जांचें; तुम एक बेमेल हो सकता है।

यदि आप rsync स्थानांतरण को संपीड़ित करना चाहते हैं, तो rsync "-z" विकल्प का उपयोग करें। यह विकल्प अधिक सीपीयू लेकिन कम बैंडविड्थ का उपयोग करेगा, इसलिए इससे अवगत रहें।

एक "--प्रोग्रेस" विकल्प है जो आपको एक प्रतिशत हस्तांतरित कर देगा, जो उस तरह की चीज को पसंद करने पर अच्छा है।

Answer 7

क्या वे फ़ाइलों को स्थानांतरित करने के लिए इंटरनेट की आवश्यकता के बजाय एक साझा नेटवर्क पर हैं? NFS या FTP SCP के ओवरहेड की तुलना में बहुत तेज हो सकता है, हालांकि आप स्थानांतरण के दौरान एन्क्रिप्शन खो देंगे।

Comments

दूरस्थ स्थानों में अलग-अलग सर्वर

— एंड्रयू फैशन

Answer 8

या आप हमेशा टार पाइप का उपयोग कर सकते हैं:

(cd /path && tar -cjf - * ) | ssh user@host 'tar -xjf - -C /path'

'j' = bzip2, यदि आप अपना टार सपोर्ट करते हैं तो आप gzip या --lzma के लिए 'z' का उपयोग कर सकते हैं।