क्या rsync चलने के दौरान HDD का उपयोग करना सुरक्षित है?


27

मैं अपने बड़े एचडीडी का बैकअप लेने की योजना बनाता हूं rsync, और अनुमान लगाता हूं कि इसमें कुछ दिन लगते हैं। क्या rsyncकाम करते समय मूल एचडीडी (फाइलों को जोड़ना) का उपयोग करना सुरक्षित है? या HDDs rsyncको समाप्त होने तक अछूता छोड़ना बेहतर है?


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

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

जवाबों:


34

जैसा कि दूसरों ने पहले ही बताया है, स्रोत डिस्क से पढ़ना सुरक्षित है, या लक्ष्य निर्देशिका से बाहर लक्ष्य डिस्क का उपयोग करें, जबकि rsync चल रहा है। यह लक्ष्य निर्देशिका के भीतर पढ़ने के लिए भी सुरक्षित है , खासकर यदि लक्ष्य निर्देशिका rsync रन द्वारा विशेष रूप से आबादी जा रही है।

Rsync चल रहा है, जबकि स्रोत निर्देशिका के भीतर लिखने के लिए आम तौर पर सुरक्षित नहीं है। "राइट्स" कुछ भी है जो स्रोत निर्देशिका या किसी भी उपनिर्देशिका की सामग्री को संशोधित करता है, इसलिए फ़ाइल अपडेट, डिलीट, निर्माण, आदि शामिल हैं।

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

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

दूसरे रन में केवल वही अंतर होना चाहिए जो पिछले rsync रन के दौरान हुआ था, और जैसे बहुत तेजी से पूरा होगा। इस प्रकार, आप पहले रन के दौरान सामान्य रूप से कंप्यूटर का उपयोग करने के लिए स्वतंत्र महसूस कर सकते हैं, लेकिन दूसरे रन के दौरान स्रोत में कोई भी बदलाव करने से यथासंभव बचना चाहिए। यदि आप कर सकते हैं, तो दूसरी rsync चलाने की शुरुआत से पहले केवल स्रोत फ़ाइल सिस्टम को पढ़ने के लिए जोरदार तरीके से विचार करें । (कुछ ऐसा mount -o ro,remount /media/sourceकरना चाहिए)


7
एक दूसरे रन के बाद एक तीसरा रन भी कर सकता है : इसमें भी कम समय लग सकता है ... ;-)
gerlos

5
@gerlos एक पैटर्न उभर रहा है। यह लगभग ऐसा लगता है जैसे प्रत्येक उपयोग सत्र के अंत में rsync कमांड को चालू रख सकता है, और कुछ ही दिनों में इसे कुछ ही समय में किया जाएगा।
मोंटी हार्डर

5
@gerlos यदि आप दूसरी बार rsync चलाने से पहले केवल पढ़ने के लिए रिमूव करते हैं, तो यह आवश्यक नहीं होगा और बैकअप सभी के लिए होगा, लेकिन उस समय को कम करते हुए सुसंगत होने की गारंटी है, जिसके दौरान आप स्रोत फ़ाइल सिस्टम को नहीं लिख सकते।
एक सीवी

1
@gerlos एक तरफ के रूप में, यही कारण है कि मेरे पास @reboot root find / -print &>/dev/nullमेरे सिस्टम क्रॉस्टब में बहुत कुछ है जैसे कि कैश को आबाद करने के लिए। (मेरे विशेष सिस्टम पर कुछ विशेष मामलों के लिए वास्तविक प्रविष्टि अधिक जटिल है।) यह कुछ रैम और कुछ वॉलकॉक समय का उपयोग स्टार्टअप के बाद डायरेक्टरी-ट्री स्कैनिंग में सुधार करने के लिए बहुत कम आईएमई का उपयोग करता है।
बजे एक CVn

1
@ माइकलकॉर्जलिंग: पदानुक्रम को कैश करने के लिए विचार का अंतर। लेकिन हो सकता है कि आपको इसके बजाय ( updatedbपता लगाने के डेटाबेस का निर्माण) slocate -u( या , यदि आपके पास धीमापन है) चलाना चाहिए? इस तरह से आप अभी भी पदानुक्रम को कैश करते हैं, लेकिन आप कई बार फ़ाइल खोजने के लिए उन कमांड्स का उपयोग करने की अनुमति देते हैं, जो आपको खोजने या धीमा करने के डेटाबेस का निर्माण करते हैं?
ओलिवियर दुलक

22

यह आपके द्वारा उपयोग किए जाने वाले बैकअप सिस्टम पर निर्भर करता है, लेकिन सामान्य तौर पर जब आप इसे बैकअप कर रहे होते हैं तो डिवाइस की सामग्री को संशोधित करना एक बुरा विचार है । हालाँकि, आप इसकी सामग्री पढ़ सकते हैं; यह एक सुरक्षित संचालन है, भले ही यह प्रक्रिया को धीमा कर दे।

आपके मामले में, rsyncएक फ़ाइल सूची बनाएगी और फिर बैकअप शुरू करेगी। इसलिए बैकअप शुरू होने के बाद आप जो भी फाइल सोर्स HDD में जोड़ेंगे, वह कॉपी नहीं होगी ।

एक बैकअप के दौरान मैं एक उपकरण का उपयोग करने के लिए क्या नहीं करता। यह एक तेज़ और लगातार बैकअप प्राप्त करने का सुरक्षित तरीका है।


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

15

rsyncसंचालन करते समय स्रोत क्षेत्रों के डेटा को पढ़ना सुरक्षित है , लेकिन यदि आप कुछ भी कॉपी करते हैं जो rsyncबनाता है / अपडेट करता है, तो इस पर विचार किया जा सकता है:

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

  2. यदि आप एक निर्देशिका में एक फ़ाइल जोड़ते हैं जो पहले से ही स्कैन हो चुकी है तो यह इस बार गंतव्य की प्रतिलिपि से छूट जाएगा। यदि आप एक निर्देशिका से एक फ़ाइल निकालते हैं जो पहले से ही स्कैन की जा चुकी है तो इसे इस बार गंतव्य प्रतिलिपि में छोड़ दिया जाएगा। इस बात पर निर्भर करता है कि आप प्रारंभ rsyncमें पूरे पेड़ को कैसे स्कैन कर सकते हैं या सिंक प्रक्रिया के रूप में यह अचानक स्कैन किया जा सकता है।

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

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

यदि आप अपने स्टोरेज सिस्टम के भाग के लिए LVM का उपयोग करते हैं तो आप एक पॉइंट-इन-टाइम बैकअप लेने के लिए एक अस्थायी स्नैपशॉट का उपयोग कर सकते हैं। इसके लिए आवश्यक है कि आपके पास स्नैपशॉट वॉल्यूम बनाने के लिए वॉल्यूम समूह पर पर्याप्त स्थान हो, जो कि स्नैपशॉट की आवश्यकता वाले सभी परिवर्तनों को रखने के लिए पर्याप्त हो। अधिक विवरण के लिए LVM प्रलेखन (या कई ऑनलाइन उदाहरणों में से एक: "LVM स्नैपशॉट बैकअप" या इसी तरह के) की जाँच करें।

LVM के बिना भी कुछ फाइलसिस्टम स्नैपशॉट्स का समर्थन करते हैं - इसलिए आप उस विकल्प पर भी गौर कर सकते हैं।

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


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

11
  • स्रोत HDD rsync के दौरान कुछ भी पढ़ सकता है।

  • स्रोत HDD किसी भी सामग्री को rsync सामग्री से संबंधित नहीं लिख सकता है।

  • गंतव्य HDD rsync के दौरान कुछ भी पढ़ सकता है।

  • गंतव्य HDD सिंक की गई सामग्री के लिए पर्याप्त स्थान आरक्षित होने की स्थिति के साथ rsync करते समय कुछ भी लिख सकता है।

बेशक, किसी भी मामले में, प्रदर्शन में कमी होगी।


0

सभी मौजूदा उत्तर, संगति के संदर्भ में डेटा सुरक्षा के बारे में बात कर रहे हैं और सही हार्डवेयर मान रहे हैं।

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

बाद के वृद्धिशील बैकअप के लिए rsync एक बढ़िया विकल्प है और मैं अन्य उत्तरों से 100% सहमत हूँ।


1
यदि मीडिया सीमांत है या यहां तक ​​कि संभावित सीमांत है, ddतो सबसे अच्छा विकल्प नहीं है। ddrescueइसके बजाय का उपयोग करें ; यह आंशिक विफलताओं को बहुत बेहतर तरीके से संभालता है। लेकिन मूल प्रश्न में यह विचार नहीं था।
बजे एक CVn

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