यह वाकई अच्छा होगा।

यह अनजाने में शामिल किए गए संवेदनशील डेटा को हटाने की भी अनुमति देगा।

यह एक बड़ी विशेषता होगी!

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

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

धन्यवाद।

मुझे लगता है कि इसके लिए कई वैध उपयोग के मामले हैं। ऐसा लगता है कि वास्तव में एक अच्छी सुविधा है। मैं शायद इसे किसी बिंदु पर स्वयं उपयोग करूंगा।

यह शायद वास्तव में कार्यान्वयन के प्रयास को नहीं बदलता है, लेकिन एक UX दृष्टिकोण से, यह पूरी तरह से नया कमांड जोड़ने के बजाय backup कमांड का विस्तार करके एक कम प्रोफ़ाइल के साथ किया जा सकता है:

restic backup [flags] FILE/DIR/SNAPSHOT [FILE/DIR/SNAPSHOT] ...

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

@dnnr देखें https://github.com/restic/restic/issues/1550#issuecomment -358536554

हालाँकि, मैं यहाँ आपका अनुसरण नहीं करता हूँ। पुराने स्नैपशॉट से डेटा हटाना निश्चित रूप से एक अलग ऑपरेशन है और इसका अपना आदेश होना चाहिए। कुछ इस तरह:

restic purge --snapshots abcd1234 deadbeef --paths /path/to/file1 /path/to/file2

और --snapshots को संभवतः सभी स्नैपशॉट (या निर्दिष्ट --tag साथ सभी स्नैपशॉट) पर काम करने के लिए all कीवर्ड स्वीकार करना चाहिए। और कमांड को संभवतः yes टाइप करके पुष्टि की आवश्यकता होनी चाहिए।

इसके लिए --patterns विकल्प होना भी अच्छा होगा, जो दिए गए पैटर्न से मेल खाने वाले रास्तों को हटा देगा।

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

ठीक है, मैंने उस चरण को छोड़ दिया जहां आप बाद में स्रोत स्नैपशॉट को हटा देंगे ( forget का उपयोग करके, फिर शायद prune ), क्योंकि मुझे लगा कि यह स्पष्ट था।

मेरी राय में, इसे इस तरह करने से मौजूदा कमांड की कार्यक्षमता के साथ ओवरलैप होने वाली एक नई कमांड जोड़ने की तुलना में कमांड को अधिक ऑर्थोगोनल सेट किया जाएगा। अभी, backup , forget और prune और वे सभी पूरी तरह से अलग चीजें करते हैं। purge जैसा कि आप इसका वर्णन करते हैं, जोड़ने से वह बदल जाता है। मेरा सुझाव नहीं है।

चूंकि हम एक फ़ाइल संचालन का प्रस्ताव कर रहे हैं, इसलिए नाम बदलने में सक्षम होना अच्छा होगा।

मैं @alphapapa से सहमत purge हो सकता है, यह एक बुरा नाम नहीं है, फिर भविष्य में इसी तरह के अन्य ऑपरेशन भी हो सकते हैं, उदाहरण के लिए @alvarolm ने पहले ही फाइलों का नाम बदलने में सक्षम होने का सुझाव दिया है।

इसी कारण से मुझे लगता है कि शायद इस मामले में rewrite कमांड जोड़ना सबसे अच्छा विकल्प है, और उस कमांड को --purge और --rename विकल्प दें, यह मानते हुए कि बाद वाला प्रासंगिक है लागू। तो अंतिम आदेश होंगे जैसे restic -r foo rewrite --purge snap1,snap2 path1 path2 ... और restic -r foo rewrite --rename snap1,snap2 pathFrom pathTo ।

उस ने कहा कि मुझे पूरी तरह से यकीन नहीं है कि नाम बदलना कुछ ऐसा है जिसे लागू करना उचित है - यह बैकअप प्रोग्राम के बारे में काफी लंबा रास्ता तय करता है। लेकिन यकीन है, क्यों नहीं।

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

@dnnr

ठीक है, मैंने उस चरण को छोड़ दिया जहां आप बाद में स्रोत स्नैपशॉट हटा देंगे (भूल जाओ, फिर शायद छँटाई का उपयोग करके), क्योंकि मुझे लगा कि यह स्पष्ट था।

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

मेरी राय में, इसे इस तरह करने से मौजूदा कमांड की कार्यक्षमता के साथ ओवरलैप होने वाली एक नई कमांड जोड़ने की तुलना में कमांड को अधिक ऑर्थोगोनल सेट किया जाएगा।

मुझे समझ नहीं आ रहा है कि आपका क्या मतलब है। मामला इसके विपरीत है। यह प्रस्तावित पर्ज/डिलीट/रीराइट कमांड backup साथ बिल्कुल भी ओवरलैप नहीं है--यह मौजूदा स्नैपशॉट से डेटा हटा देता है । यह मौजूदा आदेशों के लिए ओर्थोगोनल है।

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

दोबारा, पता नहीं आप यहां क्या सोच रहे हैं। purge बैकअप, भूलने और छाँटने से पूरी तरह से अलग है:

• backup : दिए गए पथों का एक नया स्नैपशॉट बनाता है।
• forget : मौजूदा स्नैपशॉट को हटाता है।
• prune : कचरा भूले हुए स्नैपशॉट से अप्रयुक्त बूँदें एकत्र करता है।
• purge / rewrite /जो कुछ भी: मौजूदा स्नैपशॉट से फ़ाइलें हटाता है।

आप backup कमांड को दो मोड में संचालित करने का प्रस्ताव कर रहे हैं, जिनमें से एक डेटा का बैकअप लेता है, और दूसरा डेटा हटा देता है।

@rawtaz हां, rewrite एक अच्छा सुझाव है, क्योंकि यह सचमुच मौजूदा स्नैपशॉट को फिर से लिखता है। मैं एक यूआई का सुझाव दूंगा जैसे:

restic --repo REPO rewrite --snapshots abcd1234 deadbeef --delete /path/to/file1 "*.unwanted-file-extension-glob"

मैं अल्पविराम को विभाजक के रूप में उपयोग करने के खिलाफ अनुशंसा करता हूं, क्योंकि यह स्क्रिप्ट में कमांड लाइनों को और अधिक जटिल बनाता है।

बैकअप: दिए गए पथों का एक नया स्नैपशॉट बनाता है।

खैर, एक अर्थ में, एक स्नैपशॉट की सामग्री को संशोधित करके नया स्नैपशॉट पैदा कर रही है (क्योंकि यह एक ही स्नैपशॉट से पहले के रूप में नहीं है)। git commit --amend सोचें, जो मौजूदा प्रतिबद्धता के आधार पर एक नई प्रतिबद्धता बनाता है। सादृश्य वास्तव में बहुत उपयुक्त है, क्योंकि यह टिकट गिट को फिर से शुरू करने की दिशा में तेजी से आगे बढ़ रहा है।

आप बैकअप कमांड को दो मोड में संचालित करने का प्रस्ताव कर रहे हैं, जिनमें से एक डेटा का बैकअप लेता है, और दूसरा डेटा को हटा देगा।

मैंने ऐसा नहीं कहा। यह क्यों होगा? forget और prune , जो चीजों को हटाने के लिए बिल्कुल ठीक हैं।

ठीक है, एक मायने में, स्नैपशॉट की सामग्री को संशोधित करना एक नया स्नैपशॉट बना रहा है (क्योंकि यह पहले जैसा स्नैपशॉट नहीं है)। थिंक git कमिट --amend, जो मौजूदा कमिट के आधार पर एक नई कमिट बनाता है। सादृश्य वास्तव में बहुत उपयुक्त है, क्योंकि यह टिकट गिट को फिर से शुरू करने की दिशा में तेजी से आगे बढ़ रहा है।

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

मैंने ऐसा नहीं कहा। यह क्यों होगा?

अच्छा, आपने कहा:

UX के दृष्टिकोण से, यह पूरी तरह से नया कमांड जोड़ने के बजाय बैकअप कमांड का विस्तार करके कम प्रोफ़ाइल के साथ किया जा सकता है

शायद आपको और विस्तार से समझाना चाहिए।

भूल और छँटाई है, जो चीजों को हटाने के लिए पूरी तरह से ठीक है।

आइए विशिष्ट बनें। forget स्नैपशॉट हटाता prune बूँदें हटाता है। हम स्नैपशॉट के भीतर फ़ाइलों को निकालने के लिए एक आदेश का प्रस्ताव कर रहे हैं। यह एक अलग आदेश होना चाहिए।

मैं अपनी राय जोड़ना चाहता हूं:

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

कमांड backup कमांड से स्वतंत्र होना चाहिए, न केवल ऑर्थोगोनैलिटी कारणों के लिए (जो काफी गो-लाइक है), बल्कि व्यावहारिक विचार से भी बाहर है: backup कमांड पहले से ही काफी जटिल है इसलिए मैं ' अन्य कमांड को इससे अलग करना चाहते हैं।

मैं नाम पसंद नहीं purge करने के लिए समानता की वजह से, prune । change बारे में क्या? फिर हमारे पास restic backup , restic restore और restic change ।

कमांड के समर्थित संचालन के लिए, मैंने इसके लिए अनुरोध देखे हैं:

• फ़ाइलें हटाएं, जैसे --delete
• फ़ाइलों का नाम बदलें, जैसे --rename

पूर्व वास्तव में इस मुद्दे (मूल रूप से) के बारे में है, लेकिन क्या वास्तव में फाइलों का नाम बदलने के लिए उपयोग के मामले हैं?

मुझे लगता है कि change कुछ की सामग्री को संशोधित करने के बजाय कुछ बाहर निकालने और कुछ डालने जैसा लगता है।

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

शायद कुछ मूल अंग्रेजी/अमेरिकी व्यक्ति जानता है कि कौन सा उचित है :) यह मेरे विचार से भाषाविज्ञान तक उबाल जाता है।

हम्म, modify तो?

modify निश्चित रूप से change से बेहतर है। तो या तो rewrite या modify से जो अभी तक प्रस्तावित किया गया है। उत्सुक दूसरे क्या सोचते हैं :)

अगर यह केवल फाइलों को हटाने के बारे में है, तो क्या स्नैपशॉट और फाइलों के साथ काम करने के लिए forget कमांड को बढ़ाने का कोई मतलब होगा? या यह बहुत जटिल होगा?

अगर यह नई सुविधा हटाने और नाम बदलने (या कुछ और) के बारे में है तो मैं modify लिए वोट करूंगा।

आपके इनपुट के लिए धन्यवाद @dimejo

मुझे लगता है कि जब आप नाम बदल रहे हैं और/या हटा रहे हैं, तो आप forget ting नहीं हैं (कम से कम पूर्व मामले में नहीं)।

आईएमएचओ "पुनर्लेखन" अर्थ को सबसे अच्छा बताता है।

forget कमांड भी बहुत जटिल है, अगर हम इसमें मदद कर सकते हैं तो हम इसमें कुछ भी नहीं जोड़ेंगे;)

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

वैसे, मुझे लगता है कि कमांड श्रेणियों से रेस्टिक को फायदा होगा, जैसा कि गिट के प्लंबिंग कमांड के साथ है। अभी, restic -h निम्न-स्तरीय कमांड (जैसे, cat , list , जिसे "सामान्य" उपयोगकर्ताओं द्वारा कभी भी आवश्यकता नहीं होगी) को मिलाकर, सभी आदेशों को शाब्दिक क्रम में सूचीबद्ध करता है। प्राथमिक उच्च स्तरीय आदेश।

आप update पर भी विचार कर सकते हैं।

+1 rewrite , इसमें एक अच्छी ऑरवेलियन रिंग है। :-)

alter
discard
evict
expel
expunge
extrude
oust
...
nuke ? मैं

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

कुछ समय के लिए यह कुछ इस तरह हो सकता है:

$ restic edit 40dc1520 remove dir/file

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

संपादन संदर्भ के अंतर्गत अन्य आदेश हो सकते हैं

• rename फ़ाइलों और फ़ोल्डरों का नाम बदलने के लिए
• move बदली हुई फ़ाइल/डीआईआर संरचनाओं को ठीक करने के लिए

मेरा मानना ​​है कि यह महत्वपूर्ण है कि हम इन कार्रवाइयों को एक या एक से अधिक स्नैपशॉट (आईडी या संभवतः कई तिथियों या एक सीमा द्वारा) पर निष्पादित करने की अनुमति दें।

मुझे अभी भी यकीन नहीं है कि बैक अप डेटा के साथ कितना रेस्टिक सक्षम होना चाहिए। मेरा मतलब है, यह डेटा का बैकअप लेने के लिए है ताकि यह संरक्षित किया जा सके कि एक निश्चित समय में चीजें कैसी दिखती हैं। यह NAS होने का मतलब नहीं है।

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

@rawtaz
मेरे विचार (लगभग) बिल्कुल।

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

उससे आगे के संचालन के बारे में (यानी, नाम बदलना, जोड़ना), मैं आपकी शंकाओं को साझा करता हूं। यह फीचर रेंगना है और बैकअप टूल, IMHO के दायरे में नहीं है।

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

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

दी, रिमूव-पाथ्स-से-स्नैपशॉट्स फीचर को भी इस तरह से लागू किया जा सकता है, लेकिन चूंकि इसकी आवश्यकता होने की अधिक संभावना है, इसलिए मुझे लगता है कि इसे रेस्टिक में शामिल करना उचित है।

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

मुझे नहीं लगता कि हमें यहां अधिक चर्चा की आवश्यकता है, भाग लेने के लिए धन्यवाद!

कमांड नाम के लिए सुझाव: restic purge ।

मैं इस सुविधा की प्रतीक्षा कर रहा हूं। धन्यवाद

@fd0
इस फीचर पर कोई अपडेट? इसका इस्तेमाल करना पसंद करेंगे :)
हम सरकारी परिवेश में रेस्टिक का उपयोग कर रहे हैं और उनके लिए बैकअप से एक फ़ाइल को हटाना आवश्यक है। जरूरत पड़ने पर हम कुछ काम के लिए फंड दे सकते हैं!

मैं भी इसका इंतज़ार कर रहा हूँ! मैं restic find लिए आधार संरचना की तरह कुछ का उपयोग करने का प्रस्ताव करता हूं।

restic purge [flags] PATTERN

जहां आप purge से host (-H) snapshots (-s) or paths (--path) सीमित कर सकते हैं

फिर शायद एक restic prune बाद में वास्तविक डिलीट कर देगा

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

धन्यवाद !

कोई अपडेट नहीं, क्षमा करें। कुछ होने पर आपको इस मुद्दे की सदस्यता लेने से सूचित किया जाएगा।

ऐसा लगता है कि अधिकांश लोग clone बैकअप के मेटाडेटा में सक्षम होना चाहते हैं, लेकिन आपत्तिजनक फ़ाइलों को बाहर कर दें - उन सभी को स्क्रैच स्थान पर पुनर्स्थापित किए बिना। बैकअप को क्लोन करने का विचार कुछ बिंदुओं को हटाने की क्षमता के साथ मेटाडेटा की नकल करेगा।

क्या यह उपयोग का मामला है?

• restic backup --exclude <something> --clone <original backup id> [new feature]
• restic forget <original backup id>
• restic prune

rewrite और modify उपरोक्त प्रक्रिया के लिए मैक्रो हो सकते हैं।

मेरे लिए, यह वास्तव में पर्याप्त होगा @nullcake

बहुत बुरा नहीं, @nullcake।

हालांकि, मेरे पिछले अनुभव के आधार पर, आमतौर पर मुझे पता चलता है कि मैं बेकार सामानों का बैकअप केवल दिनों या हफ्तों के बाद लेता हूं। जब मेरे पास जांच करने के लिए कुछ समय होता है। इसका मतलब यह है कि जब तक मैं समझता हूं कि मुझे कुछ विशिष्ट --बहिष्कृत करने की आवश्यकता है, तब तक शायद एक दर्जन या अधिक बैकअप प्रभावित होते हैं।

बेशक, भले ही एक बैकअप के आधार पर किसी भी तरह की सफाई लागू की गई हो, जैसा कि आप सुझाव देते हैं, यह अभी भी एक महान कदम होगा। बेशक, हम स्क्रिप्ट करना जानते हैं। ;)

तो, अंगूठे ऊपर। :)

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

क्रैशप्लान का एक दिलचस्प व्यवहार था कि जब किसी फ़ाइल को बाहर रखा जाता है, तो उसे सभी मौजूदा स्नैपशॉट से हटा दिया जाता है। यह विचार करने योग्य बात हो सकती है।

यह एक बेहतरीन फीचर होगा। क्या इसे जोड़ा गया है?

नहीं।

@fd0 क्या इस पर कोई प्रगति हुई है? मुझे अभी पता चला है कि मैं कैश को बाहर नहीं कर रहा था जैसा मैंने सोचा था और उन्हें निकालना अच्छा लगेगा।

कमांड नाम के लिए एक और सुझाव: scrub (हालांकि मैं purge साथ भी ठीक हूं, --rename झंडा मुझे अजीब लगेगा)। मेरे विचार:

restic scrub [--dry-run] [--replace=<clean|prune>] [--diff] [--all | snapshot-ID...]

जहां --replace=clean किसी भी संशोधित स्नैपशॉट को हटा देता है, prune prune बाद में --diff किसी भी संशोधित स्नैपशॉट के लिए एक अंतर दिखाता है। --dry-run रेपो में कोई भी बदलाव करने से बचता है।

इसके अलावा वैध के सभी कर रहे हैं --exclude से झंडे restic backup । मुझे लगता है कि --host और --time भी समझ में आता है (प्रत्येक पहले से मौजूद स्नैपशॉट के मानों को प्रतिस्थापित करता है); --tag संपादन पहले ही restic tag द्वारा नियंत्रित किया जा चुका है।

क्या किसी डेवलपर के पास मार्गदर्शन है कि इसे कैसे कार्यान्वित किया जा सकता है? मुझे ऐसा लगता है (सरसरी नज़र से) कि अधिकांश कोड cmd_scrub.go फ़ाइल में जा सकते हैं; हो सकता है कि आंतरिक पुस्तकालय में केवल कुछ एपीआई जोड़ आवश्यक हों क्योंकि यह मुख्य रूप से इंडेक्स ऑपरेशंस प्रतीत होता है, लेकिन शायद यह बेवकूफ है। कोई अनुमानित कठिनाई (मुझे लगता है कि परीक्षण किसी भी मामले में इसका बड़ा हिस्सा होगा)?

चूंकि यह बहुत पुराना मुद्दा है.. क्या इस सुविधा को प्राप्त करने की कोई संभावना है?

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

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

मैं लगभग एक साल से रेस्टिक का उपयोग कर रहा हूं और मैंने सुविधाओं के लागू होने की प्रतीक्षा करना बंद कर दिया है। मेरा मतलब यह नहीं है कि सब कुछ रेस्टिक में जोड़ा जाना चाहिए, लेकिन बुनियादी चीजें हैं जो वहां होनी चाहिए। मैं रेस्टिक से दूर जाने पर विचार कर रहा हूं: भंडार बहुत नाजुक है और बहुत आसानी से टूट सकता है।

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

@MorgothSauron मैं आमतौर पर केवल स्नैपशॉट को हटा

मैं इस मामले पर उनके इनपुट के लिए सभी को धन्यवाद देना चाहता हूं। जैसा कि हमने देखा है, बहुत से लोग विशेष रूप से स्नैपशॉट से फ़ाइलों को निकालने की क्षमता चाहते हैं। मुझे लगता है कि बैक अप लेते समय हम सभी एक बार गलती करते हैं;)

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

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

ऐसा पीआर बुनियादी होना चाहिए और एक शुरुआती बिंदु के रूप में कार्य करना चाहिए, जिसे यदि आवश्यक हो तो बनाया जा सकता है। इसका एक उदाहरण मेरा मतलब यह है कि यह शुरुआत के लिए होना चाहिए:

• बस एक नया आदेश बनें (उदाहरण के लिए rewrite क्योंकि यह इस मुद्दे में सबसे अधिक वोट दिया गया है)।
• स्नैपशॉट की एक सूची को इसके प्राथमिक तर्क (ओं) के रूप में लें ( all लिए समर्थन सहित), उदाहरण के लिए all या 098db9d5 या 098db9d5 af92db33 ।
• उन पथों को सूचीबद्ध करने के लिए एक या अधिक --exclude <pattern> की सूची लें जिन्हें स्नैपशॉट के रूप में बाहर/हटाया जाना चाहिए (दूसरे शब्दों में, यहां --exclude जो बैक अप के समय गायब था), उदाहरण के लिए --exclude="*.o" , --exclude=*.unwanted , --exclude="*.o" --exclude=*.unwanted --exclude=.DS_Store ।

यहां तर्क अवधारणा और न्यूनतम व्यवहार्य उत्पाद के प्रमाण के रूप में न्यूनतम शुरुआत प्राप्त करना है। एक बार परीक्षण करने के बाद हम इसे आवश्यकतानुसार समायोजित कर सकते हैं, उदाहरण के लिए backup कमांड से अन्य --exclude-* तर्क जोड़कर। यदि हम इस तरह rewrite कमांड बनाते हैं, तो इसका इंटरफ़ेस backup कमांड के समान ही होगा, जिसका अर्थ "सही" है:

~रेस्टिक -r /some/repo सभी को फिर से लिखें --exclude=" .o" --exclude= .unwanted --exclude=.DS_Storeरेस्टिक -r /some/repo फिर से लिखना 098db9d5 af92db33 --exclude=" .o" --exclude= .unwanted --exclude=.DS_Store~

संबंधित नोट पर, शायद https://github.com/restic/restic/issues/323 में @middelink द्वारा किए गए कार्य को प्रेरणा या कार्यान्वयन के आधार के रूप में इस्तेमाल किया जा सकता है, क्योंकि यह मौजूदा स्नैपशॉट की कुछ प्रोसेसिंग करता है। मैं यह देखने जा रहा हूं कि क्या हम जल्द ही इसके साथ आगे बढ़ सकते हैं।

@rawtaz

विचारशील प्रतिक्रिया के लिए धन्यवाद!

नमस्ते।

मैंने @rawtaz . द्वारा टिप्पणी के करीब ड्राफ्ट rewrite कार्यान्वयन जोड़ा है

यह यहां परीक्षण रेपो के साथ काम करता है, त्रुटियों के बिना restic check --read-data पास करता है, लेकिन इसका अधिक परीक्षण नहीं किया है। इसलिए मैं दृढ़ता से सुझाव देता हूं कि इसे महत्वपूर्ण डेटा के साथ उपयोग न करें।

मैंने सिंटैक्स को backup कमांड के बहुत करीब लाने की कोशिश की है। तो --exclude , --iexclude और --exclude-file समर्थित हैं (लेकिन परीक्षण नहीं किया गया)। आदर्श रूप से मैं --exclude-if-present विकल्प भी देखना चाहता हूं (मेरे लिए आदर्श वर्कफ़्लो 'उफ़, बैकअप की आवश्यकता नहीं है, CACHEDIR.TAG और restic rewrite ' जोड़ें)। लेकिन यह बहुत जटिल है क्योंकि ऐसे मामले में हमें उसी होस्ट पर rewrite आवश्यकता होगी जहां बैकअप बनाया गया था और इन फ़ाइलों को इकट्ठा करने के लिए फाइल सिस्टम तक पहुंच (साथ ही सापेक्ष पथ के साथ जादू के टन)। तो अभी नहीं...

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

किसी भी प्रतिक्रिया की काफी सराहना की जाएगी।

अरे दिमित्री,

इस कार्यान्वयन के लिए धन्यवाद, बहुत अच्छा काम!

अब तक यह लिनक्स पर 600 फाइलों के एक छोटे परीक्षण रेपो + कई परीक्षण स्नैपशॉट के साथ पूरी तरह से काम करता है। कार्यों को पुनर्स्थापित करें और सही ढंग से बहिष्कृत फ़ोल्डरों को अलग दिखाता है। मैं एक "क्लोन" वास्तविक रेपो पर अधिक गहन परीक्षण कर रहा हूँ जिसमें कई जीबी डेटा के साथ 100 से अधिक स्नैपशॉट हैं। मैं विंडोज़ सोर्स किए गए रेपो भी कोशिश करूंगा।

एक प्रस्ताव: स्नैपशॉट के लिए एक टैग निर्दिष्ट करने का विकल्प है जिसमें पुनर्लेखन पास पर बहिष्करण शामिल हैं। (नए बनाए गए स्नैपशॉट पर " rewrite " टैग रखते हुए।)

restic rewrite --add-tag mytag -i thisfileshouldberemoved.txt all

यह उन स्नैपशॉट की पहचान करने में मदद करेगा जिनमें अभी भी "_thisfileshouldberemoved.txt_" शामिल है। दूसरी ओर, अधिक प्रत्यक्ष --inplace अपेक्षा के अनुरूप काम करता है।

फिर से बहुत अच्छा काम।

@NovacomExperts हां, मेरी प्रारंभिक प्रेरणा 'इतिहास संपादन को यथासंभव सुरक्षित रखना' था। --exclude * साथ कुछ महत्वपूर्ण को बाहर करना बहुत आसान है और इससे उबरने का लगभग कोई तरीका नहीं है (बैकअप के साथ यह केवल नया बैकअप फिर से शुरू करने की बात है)। --dry-run जैसा कुछ लेकिन वास्तविक स्नैपशॉट प्राप्त करने की क्षमता के साथ और यह जांचने के बाद स्रोत स्नैपशॉट को स्पष्ट रूप से हटा दें कि यह ठीक है।

मैं पूरी तरह से सहमत हूं कि वर्तमान में यह पूरी तरह से हासिल नहीं हुआ है। नए स्नैपशॉट को 'निरीक्षण' करना आसान है, लेकिन पुराने को हटाना बहुत मुश्किल है। साथ ही मुझे हार्डकोडेड rewrite स्नैपशॉट नाम पसंद नहीं है। हो सकता है कि डिफ़ॉल्ट रूप से --inplace और ---keep-source-tagged before-rewrite --tag-destination after-rewrite या ऐसा कुछ होना बेहतर हो। ( --add-tag थोड़ा अस्पष्ट है, चाहे वह पुराना हो या नया स्नैपशॉट)।

किसी भी मामले में मैं अनुरक्षकों से प्रतिक्रिया की प्रतीक्षा करूंगा। अगर यह गलत दिशा में बढ़ रहा है तो ज्यादा समय बर्बाद नहीं करना चाहता।

पुनश्च. मेरा प्राथमिक रेस्टिक रेपो अब लगभग ~ 2TB है। LVM स्नैपशॉट बनाने के बाद बाद में इस पर प्रयास करेंगे।

@dionorgua आपकी प्रारंभिक प्रेरणा पूरी तरह से सही है। मैं इसे "खतरनाक" विकल्प --inplace साथ उपयोगकर्ता से यथासंभव दूर रखने के लिए अपना वोट डालूंगा (निश्चित रूप से डिफ़ॉल्ट रूप से नहीं)। मैं पर एक लापता तर्क त्रुटि पसंद करेंगे --keep-source-tagged / --tag-destination से --inplace डिफ़ॉल्ट रूप से।

लेकिन मैं सहमत हूं, आइए इस पर प्रतिक्रिया की प्रतीक्षा करें।

कल, मैं क्लोन परीक्षण रेपो (65 जीबी) को एक फ़ोल्डर के अंदर भूल गया था जिसे रात भर रेस्टिक द्वारा बैकअप किया गया था। मेरे पास कल का स्नैपशॉट forget हो सकता था लेकिन "ऑल इन" गया और आपके कार्यान्वयन की कोशिश की। forget + prune , मैंने 400GB रेपो से 65GB को सफलतापूर्वक हटा दिया। सब ठीक है, कोई त्रुटि नहीं मिली।

मैं डेटा के साथ अधिक गहन परीक्षण करता हूं जो कई स्नैपशॉट में फैला होता है।

चियर्स

मैंने उस गलत #2720 पुल अनुरोध को नए के साथ बदल दिया है क्योंकि पुराना मास्टर शाखा से बनाया गया था। बस एक लापता त्रुटि जांच जोड़ा गया। अतिरिक्त शोर के लिए क्षमा करें

हम्म, modify तो?

इसके लिए बहुत देर हो चुकी है, लेकिन _rectify_ डिलीट-स्पेसिफिक-फाइल-फ्रॉम-बैकअप कमांड के लिए मेरा सुझाव है।

2731 रोमांचक है, बहुत बहुत धन्यवाद!

इसके लिए बहुत देर हो चुकी है, लेकिन डिलीट-स्पेसिफिक-फाइल-फ्रॉम-बैकअप कमांड के लिए रेक्टिफाई मेरा सुझाव है।

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