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

दिलचस्प बिंदु, धन्यवाद। मुझे अभी तक यकीन नहीं है कि बेहतर क्या है इसका न्याय कैसे करें। रिमोट बैकएंड के लिए हम तब भी (बैकएंड इंटरफ़ेस में कुछ बदलावों के बाद) बस io.Reader पास कर सकते हैं और फिर शायद stdlib फ़ाइल को सीधे डिस्क से स्ट्रीम करने के लिए sendfile का उपयोग कर सकता है। एचएम

बस FYI करें मैं सोच रहा हूं कि आप GCM का उपयोग क्यों नहीं करते हैं, इसलिए मैंने बेंचमार्क चलाया। एईएस-सीटीआर + पॉली1305 बहुत तेज है यदि सीपीयू में एईएस-एनआई नहीं है (गो बिल्ट-इन जीसीएम से 50% तेज)। एईएस-एनआई के साथ, जीसीएम के लिए गो का अनुकूलित असेंबली कोड शायद अपराजेय है।

इंटेल Xeon E312xx

restic:
BenchmarkEncrypt-4        50      32470322 ns/op     258.35 MB/s

stupidgcm:
Benchmark4kEncStupidGCM-4     200000         10620 ns/op     385.67 MB/s
Benchmark4kEncGoGCM-4         300000          5540 ns/op     739.22 MB/s

इंटेल पेंटियम G630 (कोई AES-NI नहीं)

restic:
BenchmarkEncrypt-2            10     108468078 ns/op      77.34 MB/s

stupidgcm:
Benchmark4kEncStupidGCM-2          50000         24182 ns/op     169.38 MB/s
Benchmark4kEncGoGCM-2              20000         96391 ns/op      42.49 MB/s

यह इस मुद्दे से संबंधित नहीं है, लेकिन मैं वैसे भी उत्तर दूंगा:

मुझे लगता है कि जिस समय मैंने रेस्टिक शुरू किया था, उस समय गो के पास जीसीएम का अनुकूलित संस्करण नहीं था। इसके अलावा, मैंने GCM का उपयोग करने में सहज महसूस नहीं किया क्योंकि मुझे यह समझ में नहीं आया, जबकि Poly1305 पेपर पढ़ने और समझने में बहुत आसान था।

मुझे लगता है कि आपका बेंचमार्क डेटा के बहुत छोटे ब्लॉब्स को संसाधित करता है, हो सकता है कि जब ब्लॉब्स बड़े हों तो यह करीब हो जाएगा।

समझा। हाँ अनुकूलित GCM हाल ही में है, मुझे लगता है कि Cloudflare ने इसे Go 1.5 के लिए दान कर दिया है।

ब्लॉक आकार के संबंध में, रेस्टिक बेंचमार्क 8 एमआईबी का उपयोग करता है जबकि बेवकूफजीसीएम 4kiB का उपयोग करता है । मैंने बेवकूफी के लिए 8 एमआईबी ब्लॉक आकार के साथ पुनः प्रयास किया लेकिन परिणाम लगभग समान हैं।

तो चलिए इस पर समय बर्बाद नहीं करते, मुझे लगता है कि CTR+Poly1305 काफी तेज है।

क्या इंडेक्स फ़ाइल या पैक फ़ुटर में असम्पीडित आकार होना ज़रूरी है? मुझे लगता है कि इसे केवल ब्लॉब के भीतर जानना ठीक होगा, फिर, रेस्टिक में कम बदलावों की आवश्यकता होती है। क्या यह इस अतिरिक्त स्थान पर किसी नई विशेषता को जानने में सक्षम बनाता है?

मेरी राय में, रिपोजिटरी प्रारूप 2 == ब्लॉब डेटा का पहला बाइट संपीड़न प्रारूप इंगित करता है, बस इसकी आवश्यकता है। शायद 255 संभावित प्रारूपों में से एक {64-बिट असम्पीडित लंबाई} {संपीड़ित डेटा} हो सकता है।

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

क्या इंडेक्स फ़ाइल या पैक फ़ुटर में असम्पीडित आकार होना ज़रूरी है?

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

मेरी राय में, रिपोजिटरी प्रारूप 2 == ब्लॉब डेटा का पहला बाइट संपीड़न प्रारूप इंगित करता है, बस इसकी आवश्यकता है। शायद 255 संभावित प्रारूपों में से एक {64-बिट असम्पीडित लंबाई} {संपीड़ित डेटा} हो सकता है।

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

मुझे लगता है कि बैकअप के लिए त्रुटि सुधार एक अच्छा विचार है। लेकिन मुझे लगता है कि यह फाइल सिस्टम की जिम्मेदारी है।

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

रीड-सोलोमन कोड के लिए, कुछ प्रदर्शन डेटा के साथ https://github.com/klauspost/reedsolomon पर एक शुद्ध गो कार्यान्वयन है।

https://www.usenix.org/legacy/event/fast09/tech/full_papers/plank/plank_html/ के अनुसार ZFEC तेज होना चाहिए। एक कार्यान्वयन https://gitlab.com/zfec/go-zfec में है जो https://pypi.python.org/pypi/zfec पर आधारित प्रतीत होता है ।

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

यूज़नेट बाइनरी समूहों में वे अलग फाइलों का उपयोग करते हैं (देखें https://en.wikipedia.org/wiki/Parchive) जिसमें ईसीसी जानकारी होती है। यह रिपोजिटरी लेआउट में सिर्फ एक और उपनिर्देशिका जोड़ देगा और रेपो प्रबंधन जानकारी (कॉन्फ़िगरेशन, इंडेक्स, ...) में ईसीसी लागू करना भी आसान होगा। लेकिन मुझे यकीन नहीं है कि ऐसा करने से ईसीसी स्कीमा कमजोर हो जाएगा (शायद ईसीसी जानकारी के भीतर क्लस्टर त्रुटियों के खिलाफ मजबूती कम हो जाती है)।

संकेतों के लिए धन्यवाद। मुझे पेपर का पीडीएफ संस्करण यहां मिला है: https://www.usenix.org/legacy/event/fast09/tech/full_papers/plank/plank.pdf

ZFEC Go कार्यान्वयन C लाइब्रेरी के चारों ओर केवल एक आवरण है।

ZFEC के लिए [https://github.com/korvus81/jfec] पर jfec नाम के अतिरिक्त (गोरआउट्स का उपयोग) के साथ एक गो पोर्ट है।

मैंने नए रिपॉजिटरी प्रारूप को लागू करने के लिए एक "प्रोजेक्ट" (गिटहब के लिए हाल ही में जोड़ा) जोड़ा है: https://github.com/restic/restic/projects/3

कुछ विचार जिन्हें पीछे की संगतता को तोड़ते समय देखा जा सकता है:

• sha256 से sha512 . में बदलें

क्या sha256 के बजाय sha512 (या sha512/256) का उपयोग करने से बैकअप गति में वृद्धि होगी? जहां तक ​​​​मैं देख सकता हूं यह एआरएम को छोड़कर अधिकांश प्लेटफॉर्म के लिए सच है।

समकालिक चर्चा (https://github.com/syncthing/syncthing/issues/582)

बोर्ग चर्चा (https://github.com/jborg/attic/issues/209)

sha512/256 पर पेपर (https://eprint.iacr.org/2010/548.pdf)

• एक साधारण पासवर्ड के बजाय सार्वजनिक कुंजी एन्क्रिप्शन का उपयोग करना

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

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

NaCl - https://godoc.org/golang.org/x/crypto/nacl/box

• रिपोजिटरी पहचान

वर्तमान में यह जानने का कोई तरीका नहीं है कि जब आप रिपोजिटरी पर ठोकर खाते हैं तो आप एक रेस्टिक रिपोजिटरी को देख रहे हैं। वर्तमान में हम प्रमुख फाइलों में "created":"TIMESTAMP","username":"XXXXX","hostname":"XXXXX" लीक कर रहे हैं। मैं इस जानकारी को छिपाने का सुझाव दूंगा, और इसके बजाय रेस्टिक के बारे में कुछ जानकारी शामिल करूंगा, जैसे restic repository version X । README जितना आसान हो सकता है।

पिछली चर्चाओं के संबंध में; मैं किसी प्रकार की त्रुटि-सुधार को लागू करने के पक्ष में हूं।

@oysols आपको विचार जोड़ने के लिए धन्यवाद!

मैं नीचे अपने विचार जोड़ूंगा:

sha256 से sha512 में बदलें (गति के लिए)

फिलहाल, मुझे गति से कोई सरोकार नहीं है (रेस्टिक पहले से ही वास्तव में तेज़ है), इसलिए कम से कम मेरे लिए यह आइटम कम प्राथमिकता का है। सिम-सक्षम प्रोसेसर के लिए SHA256 का एक अनुकूलित संस्करण भी मौजूद है जिसे हम आसानी से स्विच कर सकते हैं। दूसरी ओर, जब हम रेस्टिक को गति देने का निर्णय लेते हैं और हैश पर चर्चा की जानी है, तो मैं शायद केकक (SHA3) या ब्लेक 2 को पसंद करूंगा, वे हैं (जहाँ तक मुझे पता है, मैंने अभी तक कोई बेंचमार्क नहीं किया है) बहुत तेजी से।

अतः मेरे विचार से यह विषय अभी के लिए स्थगित किया जाता है।

एक साधारण पासवर्ड के बजाय सार्वजनिक कुंजी एन्क्रिप्शन का उपयोग करना

इस सुविधा की योजना बनाई गई है (देखें #187), लेकिन यह जटिल है और इसके लिए बहुत सोच-विचार और कई बड़े बुनियादी ढांचे में बदलाव की आवश्यकता है। मैं इसे स्थगित करना चाहता हूं और इसके बजाय छोटे वृद्धिशील अपडेट करना चाहता हूं जहां हम सब कुछ बदलते हैं -> स्थगित।

रिपोजिटरी पहचान (रिपॉजिटरी में एक README फ़ाइल जोड़ें)

बहुत अच्छी बात, हम इसे अब बिना कुछ तोड़े भी जोड़ सकते हैं।

रिपोजिटरी "सूचना रिसाव" (उपयोगकर्ता नाम, होस्टनाम को हटा रहा है और मुख्य फाइलों से टाइमस्टैम्प बनाया गया है)

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

मैं username और host को छोड़ना चाहता हूं और बनाए गए टाइमस्टैम्प को अंदर छोड़ना चाहता हूं। विचार?

मैंने आज https://github.com/klauspost/reedsolomon के साथ खेला है और मुझे लगता है कि हम पैक फ़ाइल के अंत में आसानी से त्रुटि-सुधार कोड जोड़ सकते हैं (एक बार जब हम पैक हेडर को फ़ाइल की शुरुआत में ले जाते हैं) ) हालांकि, दो डाउनसाइड्स हैं:

• रीड-सोलोमन के लिए हमारे द्वारा चुने गए मापदंडों के आधार पर फ़ाइल का आकार ~ 14-30% बढ़ जाएगा
• हमें पैक फ़ाइल के अनुभागों के चेकसम (आवश्यक रूप से क्रिप्टोग्राफ़िक हैश नहीं) को पैक फ़ाइल में ही संग्रहीत करने की आवश्यकता होगी, ये पुनर्निर्माण के लिए आवश्यक हैं क्योंकि पुनर्निर्माण के लिए एल्गोरिथ्म को यह जानने की आवश्यकता है कि फ़ाइल के कौन से हिस्से क्षतिग्रस्त हो गए हैं। इसलिए गणना करने में थोड़ा अधिक समय लगता है, हालांकि हम एक तेज़ चेकसम (जैसे सीआरसी या तो) का उपयोग करना चुन सकते हैं।

विचार?

क्या डेटा रॉड सुरक्षा तब वैकल्पिक हो सकती है? मैं मानता हूं कि आकार सीमांत से अधिक बढ़ता है (हालांकि मुझे विश्वास है कि यह अन्य लोगों के लिए एक बड़ी विशेषता है!)

मुझे इसके साथ थोड़ा खेलने दें, ताकि मैं यह महसूस कर सकूं कि ईसीसी को संपीड़न के साथ जोड़ने पर रेपो कितना बड़ा (या छोटा?) होगा। हो सकता है कि हम दो प्रकार के कोड जोड़ते हैं: एक पैक हेडर के लिए, और एक (शायद वैकल्पिक) डेटा के लिए।

उपयोगकर्ता नाम और होस्ट ड्रॉप करें

एक अच्छे विचार की तरह लगता है। अगर हम जानकारी रखना चाहते हैं तो इसे एक अलग एन्क्रिप्टेड फ़ील्ड में जोड़ा जा सकता है, उसी तरह जैसे मास्टर कुंजी।

ECC: फ़ाइल का आकार ~14-30% बढ़ जाएगा,

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

मेरा सुझाव है कि समता डेटा को एक अलग निर्देशिका में रखा जाए:

repo/data/1e/1ef7267...
repo/parity/1e/1ef7267...

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

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

आपकी टिप्पणियों के लिए धन्यवाद, चलिए चर्चा को एक अलग मुद्दे पर ले जाते हैं जिसे मैंने अभी बनाया है: #804।

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

मैंने अपनी पायथन लिपि (https://github.com/oysols/restic-python) के साथ अपने रेपो पर त्वरित जांच की।

header_length:        8688549
tree_length:         53898054
data_length:     146443506727
treeblobs:               8466
datablobs:             200975
packfiles:              29351
---- repo size by dir ----
            155   config
146 510 470 574   data
     27 538 629   index
          4 545   keys
          4 243   locks
         14 041   snapshots
          4 096   tmp
-----
Currently 116071 original files contained in the backup.

146 जीबी बैकअप में से, ट्री ब्लॉब्स केवल 54 एमबी का होता है और जब हम कंप्रेशन लागू करते हैं, तो यह मूल स्थान के लगभग एक तिहाई हिस्से तक अच्छी तरह से संकुचित हो जाएगा।

क्या डेटा ब्लॉब्स से ट्री ब्लॉब्स को अलग करके प्रदर्शन में सुधार होगा?

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

बेशक; यह वितरण सभी रेपो के लिए समान नहीं हो सकता है।

क्या आपको लगता है कि यह आगे देखने लायक है?

क्या डेटा ब्लॉब्स से ट्री ब्लॉब्स को अलग करके प्रदर्शन में सुधार होगा?

हो सकता है, भविष्य के लिए मेरे मन में यह अनुकूलन में से एक है।

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

क्या डेटा ब्लॉब्स से ट्री ब्लॉब्स को अलग करके प्रदर्शन में सुधार होगा?

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

मैं इसे पहले से ही #842 . के दौरान देख रहा हूँ

जीसीएम बनाम सीटीआर: http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html

सिम बनाम एसिम: विचार एक "सत्र" -की को पबकी-एन्क्रिप्ट करना है, है ना?

आइए इस मुद्दे में क्रिप्टो पर चर्चा न करें, क्योंकि इसे अभी के लिए स्थगित कर दिया गया है। असममित क्रिप्टो चर्चाओं के लिए प्रासंगिक मुद्दा # 187 है। इसके अलावा, जब तक हम उपयोग के मामले को समाप्त नहीं कर देते, मैं चर्चा को उच्च स्तर पर रखना चाहता हूं। तब हम निम्न-स्तरीय क्रिप्टो के बारे में बात कर सकते हैं।

कुंजी फ़ाइलों से उपयोगकर्ता नाम और होस्टनाम निकालें।

बहुत बड़ा मेटाडेटा लीक!
उदाहरण के लिए, "username":"WorldBank\\JimYongKim" स्पष्ट रूप से उच्च-रैंकिंग स्वामी को इंगित करता है।

जनवरी 2017 में पहली विंडोज बाइनरी संकलित होने के बाद से इसके _removed_ (या _encrypted_) होने की प्रतीक्षा की जा रही है।
सौभाग्य से, मैंने गोपनीयता-जागरूक साथियों को रेस्टिक को अपलोड करने या अनुशंसा करने से पहले बैकअप की जांच की।

संपादित करें: सादा पाठ में उपयोगकर्ता के समय क्षेत्र का भी उल्लेख किया गया है, जो गोपनीयता सिद्धांत के खिलाफ भी जाता है।

पुन: SHA3 - यहाँ एक राय है कि यह अपनाने योग्य क्यों नहीं है (अभी तक?): https://www.imperialviolet.org/2017/05/31/skipsha3.html

इस प्रकार मेरा मानना ​​है कि SHA-3 का शायद उपयोग नहीं किया जाना चाहिए। यह SHA-2 पर कोई सम्मोहक लाभ प्रदान नहीं करता है और कई लागतें लाता है। एकमात्र तर्क जिसे मैं श्रेय दे सकता हूं वह यह है कि बैकअप हैश फ़ंक्शन होना अच्छा है, लेकिन SHA-256 और SHA-512 दोनों आमतौर पर समर्थित हैं और अलग-अलग कोर हैं। इसलिए हमारे पास पहले से ही दो सुरक्षित हैश फ़ंक्शन तैनात हैं और मुझे नहीं लगता कि हमें दूसरे की आवश्यकता है।

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

सुनिश्चित नहीं है कि यह एक रेपो-प्रारूप चीज़ है: एन्क्रिप्शन को वैकल्पिक बनाने के बारे में कैसे? मैं बैकअप के बारे में सोच रहा हूं जो एक विश्वसनीय बैकअप सर्वर पर संग्रहीत किया जाएगा जिसमें पहले से एन्क्रिप्टेड डिस्क हैं।

@mschiff उस चर्चा के लिए #1018 देखें। ;)

भाग आकार को एक विकल्प बनाने के बारे में कैसे?
वर्तमान में मेरे पास प्रति फ़ाइल 4-6 एमबी है। कम फाइलों के साथ लेकिन बड़े, रिमोट बैकअप बहुत तेज होगा।

@ fd0 ने लिखा:

फिलहाल, मुझे गति से कोई सरोकार नहीं है (रेस्टिक पहले से ही वास्तव में तेज़ है), इसलिए कम से कम मेरे लिए यह आइटम कम प्राथमिकता का है। सिम-सक्षम प्रोसेसर के लिए SHA256 का एक अनुकूलित संस्करण भी मौजूद है जिसे हम आसानी से स्विच कर सकते हैं। दूसरी ओर, जब हम रेस्टिक को गति देने का निर्णय लेते हैं और हैश पर चर्चा की जानी है, तो मैं शायद केकक (SHA3) या ब्लेक 2 को पसंद करूंगा, वे हैं (जहाँ तक मुझे पता है, मैंने अभी तक कोई बेंचमार्क नहीं किया है) बहुत तेजी से।

एक तेज़, कम CPU गहन हैश एल्गोरिथम (जैसे Blake2) के लिए एक और विचार लैपटॉप पर बैटरी के उपयोग को कम करना होगा, जबकि एक शक्ति स्रोत से कनेक्ट नहीं होने पर बैकअप बनाना।

पहली पोस्ट का जवाब:

कुंजी फ़ाइलों से उपयोगकर्ता नाम और होस्टनाम निकालें।

क्या इसे मुख्य नाम या किसी प्रकार के विवरण से बदल दिया जाएगा? मेरा मानना ​​​​है कि अलग-अलग कुंजियों को अलग करने का कोई तरीका (कुंजी तक पहुंच के बिना, उदाहरण के लिए जब किसी मशीन के लिए पहुंच रद्द करना) कुंजी प्रबंधन को उपयोगी बनाने के लिए उपयोगी है?

एक नया सुझाव: बूँद, पेड़ और स्नैपशॉट के लिए एक अलग कुंजी का उपयोग कैसे करें? यह, AFAICS, एक ऐसे परिदृश्य को सक्षम करेगा जहां क्लाइंट के बजाय बैकअप स्टोरेज सर्वर पर भूल और छंटाई होती है। स्टोरेज सर्वर को ट्री और स्नैपशॉट ऑब्जेक्ट तक पहुंच प्रदान करके, यह निर्धारित करने के लिए पर्याप्त जानकारी होनी चाहिए कि कौन से स्नैपशॉट के लिए किन ऑब्जेक्ट्स की आवश्यकता है और किन ऑब्जेक्ट्स का अब उपयोग नहीं किया जाता है। यदि स्टोरेज सर्वर से हर तरह का समझौता किया जाता है, तो ट्री मेटाडेटा तक पहुंच प्राप्त होती है, लेकिन वास्तविक फ़ाइल सामग्री नहीं।

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

यदि उपरोक्त को संभव बनाया जाता है, तो यह केवल लिखने के लिए/केवल परिशिष्ट प्रकार के भंडारण का उपयोग करने के लिए रास्ता खोलता है (जहां बैक-अप क्लाइंट बैकअप नहीं हटा सकता है, # 784 देखें), या तो स्वचालित छंटाई का त्याग किए बिना, या डाटा सुरक्षा।

मेरी पिछली टिप्पणी के बारे में (डेटा तक पूर्ण पहुंच की आवश्यकता के बिना छंटनी): यह बैकअप की जांच के लिए (संभवतः और भी मजबूत) लागू होता है। दक्षता कारणों से स्टोरेज सर्वर पर रेपो की जांच करना समझ में आता है (AFAICS को रेपो की जांच करने के लिए दूरस्थ रूप से सभी सामग्री को स्थानांतरित करने की आवश्यकता होती है), या जब केवल राइट-ओनली सपोर्ट लागू होता है (देखें https://github.com/ncw/rclone/issues / 2499)।

इसके अलावा, केवल एक सच्चे लेखन दृष्टिकोण के लिए, इसे पढ़ने के लिए आवश्यक फ़ाइलों को सीमित करने के लिए परिवर्तनों की आवश्यकता होती है (https://github.com/ncw/rclone/issues/2499#issuecomment-418609301) के अनुसार। मुझे यकीन नहीं है कि उसे भी रिपोजिटरी प्रारूप परिवर्तनों की आवश्यकता है, यदि ऐसा है तो इन्हें यहां शामिल करना उपयोगी हो सकता है?

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

मैं स्नैपशॉट फ़ाइल स्वरूप में कुछ (शायद वैकल्पिक) परिवर्धन पर चर्चा करना चाहूंगा:

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

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

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

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

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

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

मुझे इस बात में भी दिलचस्पी है कि भविष्य क्या आराम लाता है। विशेष रूप से असममित क्रिप्टो और संपीड़न में।
वैसे, एक नए हैश फ़ंक्शन के लिए, blake3 भी है जो बहुत नया है और बहुत तेज़ भी है: https://github.com/BLAKE3-team/BLAKE3
यदि हैश फ़ंक्शन में बदलाव के संबंध में पहले से कोई निर्णय नहीं लिया गया है, तो यह दिलचस्प हो सकता है।

रेपो.v2 के लिए कुछ और विचार:

• अलग-अलग निर्देशिकाओं में पेड़ और डेटा ब्लॉब्स को सहेजें (पिछले पेड़ और डेटा मिश्रित थे, लेकिन इसे कैश की शुरूआत के साथ बहिष्कृत किया गया था)।
• डेटा ब्लॉब्स में 'बनाए गए समय' की जानकारी जोड़ें।

यह अमेज़ॅन ग्लेशियर जैसे बहुत धीमी या महंगी डाउनलोड के साथ 'कोल्ड' स्टोरेज के लिए समर्थन को सरल बनाना चाहिए।

* save tree and data blobs to different directories (in the past tree and data was mixed, but this was deprecated with introduction of cache).

मुझे यह विचार पसंद नहीं है.. यह बैकअप के फ़ाइल आकार का अनुमान लगाना बहुत आसान बनाता है जबकि मुझे इसका कोई लाभ नहीं दिखता है।

* add 'created time' info to data blobs.

मुझे "बनाए गए समय" को जोड़ने का कोई फायदा नहीं दिख रहा है। क्या आप उपयोग का मामला दे सकते हैं?

यह अमेज़ॅन ग्लेशियर जैसे बहुत धीमी या महंगी डाउनलोड के साथ 'कोल्ड' स्टोरेज के लिए समर्थन को सरल बनाना चाहिए।

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

* save tree and data blobs to different directories (in the past tree and data was mixed, but this was deprecated with introduction of cache).

मुझे यह विचार पसंद नहीं है.. यह बैकअप के फ़ाइल आकार का अनुमान लगाना बहुत आसान बनाता है जबकि मुझे इसका कोई लाभ नहीं दिखता है।

इस मुद्दे पर पहले की टिप्पणियों में लाभ अच्छी तरह से निर्धारित किया गया है:
https://github.com/restic/restic/issues/628#issuecomment -280436633
https://github.com/restic/restic/issues/628#issuecomment -280833405
पहली टिप्पणी के परिणाम यह भी दिखाते हैं कि इन दो प्रकार के बूँदों को मिलाने से फ़ाइल का आकार किसी भी सार्थक तरीके से अस्पष्ट नहीं होता है।

संबंधित मंच पोस्ट:
https://forum.restic.net/t/feature-using-an-index-for-restic-find/1773

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

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

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

ट्री ब्लॉब्स पहले से ही अलग पैक फ़ाइलों में संग्रहीत हैं (इसे कैश के साथ एक साथ पेश किया गया था)।
बस उन्हें अलग-अलग निर्देशिका में लिखने से बहुत धीमी-से-डाउनलोड स्टोरेज के समर्थन में सुधार करने का एक रास्ता खुल जाएगा (अमेज़ॅन ग्लेशियर मानक के लिए 3-5 घंटे)। जैसे सभी मेटाडेटा (इंडेक्स+स्नैपशॉट+ट्री नियमित S3 में, और डेटा ग्लेशियर में) स्टोर करना।

2504 इसे थोड़ा सुधारता है, लेकिन मुझे 'लोकल-कैश' पर भरोसा करने या कैश भरने के लिए बहुत इंतजार करने का विचार पसंद नहीं है।

मुझे कुछ रिवर्स प्रॉक्सी का विचार पसंद है जो नियमित S3 या किसी अन्य स्थान पर tree+index+snapshots स्टोर करेगा, लेकिन डेटा को गहरे संग्रह में रखेगा।
किसी भी मामले में, निश्चित रूप से कुछ सीमाओं के साथ restic का उपयोग करना संभव है। लेकिन कुछ प्रारूप परिवर्तन चीजों को बेहतर/सरल कर सकते हैं।

@cfbao जहां तक ​​​​मैं कोड restic find से देखता हूं, इससे कोई फायदा नहीं होगा। यह पहले से ही स्नैपशॉट पर चलता है। मूल रूप से यह ज्यादातर restic ls <all-snapshots> | grep something जैसा ही है।

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

शायद यह एक बेवकूफी भरा विचार है लेकिन बोर्ग या कोपिया के साथ संगत प्रारूप के बारे में क्या?

@aawsome

आप जिन टिप्पणियों का जिक्र कर रहे हैं, वे एक डेटा फ़ाइल (पैक) के भीतर ट्री और डेटा ब्लॉब को मिलाने के बारे में हैं।

सत्य। मेरी गलती। हाँ, यही एकमात्र चीज है जिसकी मुझे परवाह है।

यह पहले से ही रेस्टिक में बदल चुका है।

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

मुझे अभी भी विभिन्न निर्देशिकाओं में पेड़ और डेटा ब्लॉब्स सहेजने का कोई लाभ नहीं दिख रहा है। क्या आप उपयोग का मामला दे सकते हैं?

मुझे पता नहीं है। जैसा कि पहले उल्लेख किया गया है, मुझे वास्तव में इसकी परवाह नहीं है।

@dionorgua

जहां तक ​​​​मैं कोड रेस्टिक फाइंड से देखता हूं, इससे कोई फायदा नहीं होगा। यह पहले से ही स्नैपशॉट पर चलता है। मूल रूप से यह ज्यादातर रेस्टिक ls . जैसा ही है| ग्रेप कुछ।

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

किसी भी तरह से मैं (शायद धीरे-धीरे) अपने रेपो को बेहतर बनाने के लिए परिवर्तित कर सकता हूं
अलगाव?

रेस्टिक के हाल के संस्करण के साथ 'प्रून' के एक रन को इन मिश्रित पैकों का पुनर्निर्माण करना चाहिए।
ध्यान दें कि 'छंटाई' का वास्तविक कार्यान्वयन दूरस्थ रिपॉजिटरी के लिए बहुत अधिक ट्रैफ़िक उत्पन्न करता है। #2718 में प्रयोगात्मक पुन: कार्यान्वयन के साथ आप कम से कम ट्रैफ़िक होने पर केवल मिश्रित पैक ही दोबारा पैक कर पाएंगे।

ट्री ब्लॉब्स को डेटा ब्लॉब्स से अलग नहीं करने से API की संख्या कम हो जाएगी
खोजने के लिए आवश्यक कॉल?

हाल के संस्करण में और एक रेपो के साथ जिसमें कोई मिश्रित पैक नहीं है, सभी आवश्यक जानकारी स्थानीय रूप से कैश की जाती है।

एक बेहतर रिपोजिटरी प्रारूप के लिए एक और विचार:

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

इसे रिपोजिटरी में भी करने से अधिक कॉम्पैक्ट प्रतिनिधित्व की अनुमति होगी, उदाहरण के लिए

{
  "supersedes": [
    "ed54ae36197f4745ebc4b54d10e0f623eaaaedd03013eb7ae90df881b7781452"
  ],
  "type": "data",
  "packs": [
    {
      "id": "73d04e6125cf3c28a299cc2f3cca3b78ceac396e4fcf9575e34536b26782413c",
      "blobs": [
        {
          "id": "3ec79977ef0cf5de7b08cd12b874cd0f62bbaf7f07f3497a5b1bbcc8cb39b1ce",
          "offset": 0,
          "length": 25
        },{
          "id": "9ccb846e60d90d4eb915848add7aa7ea1e4bbabfc60e573db9f7bfb2789afbae",
          "offset": 38,
          "length": 100
        },
        {
          "id": "d3dc577b4ffd38cc4b32122cabf8655a0223ed22edfd93b353dc0c3f2b0fdf66",
          "offset": 150,
          "length": 123
        }
      ]
    }, [...]
  ]
}