Restic: अपूर्ण स्नैपशॉट से डेटा।

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

ईमानदार सवाल: आपके लिए डेटा कितना महत्वपूर्ण है? मैं आज आपके लिए कुछ एक साथ हैक करने के लिए कुछ समय बिता सकता हूं, जो आपको लगभग सभी डेटा तक पहुंच प्रदान करना चाहिए जो कि रेपो पर अपलोड किया गया है, लेकिन यह कोड के अधिकांश के रूप में "उत्पादन के लिए तैयार" नहीं है। :)

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

ठीक है, मैं देखूंगा कि मैं क्या कर सकता हूं।

बहुत बहुत धन्यवाद।

आप restic rebuild-index चलाकर शुरू कर सकते हैं, इसलिए हमारे पास रेपो में सभी पैकों को कवर करने वाला एक ताज़ा सूचकांक है।

जो अब शुरू हो रहा है।

वाह, यह आप @ fd0 के सुपर उदार है।

अगर मैं इससे संबंधित किसी भी चीज़ का परीक्षण करने में मदद कर सकता हूं, तो मुझे बताएं।

क्या restic rebuild-index मुझे रेपो पासवर्ड के लिए पूछना चाहिए? यह अभी तक नहीं हुआ है। मुझे संदेह है कि रेपो में डेटा की मात्रा के कारण इसमें काफी लंबा समय लग सकता है। यदि आवश्यक हो तो मैं इसे सभी सप्ताहांत या अगले सप्ताह तक चलाने के लिए पूरी तरह से संतुष्ट हूं। मैं सिर्फ यह सुनिश्चित करना चाहता हूं कि इसे लंबे समय तक अनअटेंडेड छोड़ने से पहले इसे मुझसे पासवर्ड की आवश्यकता न हो।

हम्म, यह जल्दी से एक पासवर्ड के लिए पूछना चाहिए। यह रेपो में सभी फाइलों के सभी हेडर को डिक्रिप्ट करने की आवश्यकता है। क्या आपके पास शायद पर्यावरण चर RESTIC_PASSWORD निर्यात किया गया है, इसलिए इसे आपसे पासवर्ड की आवश्यकता नहीं है?

इसे कुछ इस तरह से जल्दी प्रिंट करना चाहिए:

repository ed6136ad opened successfully, password is correct

कम से कम जब अंतःक्रियात्मक रूप से चलाते हैं (किसी लॉग फ़ाइल में stdout का पुनर्निर्देशन नहीं)।

यदि आप अपलोड किए गए डेटा के अंतिम 15 मिनट उस महत्वपूर्ण नहीं हैं, तो हम rebuild-index को भी छोड़ सकते हैं, हम हमेशा बाद में ऐसा कर सकते हैं।

मेरे पास ऐसा नहीं है कि RESTIC_PASSWORD पर्यावरण चर सेट है, लेकिन मैं इसे सेट कर दूंगा और बस कमांड को चलने दूंगा। यह लगभग 10 मिनट तक कुछ भी नहीं लौटा, इसलिए मैंने इसे ctrl-c और फिर से कोशिश की। मेरा वाक्यविन्यास सही है, है ना? restic -r b2:MY_BUCKET_NAME:/ rebuild-index किसी भी मामले में, कुल अपलोड किए गए डेटा की तुलना में अंतिम 15 मिनट का डेटा बहुत छोटा होना चाहिए, इसलिए मुझे बाद में वापस आने पर पूरी तरह से खुशी होगी।

ठीक है, फिर rebuild-index अभी तक नहीं चला है, इसलिए हम पुनर्प्राप्ति कोड आज़मा सकते हैं :)

मैंने शाखा के लिए एक प्रतिबद्ध किया है recover-data , बस आराम का निर्माण ( go run build.go ) और इसे इस तरह से कॉल करें:

$ restic -r b2:MY_BUCKET_NAME:/ recover

इसके बाद रेपो में सभी पेड़ों को सूचीबद्ध करना चाहिए, मूल पेड़ों को खोजना चाहिए, और सभी रूट पेड़ों को संदर्भित करते हुए एक नया स्नैपशॉट बनाना चाहिए:

repository abe002d6 opened successfully, password is correct
load index files
load 543 trees
tree (543/543)
done
found 2 roots
save tree with 2 nodes
saved new snapshot 26f25bf1

फिर आपके पास एक स्नैपशॉट है (इस मामले में 26f25bf1 ), जिसे आप पुनर्स्थापित कर सकते हैं, या बस इसमें आसपास ब्राउज़ करने के लिए restic mount कर सकते हैं। आप भी इसे सूचीबद्ध कर सकते हैं:

$ restic ls -l 26f25bf1 /
repository abe002d6 opened successfully, password is correct
snapshot aac6d0ed of [/recover] filtered by [/] at 2018-08-23 22:23:56.903268714 +0200 CEST):
drwxr-xr-x     0     0      0 2018-08-23 22:23:56 /0b9e25fb
drwxr-xr-x     0     0      0 2018-08-23 22:23:56 /d0d9386a

शीर्ष-स्तरीय निर्देशिकाओं का नाम ट्री आईडी के नाम पर रखा गया है, इसलिए वे थोड़ी गूढ़ हैं, लेकिन अगले स्तर में सामान्य नाम हैं।

मुझे पता है कि अगर आपकी मदद करता है!

इसलिए, थोड़ा सा बैकग्राउंड स्टोरी जोड़ने के लिए: मैंने गितुब इश्यू पढ़ा, फिर शॉवर के लिए गया, और अपने आप से सोचा, "हम्म, ऐसा करना मुश्किल नहीं है"। पता चला, मैं सही था, और यह नहीं था। यदि यह कार्यक्षमता दूसरों के लिए सहायक है, तो हम इसे बाद में एक उचित कमांड में बदल सकते हैं, लेकिन अब मुझे आशा है कि यह आपके लिए काम करता है और आप पहले से ही B2 पर अपलोड किए गए डेटा तक पहुंच सकते हैं।

कितना डेटा था? आपने कितना वसूला?

सौभाग्य!

वाह! यह तेज़ था! आपको बहुत - बहुत धन्यवाद! मैंने अभी रेपो का क्लोन तैयार किया है और अब इसे बनाने का प्रयास करने जा रहा हूं। मैंने यह भी पता लगाया कि पुनर्निर्माण-सूचकांक क्यों काम नहीं कर रहा था। यह नेटवर्क पर एक DNS मुद्दा था जो हमारा सर्वर चालू है। मैंने तय किया है कि और Fatal: unable to create lock in backend: repository is already locked by PID 41208 मिल रहा है, तो जाहिर है कि मेरा अपलोड सब के बाद इनायत नहीं हुआ। unlock आदेश ने साफ़ कर दिया है कि वर्तमान में पुनर्निर्माण और अनुक्रमणिका चल रही है।

मैं इस पर उतना ही काम कर पाऊंगा जितना मैं आज कर सकता हूं, लेकिन मैं लगभग 15 मिनट में सप्ताहांत के लिए उत्तरी मिशिगन के लिए रवाना हो रहा हूं और मुझे नहीं लगता कि मेरा इंटरनेट एक्सेस वहां बहुत अच्छा होगा। यह मेरा पूरा ध्यान सोमवार को होगा जब मैं वापस आऊंगा और मैं आपको अधिक जानकारी दूंगा :-)

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

यदि यह कार्यक्षमता दूसरों के लिए सहायक है, तो हम इसे बाद में एक उचित आदेश में बदल सकते हैं

मैं इसके साथ किसी भी तरह से मदद करना पसंद करूंगा। यहां मेरी अपलोड स्पीड 1 एमबीपीएस है और इसलिए मेरे शुरुआती बैकअप में 3-6 महीने तक का समय लग सकता है। पूरा होने से पहले इसे पुनर्स्थापित करने का एक तरीका एक उत्कृष्ट विशेषता होगी, खासकर यदि यह बहुत मुश्किल नहीं है, जैसा कि आप कहते हैं। मुझे पता है कि मैं कैसे सेवा का हो सकता है! इस पर काम करने के लिए बहुत-बहुत धन्यवाद! : डी

साथ ही, आपका समाधान काफी शानदार है जो मुझे लगता है। सुरुचिपूर्ण और काफी सरल।

आपको फांसी पर छोड़ने के लिए क्षमा करें, लेकिन मैं सोमवार को संपर्क में रहूंगा।

इसके बारे में चिंता मत करो, मैं बस उत्सुक हूँ अगर यह काम करता है: धूप का चश्मा:

डेटा बी 2 पर सुरक्षित है और दूर नहीं जाएगा। यहां तक ​​कि recover कमांड किसी भी डेटा को नहीं बदलेगी, यह सिर्फ इसे पढ़ेगी, एक और फ़ाइल और एक स्नैपशॉट जोड़ेगी, और वह यह है।

इसलिए, आपको थोड़ी सी पृष्ठभूमि देने के लिए (हो सकता है कि मैं बाद में एक ब्लॉग पोस्ट में इसका विस्तार करूं): हुड के तहत, एक रेस्टिक रिपॉजिटरी में विभिन्न प्रकार की फाइलें होती हैं, उदाहरण के लिए snapshot और data फाइलें:

• data फ़ाइलें कम का एक समूह शामिल tree या data का वर्णन क्या फ़ाइल में और जहां वास्तव में है अंत में एक हेडर के साथ धब्बे,
• snapshot फ़ाइलों में स्नैपशॉट का वर्णन करने वाला एक छोटा JSON दस्तावेज़ होता है, जो tree संदर्भ देता है

जब किसी फ़ाइल को रेस्टिक के साथ सहेजा जाता है, तो उसे data ब्लब्स में काट दिया जाता है, जिसे संग्रहित करके एक या एक से अधिक फ़ाइलों में भंडार में सहेजा जाता है। फ़ाइल का नाम सन्दर्भों की सूची (ID) के साथ data blobs के साथ फिर एक पेड़ में सहेजा गया है। जब रेस्टिक डायरेक्टरी को संग्रहित किया जाता है, तो फाइलों की सूची ( data blobs के लिए नाम और संदर्भ) tree बूँद के रूप में एक और data फ़ाइल में सहेजी जाती है।

उप-निर्देशिकाओं के लिए, रेस्टिक ने tree बूँद के संदर्भ में उप-निर्देशिका के नाम को एक अन्य tree में सामग्री के साथ संग्रहीत किया।

restic backup रन के अंत में हमारे पास एक रूट tree जो किसी अन्य पेड़ द्वारा संदर्भित नहीं है, लेकिन सभी शीर्ष-स्तरीय पेड़ों के लिए सभी संदर्भ हैं और इसलिए (अप्रत्यक्ष रूप से) सभी फाइलों में और बैकअप में उप-डायर। अंतिम चरण के रूप में, restic एक नया snapshot फ़ाइल बनाता है जो रूट tree संदर्भ देता है।

यदि आप किसी विशेष स्नैपशॉट को भूलने के लिए restic बताते हैं, तो रूट ट्री को और अधिक संदर्भित नहीं किया जाता है। restic prune इस का पता लगाता है और पेड़ और अन्य सभी अनावश्यक tree और data बूँद निकाल देता है।

सामान्य तौर पर, एक tree केवल रिपॉजिटरी में सहेजा जाता है, जब इसमें मौजूद सभी फाइलें और उपखंड सफलतापूर्वक सहेजे गए हों। इसलिए जैसे ही tree बूँद होती है, हम यह मान सकते हैं कि यह डेटा (उपखंड सहित) भी है।

जब बैकअप के दौरान रेस्टिक का गर्भपात किया जाता है, तो रेपो में tree ब्लब्स का एक गुच्छा होगा, साथ में वे फाइलों में डेटा को संदर्भित करते हैं। तो डेटा को पुनर्प्राप्त करने के लिए, रेस्टिक को केवल निम्न कार्य करने की आवश्यकता है:

• सभी ट्री आईडी की सूची बनाएं, ध्यान दें कि किन पेड़ों को संदर्भित किया गया है (शुरू में: कोई नहीं)
• प्रत्येक पेड़ के लिए:
  
  
  
  • पेड़ लोड करें
  
  
  • पेड़ में प्रत्येक प्रविष्टि के लिए:
    
    
    
    
    
    • यदि कोई निर्देशिका है, तो वह दूसरे पेड़ का संदर्भ देती है, उस पेड़ को सूची में संदर्भित के रूप में चिह्नित करें
    
    
    
  
  

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

अंतिम चरण के रूप में, एक नया पेड़ बनाएं जो सभी रूट पेड़ों को सूचीबद्ध करता है, इसे रेपो में सहेजता है, फिर एक नया स्नैपशॉट बनाता है जो इस नए पेड़ का संदर्भ देता है।

फिर आप इस नए स्नैपशॉट का सामान्य रूप से उपयोग कर सकते हैं, निर्देशिकाओं के गूढ़ नामों को छोड़कर (जो कि हमारे द्वारा पाए गए मूल पेड़ों की छोटी पेड़ आईडी हैं)।

इसे मास्टर में विलय करने से पहले, मुझे लगता है कि हमें निम्नलिखित कार्य करना चाहिए:

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

इस पर छोटा अपडेट: मैंने पिछले गुरुवार को निकलने से पहले एक rebuild-index शुरू किया। read: connection reset by peer साथ वापस मिलने से पहले ही मेरी मृत्यु हो गई। मैंने इसे बी 2 से अधिक संख्या वाले समानांतर कनेक्शन के साथ कल फिर से शुरू किया और यह ठीक चल रहा है। अब यह केवल 5% है, लेकिन मुझे उम्मीद है कि इसमें थोड़ा समय लगेगा। B2 बकेट में लगभग 90TB है और जिन निर्देशिकाओं का मैं समर्थन कर रहा था उनमें संभवतः लगभग 110-120TB थी।

मैं ईमानदारी से बहुत प्रभावित हूं कि आराम से अपलोड के दौरान इतना स्थिर रहा। मैं आराम करने की कोशिश करने से पहले मैक के लिए क्लाउडबेरी की कोशिश की और मैं इसे इतना डेटा के साथ काम करने में सक्षम नहीं था। मैं घर पर अपने लैपटॉप का बैकअप लेने के लिए आराम का उपयोग करता हूं और मुझे यह पसंद है, इसलिए मैंने सोचा कि मैं इसके लिए एक शॉट दूंगा। चूँकि मैंने अपना आरंभिक अपलोड पूरा नहीं किया है, मुझे नहीं पता कि prune जैसी कोई चीज़ कैसे जाएगी, लेकिन मुझे आपको अपडेट रखने में खुशी होगी अगर आपको डेटा की आवश्यकता है कि डेटा बड़ी मात्रा में कैसे व्यवहार करता है । अगर मुझे एक सप्ताह के तहत साप्ताहिक बैकअप बनाए रखने के लिए आवश्यक सभी कार्यों को पूरा करने के लिए मिल सकता है, तो मुझे लगता है कि इन बैकअप को संभालने के लिए यह एक महान उम्मीदवार होगा।

कुछ समय के मैं कुछ प्रश्न पूछना चाहते हैं के लिए: चाहिए मैं इस rebuild-index पूरा होने से चलाने से पहले मैं एक कोशिश recover ? अगर मैं नहीं करूंगा तो क्या मैं कुछ भी ढीला करूंगा? मैं इस बारे में सोचता रहा हूं और मुझे लगता है कि मैं पहली बार में जितना संभव हो उतनी ही उबरना चाहूंगा, जब से संभव हो तो चीजों को इस बहुत अधिक डेटा पर चलने में समय लगेगा, लेकिन अगर इसे मारना बेहतर है, तो recover चलाएं rebuild-index बाद में, मैं ऐसा कर सकता हूं। क्या rebuild-index या recover --quiet फ्लैग स्पीड से चलेंगे जैसे backup कमांड के साथ होता है?

अच्छा ठीक है! मैं निम्नलिखित करने की सलाह दूंगा:

• rebuild-index एबोर्ट करें
• restic recover चलाएँ
• एक नज़र डालें कि नए बनाए गए स्नैपशॉट में कौन सा डेटा है

यदि आप प्रयास करना चाहते हैं, तो आप rebuild-index फिर से चला सकते हैं और रेपो से शेष मेगाबाइट डेटा को स्क्रैप कर सकते हैं। संभवतः यह कुछ सौ मेगाबाइट से कम होगा, और यह संभावना है कि यह स्नैपशॉट में शामिल किसी भी नए डेटा को प्रकट नहीं करेगा। लेकिन आप इसे आजमा सकते हैं :)

जबकि rebuild-index चल रहा है, आप रिपॉजिटरी तक नहीं पहुँच सकते।

क्या पुनर्निर्माण-इंडेक्स चल रहा होगा या - aquiet फ्लैग स्पीड चीजों के साथ ठीक हो जाएगा जैसे कि यह बैकअप कमांड के साथ करता है?

नहीं।

मैंने चीजों को रात भर चलने दिया और ऐसा प्रतीत होता है कि हार्ड ड्राइव भर गई है और विफल हो गई है:

found 755 roots Fatal: unable to save new tree to the repo: fs.TempFile: open /var/folders/tq/67qp8py137n_5nzf563qlylr0000gn/T/restic-temp-pack-913168611: no space left on device

क्या यह बताने का एक आसान तरीका है कि इस ऑपरेशन को कितना डेटा डाउनलोड करना होगा या इसे कम करने का एक तरीका डाउनलोड करना होगा?

इसके अलावा, अगर मैं इस डिस्क स्थान को मुक्त करना चाहता हूं तो यह करने का तरीका restic cache --cleanup है?

नहीं, यह केवल कैश निर्देशिकाओं को हटाता है जो 30 दिनों के लिए उपयोग नहीं किया गया है। बस कैश डायरेक्टरी को हटा दें, जो आपके होम डायरेक्टरी में कहीं होनी चाहिए।

आपने कौन सी कमांड ठीक से चलाई थी? दोनों rebuild-index और recover को मेटाडेटा कैश के अलावा हार्ड डिस्क पर अधिक डेटा नहीं सहेजना चाहिए ...

फिलहाल मेरी डेस्क पर नहीं है। लेकिन यह कुछ ऐसा था: ./restic -o b2.connections=x -r b2:mybucket:/ recover मुझे लगता है कि मेरे पास x कुछ बहुत बड़ा था। वह समस्या का हिस्सा रहा होगा। मैं -o b2.connections=x बिट के बिना इसे पुनः आरंभ कर सकता हूं। मुझे कैश डायरेक्टरी मिली और उसे हटा दिया गया।

सबसे पहले, भयानक उपकरण।
मुझे धीमे-इश कनेक्शन पर डेटा की टेराबाइट्स बैकअप करने की आवश्यकता है और बैकअप विफल होने का एक मौका है, जबकि अभी भी पूरा नहीं हुआ है। क्या एक बार में केवल कुछ फ़ाइलों का बैकअप लेने के लिए अनुशंसित तरीका है?

क्या एक बार में केवल कुछ फ़ाइलों का बैकअप लेने के लिए अनुशंसित तरीका है?

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

इस तरह के सवालों के लिए एक बेहतर जगह https://forum.restic.net पर मंच होगा, सवाल (और जवाब!) बहुत अधिक खोज योग्य हैं।

@pauletg तो, यह कैसे चला गया?

मैंने # 2056 में नए कमांड recover का प्रस्ताव दिया है।

मैंने अपनी पिछली पोस्ट के बाद से रेस्ट रिकवर के बारे में ज्यादा जानकारी नहीं दी है। अच्छी खबर यह है कि हम सर्वर को पुनर्जीवित करने में कामयाब रहे हैं और दुर्घटना में डेटा को नुकसान नहीं पहुंचा है, इसलिए मेरे पास मेरा डेटा है। इससे पहले कि यह पूरा हो सके, रिकवरी कमांड मेरी मशीन के एचडी को भरने लगता है। यह कई कारकों के कारण हो सकता है: मेरा बैकअप बहुत बड़ा था और मैं अपलोड करने के लिए बी 2 के लिए बड़ी संख्या में कनेक्शन का उपयोग कर रहा था और जिस मशीन का उपयोग मैं ठीक करने के लिए कर रहा था उस पर HD अपेक्षाकृत छोटा था। मुझे यकीन है कि यह बहुत अच्छा काम करेगा अगर मेरा बैकअप एक अधिक उचित आकार था। मुझे बताएं कि क्या कोई और जानकारी है जो आपके लिए उपयोगी होगी। मैं वास्तव में इस पर काम करने की सराहना करता हूं और मेरे लैपटॉप बैकअप के लिए यह सुविधा उपलब्ध होना वास्तव में अच्छा है।

प्रतिक्रिया के लिए धन्यवाद! यदि आपको पसंद है (और बहुत समय है), तो आप इसे --no-cache साथ पुनः प्राप्त कर सकते हैं, लेकिन इससे भी अधिक समय लगेगा। जब # 2056 विलय हो जाता है तो मैं इस मुद्दे को बंद कर दूंगा

कृपया हमें बताएँ कि क्या आपके पास अतिरिक्त प्रतिक्रिया है! :)