इसे लागू करते समय, बेंचमार्क जोड़ें और विशेष रूप से -बेंचमेम और बेंचकम्प के साथ मेमोरी उपयोग पर एक नज़र डालें!

lz4, lzo, lzma, अशक्त। bz2 बल्कि धीमा है।

मध्यम संपीड़न के साथ तेज़ तेज़ है

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

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

नमकीन सीडीसी के साथ, मुझे लगता है कि समस्याग्रस्त फ़ाइल को टुकड़ों में विभाजित करने के बाद, प्रत्येक व्यक्तिगत खंड पर संपीड़न होगा। शेष भाग 512 केबी से 8 एमबी की सीमा में हैं (लेकिन समान रूप से वितरित नहीं - सही?)

• हमलावर जानता है कि सीडीसी एल्गोरिथम एक गुप्त नमक का उपयोग करता है, इसलिए हमलावर फ़ाइल के पहले 512 केबी से 8 एमबी तक के टुकड़ों की एक श्रृंखला उत्पन्न करता है, प्रत्येक वैध खंड लंबाई के लिए एक। हमलावर संकुचित विखंडू की लंबाई निर्धारित करने में भी सक्षम है।
• हमलावर तब संपीड़न एल्गोरिदम का उपयोग करके उस खंड को संपीड़ित करता है।
• हमलावर परिणामी विखंडू की लंबाई की तुलना बाकी बैकअप सेट में पहले खंड से करता है।
• यदि एक मिलान ब्लॉक लंबाई पाई जाती है, तो हमलावर अगले खंड, और अगले खंड, और अगले खंड, ... और अगले खंड के साथ अभ्यास दोहराता है।
• यह मेरा विश्वास है कि पर्याप्त रूप से बड़ी फाइलों के साथ, और इस तथ्य पर विचार करते हुए कि सीडीसी एल्गोरिदम लगभग 1 एमबी के ब्लॉक उत्पन्न करने के लिए "पक्षपाती" (शब्दों के बेहतर अभाव में) है, यह पता लगाने के लिए पर्याप्त होगा कि एक निश्चित बड़ा है या नहीं फ़ाइल बैकअप में मौजूद है।

हमेशा की तरह, चेतना की एक पागल और अत्यधिक अवैज्ञानिक धारा।

विचार?

दिलचस्प। मुझे समझ में नहीं आता कि आप जिस हमले का वर्णन करते हैं वह इस बात पर निर्भर करता है कि संपीड़न का उपयोग किया जाता है, क्या यह बिल्कुल जरूरी है? क्या यह हमला संपीड़न के साथ और बिना काम नहीं करता है?

फिलहाल मैं सोच रहा हूं कि #56 को कैसे लागू किया जाए। एक फ़ाइल में कई ब्लॉब्स को एक साथ बंडल करने पर आपके क्या विचार हैं?

सीडीसी कार्यान्वयन का सटीक कार्य मेरे लिए थोड़ा अस्पष्ट है:

• क्या आप सटीक बाइट सीमाओं पर विभाजित हैं या 512 केबी - 8 एमबी ब्लॉक किसी चीज़ के गुणक में "गोल" हैं?
• (असली सवाल यह है: क्या वहां (15 * 512 * 1024)/(16 एईएस-सीटीआर के कारण) संभव चंक आकार, या उससे कम है?)
• मैं इस बारे में भी उत्सुक हूं कि किसी ज्ञात फ़ाइल के पर्याप्त भाग दिए गए बीज को फिर से बनाना कितना संभव होगा - बहुत संभव नहीं है, मैं अनुमान लगा रहा हूं?

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

उदाहरण:
यदि वॉटरमार्क वाली फ़ाइल में 64 एमबी (8-128 भाग) "एएएए" है, तो 64 एमबी "एबीसीएबीसीएबीसीएबीसी", फिर 64 एमबी यादृच्छिक डेटा, पहले 16-256 भाग बहुत छोटे होंगे (क्योंकि वे अनुक्रम बहुत अच्छी तरह से संपीड़ित होते हैं , जहां 8-128 विखंडू खराब तरीके से संपीड़ित होंगे)।
हमलावर भी पीछे की ओर काम करने में सक्षम होगा, बहुत आखिरी (24 वें - 384 वें) खंड से शुरू होता है और 512 केबी -8 एमबी को संपीड़ित करता है जब तक कि हमलावर को एक ऐसा आकार न मिल जाए जो बिल्कुल उसी खंड आकार में संपीड़ित हो। एक बार यह मिल जाने के बाद, मूल प्लेनटेक्स्ट का "अगला" 512KB-8MB यह पता लगाने के लिए संपीड़ित किया जाता है कि कौन सी लंबाई दूसरे-से-अंतिम ब्लॉक (23वें - 383वें) की लंबाई तक संकुचित होती है, और इसी तरह, जब तक कि हमलावर छोटे टुकड़े जो "एएएए" तारों का परिणाम हैं।
यह एक विरोधी को सकारात्मक रूप से पुष्टि करने में सक्षम नहीं करता है कि एक वॉटरमार्क फ़ाइल बैकअप में संग्रहीत है, लेकिन मुझे लगता है कि सांख्यिकीय रूप से यह पर्याप्त डेटा दिए जाने पर काफी स्पष्ट परिणाम बना सकता है।

मुझे कुछ संभावित समाधान दिखाई दे रहे हैं, शायद आपके पास और विचार हैं:

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

आपके स्पष्टीकरण के लिए धन्यवाद, मैं अब आपके परिदृश्य को समझता हूं।

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

आपका तीसरा विचार #56 में लागू किया जाएगा (कई हिस्सों को एक साथ जोड़कर), मैं अभी उस पर काम कर रहा हूं। और मैं शायद doc/Design.md में और दस्तावेज़ जोड़ूंगा कि चंकर कैसे काम करता है।

इस परिदृश्य को लाने के लिए फिर से धन्यवाद!

मुझे यकीन नहीं है कि मैं @cfcs का अनुसरण करता

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

@klauspost : ध्यान रखें कि हम फाइलों के बजाय अलग-अलग हिस्सों के संकुचित आकारों पर चर्चा कर रहे हैं। 1MB के औसत चंक आकार वाली 100GB फ़ाइल में लगभग 100 x 1024 विखंडू होंगे, प्रत्येक फ़ाइल के एक निश्चित भाग के लिए संपीड़न अनुपात को लीक करेगा। यह एक एकल संपीड़ित फ़ाइल के आकार की तुलना में बहुत अधिक सांख्यिकीय डेटा में परिणाम देता है, जिससे सीडीसी नमक (और इस प्रकार टुकड़ों की सटीक संरेखण सीमाएं) अज्ञात होने पर भी एक ज्ञात सादा पाठ की तुलना संपीड़ित और खंडित फ़ाइल से करना संभव हो जाता है।

हालांकि, 151 को मर्ज कर दिया गया है, इसलिए शायद यह अब कोई मुद्दा नहीं है।

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

@klauspost मैं निश्चित रूप से आपकी लाइब्रेरी को

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

@cfcs - ठीक है - आपके पाठ से मुझे लगा कि आपने निहित किया है कि आप डेटा को

गैर-संपीड़ित फ़ाइलों के संबंध में, यही कारण है कि मैंने निरंतर समय हफ़मैन केवल मोड का उल्लेख किया है जिसे मैंने डिफ्लेट में रखा है, जैसा कि नाम से पता चलता है कि यह एक ही गति से सभी डेटा को संपीड़ित करता है, और असम्पीडित डेटा को संग्रहीत करने के लिए स्वचालित फ़ॉलबैक होता है। तो सामग्री संपीड़ित होने पर अधिकतम ओवरहेड लगभग 0.04% है।

यहाँ कुछ बेंचमार्क हैं । बैकअप के लिए सबसे अधिक लागू शायद "मध्यम संपीड़न" पर है, जो 10GB मिश्रित सामग्री है - संपीड़ित और असम्पीडित।

केवल हफ़मैन को gzip करने के लिए डिफ़ॉल्ट और अधिक CPU-खपत संपीड़न स्तर निर्दिष्ट करने का विकल्प होने से समझ में आ सकता है।

मेरी राय में डेटा और ट्री ऑब्जेक्ट्स के लिए अलग-अलग संपीड़न को चुनिंदा रूप से सक्षम/अक्षम करना मूल्यवान हो सकता है। विशेष रूप से बड़े पेड़ की वस्तुओं को वास्तव में अच्छा संपीड़ित करना चाहिए।

मैंने कुछ "बिंदुओं" को देखा जहां संपीड़न डालने का अर्थ हो सकता है। सबसे पारदर्शी और बहुमुखी जगह भंडार और बैकएंड के बीच कहीं होगी।

मैंने संक्षेप में Repository.Encrypt और Repository.DecryptTo को संशोधित करने पर ध्यान दिया, लेकिन हमारे पास प्रकार नहीं हैं, और अलग-अलग आकार चीजों को गड़बड़ कर देंगे।

मेरा प्रस्ताव संपीड़न और _एन्क्रिप्शन_ को "बैकएंड" के रूप में कार्यान्वित करना है, जो दोनों अंतर्निहित बैकएंड को लिखते हैं। यह संपीड़न और एन्क्रिप्शन को भंडार में पारदर्शी बना देगा।

एन्क्रिप्शन को अलग करने का कारण यह है कि एन्क्रिप्टेड डेटा संपीड़ित नहीं होता है (जैसा कि आप शायद जानते हैं)।

भंडार.भंडार

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

भंडार। कॉन्फिग

कॉन्फ़िगरेशन को संपीड़ित नहीं किया जा सकता है। हम एक स्ट्रिंग जोड़ते हैं जो हर चीज के लिए उपयोग करने के लिए डीकंप्रेसन प्रकार को इंगित करता है। खाली ("") असम्पीडित है। अन्यथा यह उपयोग किए गए संपीड़न पुस्तकालय के पैकेज नाम का अंतिम भाग है।

ध्यान दें कि प्रत्येक रन/प्रकार के बीच संपीड़न स्तर बदला जा सकता है। रेपो होने में कोई समस्या नहीं है जहां कुछ स्नैपशॉट/प्रकार डिफ्लेट स्तर 0 (स्टोर) हैं और कुछ स्तर 9 (सर्वोत्तम संपीड़न) पर हैं - जब तक डीकंप्रेसर समान है।

type Config struct {
    Version           uint        `json:"version"`
    ID                string      `json:"id"`
    ChunkerPolynomial chunker.Pol `json:"chunker_polynomial"`
+   Compression       string
}

निर्माण पैरामीटर के रूप में संपीड़न जोड़ा जाता है:

-func CreateConfig(r JSONUnpackedSaver) (Config, error) {
+func CreateConfig(r JSONUnpackedSaver, compression string) (Config, error) {

Backend को LoadConfig/CreateConfig के बाद बदल दिया जाता है। यहां एक उदाहरण दिया गया है कि यह कैसा दिख सकता है:

// SearchKey finds a key with the supplied password, afterwards the config is
// read and parsed.
func (r *Repository) SearchKey(password string) error {
    key, err := SearchKey(r, password)
    if err != nil {
        return err
    }

-   r.key = key.master
-   r.keyName = key.Name()
    r.Config, err = LoadConfig(r)
+   r.be, err = FindCompressor(r.Config.Compression, Encryption(key, r.be))
    return err
}

संपीड़न कार्यान्वयन

कंप्रेसर कुछ प्रकारों के लिए चयनात्मक/समायोज्य संपीड़न लागू कर सकता है। चूंकि इसे "बैकएंड" के रूप में देखा जाता है, इसलिए संपीड़ित आकार हम कभी भी भंडार के लिए दृश्यमान नहीं होंगे। कंप्रेसर सभी सेटिंग्स के साथ सममित होना चाहिए।

मुद्दे

HELPME/FIXME: "पैक की गई" फ़ाइलें एक समस्या की तरह लगती हैं, क्योंकि एन्क्रिप्शन प्रत्येक फ़ाइल पर फिर से शुरू होता है। यदि एन्क्रिप्शन को बैकएंड में ले जाया जाता है, तो एन्क्रिप्शन संपूर्ण ब्लॉब के लिए होगा, प्रत्येक फ़ाइल के लिए नहीं। मुझे लगता है कि यह एक समस्या है, और मेरे पास कोई अच्छा समाधान नहीं है।

TODO: कंप्रेसर को भेजे जाने वाले पैरामीटर/कॉन्फ़िगरेशन के लिए कुछ अच्छा तरीका खोजें। पहले कार्यान्वयन के लिए आवश्यक नहीं है।

TODO: क्या हम ऑन-डिस्क आकारों की परवाह करते हैं? यदि उपरोक्त लागू किया जाता है, तो भंडार इसे नहीं जान पाएगा।

अपने विचार साझा करने के लिए धन्यवाद, यहाँ मेरे हैं:

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

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

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

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

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

आपको अलग-अलग एल्गोरिदम और मापदंडों की आवश्यकता होगी (और न केवल प्रति रेपो, बल्कि प्रति बैकअप रन भी), "हर उपयोग के लिए सर्वश्रेष्ठ" संपीड़न नहीं है।

एक व्यावहारिक उदाहरण के रूप में:

मैं अपने कंपनी सर्वर से घर पर अपने बैकअप सर्वर पर बैकअप करता हूं। dsl अपलिंक ~700kbit/s के साथ।
इसके लिए मुझे सबसे अच्छा संपीड़न चाहिए (जैसे lzma + उच्च स्तर)। अगले पैकेट को स्वीकार करने के लिए भद्दे कनेक्शन की प्रतीक्षा करते हुए सीपीयू के पास रात में बहुत खाली समय होता है।

जब मैं घर पर होता हूं तो उसी भंडार में मैं अपने लैपटॉप का बैकअप भी लेता हूं, वहां मेरे पास वायरलेस "एन" कनेक्शन होता है। बेशक मैं वहाँ lzma + उच्च स्तर का उपयोग करके कनेक्शन को धीमा नहीं करना चाहता, बल्कि मुझे कुछ बहुत जल्दी चाहिए जो बिल्कुल भी धीमा न हो - जैसे lz4। मैं अभी भी संपीड़न चाहता हूं, lz4 का उपयोग नहीं करने पर लगभग 2x स्थान लगेगा।

मुझे यहाँ lzma चाहिए लेकिन lz4 वहाँ (rephrased :-))

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

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

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

एन्क्रिप्शन के संबंध में: बाद में रेस्टिक के लिए एक गैर-क्रिप्टो मोड हो सकता है, लेकिन अभी के लिए क्रिप्टो वैकल्पिक नहीं है।

यही कारण है कि बैकएंड चेनिंग इसे इतना अच्छा बनाती है। आप बस एन्क्रिप्शन को छोड़ दें (या एक पासथ्रू बैकएंड बनाएं) और यह मूल रूप से काम करता है।

संपीड़न जोड़ने के सामान्य मामले में, मैं लाभ देख सकता हूं, लेकिन जटिलता और ऑन-डिस्क प्रारूप में परिवर्तन प्रबंधनीय होना चाहिए।

यह सबसे कम दखल देने वाला तरीका था जिसे मैं देख सकता था। यदि 'पैक की गई फ़ाइल' समस्या को ठीक करने का कोई तरीका है, तो असम्पीडित रेपो पूरी तरह से पीछे की ओर संगत रहता है; पुराने क्लाइंट नए के साथ पहले की तरह उन पर काम कर सकेंगे।

संपीड़ित रेपो स्पष्ट रूप से नहीं होगा, लेकिन हम version को केवल 2 में बदल सकते हैं यदि रेपो संपीड़ित है, इससे पुराने ग्राहक विफल हो जाएंगे। चेक को स्पष्ट रूप से if cfg.Version > RepoVersion { बदल दिया जाना चाहिए, लेकिन इसमें कोई संगतता समस्या नहीं है।

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

इस बात से सहमत। अधिकांश एल्गोरिदम (lzma/deflate) में एक ही डीकंप्रेसन प्रारूप में बहुत अधिक लचीलापन होता है।

संपीड्यता का परीक्षण करने के लिए डेटास्मोक है: https://github.com/Bulat-Ziganshin/DataSmoke

इसके अलावा, pcompress संपीड़न एल्गोरिदम का एक अच्छा वर्गीकरण चुनता है: https://github.com/moinakg/pcompress

स्क्वैश कम्प्रेशन एब्स्ट्रैक्शन लाइब्रेरी में एल्गोरिदम और बेंचमार्क की एक अच्छी सूची है: https://quixdb.github.io/squash/

यहाँ एक टेक्स्ट कम्प्रेशन बेंचमार्क है: http://mattmahoney.net/dc/text.html

आसान तरीका यह है कि हमेशा crypto/crypto.go अंदर फ़िल्टर करें कार्यों को एन्क्रिप्ट/डिक्रिप्ट करें।

gzip-compression-v1.patch.txt यह प्रूफ-ऑफ-कॉन्सेप्ट

@mapu को आजमाने के लिए धन्यवाद, लेकिन इसे लागू करने से पहले हमें एक रणनीति पर सहमत होने की जरूरत है। खुले प्रश्न (मेरे सिर के ऊपर से) कम से कम हैं:

• संपीड़न कब लागू किया जाता है? (डेटा? मेटाडेटा/JSON?)
• हमें कौन सा एल्गोरिदम लागू करना चाहिए? मुझे लगता है कि @klauspost के पास हमारे लिए कुछ सुझाव हैं :)
• हम ग्राहकों को तोड़े बिना इसे एक भंडार में कैसे स्टोर करते हैं?

संपीड़न कब लागू किया जाता है? (डेटा? मेटाडेटा/JSON?)

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

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

हमें कौन सा एल्गोरिदम लागू करना चाहिए? मुझे लगता है कि @klauspost के पास हमारे लिए कुछ सुझाव हैं :)

परवाह नहीं है हालांकि मैं @ThomasWaldmann से सहमत --best और --fast उपयोग के मामले के लिए।

मैं केवल gzip का सुझाव दूंगा क्योंकि यह शुद्ध है, यह गोलांग मानक पुस्तकालय में है, और Google से प्रदर्शन ध्यान प्राप्त करता है। xz बहुत मजबूत धीमा संपीड़न है। lz4 बहुत कमजोर तेज संपीड़न है। gzip संतुलित है और आसानी से ट्यून किया जा सकता है, भले ही यह चरम पर न भी पहुंचे।

हम ग्राहकों को तोड़े बिना इसे एक भंडार में कैसे स्टोर करते हैं?

भंडार केवल एक दिशा में संगत होना चाहिए। मुझे लगता है कि यह ठीक है अगर पुराना रेस्टिक नया रेपो नहीं पढ़ सकता है, जब तक कि नया रेस्टिक पुराने रेपो को पढ़ सकता है।

शायद आप मैक के बाद टैग बाइट जोड़ सकते हैं। मौजूद नहीं - कोई संपीड़न नहीं (पुराना रेस्टिक)। फिर, बाइट यह भी इंगित कर सकता है कि किस संपीड़न एल्गोरिदम का उपयोग किया गया था। 0x01 gzip 0x02 lz4 या तो।

ऐसा लगता है कि अटारी जैसी ही (या बदतर) समस्या मौजूद है (वर्तमान प्रारूप में उपयोग किए जाने वाले कोई संपीड़न प्रकार/पैरामीटर बाइट नहीं)।

अटारी (बोर्ग) में मैं भाग्यशाली था क्योंकि पुराना प्रारूप केवल gzip था और पहले 2 बाइट्स से gzip प्रारूप का पता लगाया जा सकता है। इसलिए मैंने अतिरिक्त बाइट्स (पुराने रेपो के समान) के बिना gzip रखा और जोड़ा बाइट्स (बिना या अन्य संपीड़न के) जो पहले 2 gzip बाइट्स के साथ कभी भी अस्पष्ट नहीं होते हैं।

जाहिर है आप ऐसा नहीं कर सकते हैं अगर पुराना प्रारूप सिर्फ कच्चा, मनमाना डेटा है।

नहीं, लेकिन इस जानकारी को संकेत देने के अन्य तरीके भी हैं। उदाहरण के लिए यदि एन्क्रिप्टेड खंड की शुरुआत में IV बिल्कुल "NEWFORMAT" (1 :: 2 ^ xyz टक्कर का मौका) है तो नए प्रारूप के रूप में पार्स करें। यह इतना "साफ" नहीं है लेकिन मुझे व्यवहार में ठीक लगता है।

जैसा कि एनएमडीसी लॉक हैंडशेक में EXTENDEDPROTOCOL के साथ किया जाता है।

अरे नहीं, हम इस तरह से कुछ भी बदसूरत नहीं करेंगे, और हमें इसकी आवश्यकता नहीं है। क्या हमें इसे लागू करने का निर्णय लेना चाहिए, पैक फाइलों में प्रत्येक ब्लॉब के लिए type फ़ील्ड होता है। यह एक uint8 , और फिलहाल केवल data और tree लिए परिभाषित है, हम आसानी से compressed data और compressed tree जोड़ सकते हैं। https://github.com/restic/restic/blob/master/doc/Design.md#pack -format

फ़िलहाल, मैं इस सुविधा को उच्च प्राथमिकता नहीं मानता।

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

यह महत्वपूर्ण है कि नया-रेस्टिक पुराने-रेपो के साथ काम करे, ताकि आसान उन्नयन हो सके। यह या तो निर्बाध (पसंदीदा) होना चाहिए या इसमें restic upgrade-repo टूल होना चाहिए (पसंदीदा नहीं)।

तो इसके बारे में कैसे?

सभी रेस्टिक कमांड पहले से ही config पहले लोड + डिक्रिप्ट करते हैं।

• यदि पहले config बाइट { (यह json ऑब्जेक्ट पहले बाइट है) है, तो संपूर्ण रेपो पुराना प्रारूप है (असम्पीडित)
• अन्यथा, पहले config बाइट {टैग बाइट} है और संपूर्ण रेपो नया प्रारूप है। डिक्रिप्टेड डेटा की शुरुआत में {टैग बाइट} संपीड़न प्रारूप को इंगित करता है। उदाहरण 0x00 असम्पीडित 0x01 gzip

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

एक अच्छा बैकअप समाधान खोजते समय मुझे कल ही आराम मिला। मेरी मुख्य चिंताओं में से एक यह सीमित कर रही है कि मेरा डेटा कितना स्थान लेता है। विशेष रूप से यदि मैं उन स्थानों पर डेटा भेज रहा हूँ जिनके लिए मैं भुगतान करता हूँ, जैसे S3। डेडअप निश्चित रूप से मदद करेगा, लेकिन मुझे उम्मीद है कि संपीड़न एक बैकअप समाधान का हिस्सा और पार्सल होगा ... https://github.com/restic/restic/issues/21#issuecomment -185920429 में आप ( @fd0 ) यह कहते हैं कम प्राथमिकता है, क्या आप समझा सकते हैं कि क्यों? क्या कोई रोडमैप है जिसे मैं कहीं भी देख सकता हूं?

इसके अलावा, +1। ;)

इस समय मैं पुराने बैकअप डेटा (#518) को हटाने पर काम कर रहा हूं। एक ही समय में संपीड़न को सही और सुरक्षित करना आसान नहीं है, और मुझे इस बारे में थोड़ा और सोचने की ज़रूरत है कि इसे रिपोजिटरी प्रारूप में कैसे एकीकृत किया जाए।

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

यह मुद्दा #116 से संबंधित है। एन्क्रिप्शन के कारण हम बैकअप को किसी अन्य टूल के साथ कंप्रेस नहीं कर सकते हैं, है ना? संपीड़न और एन्क्रिप्शन को वैकल्पिक बनाने के बीच आपकी क्या प्राथमिकता है? (मैं पहले संपीड़न के लिए शर्त लगाता हूं!)
_इस बारे में दबाव बनाने के लिए क्षमा करें, आप सही कह रहे हैं कि भंडार प्रारूप को सावधानी से लिया जाना चाहिए!_

इसका उत्तर देना आसान है: पहले संपीड़न लागू किया जाएगा।

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

@ fd0 मेरे प्रश्न का उत्तर देने के लिए धन्यवाद। मेरी इच्छा है कि मेरे देव कौशल इस पर मदद करने के लिए तैयार हों। लेकिन मैंने केवल मुश्किल से ही छुआ है, और मेरे अधिकांश अन्य xp वेबदेव या सिसडमिन स्क्रिप्ट में हैं।

मैं पूरी तरह से सहमत हूं कि आपको यह सुनिश्चित करने की ज़रूरत है कि संपीड़न "सही और सुरक्षित" हो। अगर वह चीजों में देरी करता है, तो ऐसा ही हो। :मुस्कुराओ:

मैंने यहां रेस्टिक में तेज़ संपीड़न लागू किया: https://github.com/viric/restic/tree/snappy

यह सिर्फ एक प्रस्ताव है। मूल रूप से, मैंने पैक्स में ब्लॉब्स के लिए तेज़ संपीड़न/डिकंप्रेशन जोड़ा, और मैं एक चिह्न के रूप में ब्लॉब प्रकार बाइट का थोड़ा सा उपयोग करता हूं। मैंने पैक इंडेक्स में एक फ़ील्ड भी जोड़ा: PLength (सादा टेक्स्ट लंबाई), जो तब तक संग्रहीत नहीं थी बल्कि "bloblength - क्रिप्टो.एक्सटेंशन" के रूप में गणना की गई थी।

मैंने देखा कि मेरे कुछ बैकअप के लिए यह न केवल कम जगह लेता है, बल्कि यह तेजी से काम करता है (संभालने के लिए कम डेटा)।

सभी रेस्टिक टेस्ट अच्छे से पास होते हैं। यह पिछले रेस्टिक रिपॉजिटरी पर काम कर सकता है, लेकिन सामान्य रेस्टिक (मास्टर का) नए ब्लॉब्स को हैंडल नहीं कर सकता है।

मैंने तेज़ (https://github.com/golang/snappy) का उपयोग किया क्योंकि मुझे लगा कि यह @fd0 की गति के उद्देश्य को कम प्रभावित करेगा।

मास्टर पर कंप्रेशन लैंडिंग के लिए $50 का इनाम जोड़ा गया

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

कुछ एल्गोरिदम का उपयोग करना सबसे आसान होगा जो पारदर्शी रूप से इसे संभालता है, जैसे @klauspost द्वारा पहली टिप्पणी में उल्लिखित निरंतर समय संपीड़न मोड।

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

सुनिश्चित नहीं है कि यह फ़ाइल स्तर के बजाय, खंड पर कितनी अच्छी तरह मैप करेगा।

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

@teknico

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

मेरा संशोधित डिफ्लेट पैकेज पहले से ही संपीड़ित डेटा को छोड़ देता है और ऐसा ~ 250MB/s प्रति कोर की दर से करता है। गो 1.7 डिफ्लेट केवल सबसे तेज़ संपीड़न स्तरों पर इसका समर्थन करता है।

Snappy और LZ4 समान लंघन कार्यक्षमता का समर्थन करते हैं।

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

यह निश्चित रूप से एक विकल्प होना चाहिए। गो 1.7 (जिसे अब हफ़मैन ओनली और मेरे समकक्ष कहा जाता है) में यह मोड ~ 200MB/s प्रति कोर का समर्थन करता है, इनपुट से कोई फर्क नहीं पड़ता। हालांकि "सर्वश्रेष्ठ गति" की तुलना में संपीड़न गंभीर रूप से बाधित होता है, जो आमतौर पर 80 एमबी/एस/कोर पर संचालित होता है।

@cfcs

मुझे लगता है कि यह प्रति फ़ाइल होना चाहिए, भले ही यह इसे "कम अच्छा" बनाता है।

आम तौर पर मैं सहमत हूं। मुझे रेस्टिक पर पढ़ना होगा। क्या प्रत्येक पैक आकार का बाइनरी आकार गैर-एन्क्रिप्टेड उपलब्ध है?

@klauspost ऐसा लगता है कि आपके कुछ सुधार Go 1.7 DEFLATE "BestSpeed" मोड में विलय हो गए हैं, क्या यह सही है? शायद यह एक उचित डिफ़ॉल्ट होगा।

DEFLATE प्रारूप का उपयोग करने का लाभ यह है कि कई अलग-अलग कम्प्रेसर उपलब्ध हैं जो संगत बिटस्ट्रीम का उत्पादन करते हैं, इसलिए यह डीकंप्रेसर के लिए पूरी तरह से पारदर्शी है।

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

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

एक "संपीड़ित" परीक्षण अनुमानी दोनों त्रुटियों से ग्रस्त है और काफी महंगा है। मैं अनुमान लगाऊंगा कि 200 एमबी/एस/कोर से ऊपर प्राप्त करना कठिन होगा - यह एएमडी 64 पर

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

@ fd0 क्षमा करें, मेरा मतलब प्रति-ब्लॉब था, प्रति फ़ाइल नहीं।
जब तक हम एक हल्का एल्गोरिदम नहीं चुनते, संपीड़न, कुछ हद तक सीपीयू-भारी होने के कारण, एक बाधा बनने की संभावना है (एईएस के बगल में, जिसे भविष्य में एईएस-एनआई द्वारा ध्यान दिया जाएगा)।

@ fd0 - मैंने एक त्वरित "संपीड़न https://play.golang.org/p/Ve5z3txkyz - यह अनुमानित डेटा की भविष्यवाणी और एन्ट्रॉपी का अनुमान लगाता है। हालांकि, जैसा कि मैंने उल्लेख किया है, यह तय करने के लिए कंप्रेसर पर निर्भर होना चाहिए।

बोर्ग 1.1 में 2 "संपीड़न निर्णायक" होंगे:

1. पथ पैटर्न मिलान के आधार पर प्रति फ़ाइल तय करें ( *.zip , *.mp3 , /htdocs/photos/* , ...)
2. यदि अनिर्णीत है, तो प्रति खंड तय करें, lz4 को संपीड़ितता के परीक्षण के रूप में उपयोग करें - यदि वह संपीड़ित करता है, तो वांछित संपीड़न (lz4, zlib, lzma) के साथ फिर से संपीड़ित करें, यदि नहीं, तो संपीड़ित न करें।

@klauspost एचएम, वह परीक्षण मेरी मशीन पर इतना बुरा नहीं है:

BenchmarkCompressibility-4           100      10345544 ns/op     810.84 MB/s

बेंचमार्क कोड यहाँ है: https://gist.github.com/908c23123dda275a479cf931f2784f5d

Lz4 में एन्ट्रापी कोडर नहीं है, इसलिए यह कई बार गलत नकारात्मक होगा
शायद?

मुझे लगता है कि हमें तीन मोड (विश्व स्तर पर) की आवश्यकता है:

• एक रैखिक समय कंप्रेसर (डिफ़ॉल्ट) के साथ सभी डेटा ब्लॉब्स को संपीड़ित करें
• कोई संपीड़न नहीं
• अधिकतम संपीड़न (बहुत सी CPU शक्ति वाले लोगों के लिए, लेकिन केवल छोटी बैंडविड्थ)

मैं हमेशा ट्री ऑब्जेक्ट्स (JSON) को कंप्रेस करना चाहता हूं, इसलिए हमें ASCII टेक्स्ट के लिए एक उचित एल्गोरिथम का चयन करना चाहिए।

अन्यथा मैं एक प्रोटोटाइप बनाने के लिए @viric के साथ काम

विचार?

@klauspost एचएम, वह परीक्षण मेरी मशीन पर इतना बुरा नहीं है

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

मुझे लगता है कि हमें तीन मोड (विश्व स्तर पर) की आवश्यकता है:

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

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

यदि आप केवल एक संपीड़न एल्गोरिथ्म चाहते हैं, तो आपको नए दावेदार zstd पर एक नज़र डालनी चाहिए: https://github.com/facebook/zstd

इसे उसी डेवलपर ने lz4 के रूप में विकसित किया था और इसमें gzip की तुलना में बेहतर संपीड़न अनुपात है, जबकि यह 3 गुना से अधिक तेज है: https://code.facebook.com/posts/1658392934479273/smaller-and-faster-data-compression-with -ज़स्टैंडर्ड/

zstd बहुत आशाजनक लग रहा है, हालांकि मैं गो में कार्यान्वयन नहीं ढूंढ पा रहा था।

आधिकारिक साइट http://facebook.github.io/zstd/#other -languages ​​इस गो कार्यान्वयन से जुड़ी हैं: https://github.com/DataDog/zstd

या आपका मतलब शुद्ध गो कार्यान्वयन है?

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

क्या संपीड़न को लागू करने का कोई पूर्वानुमान है?

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

क्या ऐसा करने के लिए हम कुछ कर सकते हैं या योगदान दे सकते हैं?

मुझे ऐसा नहीं लगता, क्षमा करें: पलक:, इसे बस समय चाहिए।

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

35G backup-unencrypted
6.4G    backup-unencrypted.tgz2

क्या अंतर है! तुलना के लिए, यहाँ एक एकल डेटाबेस डंप का आकार संकुचित है:

1.7G    single-backup.sql.gz

मेरे पास इनमें से 29 ऊपर हैं। नियमित बैकअप की तुलना में लगभग 100 गुना बचत!

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

(मैं शायद खुद को सफल या असफल होने के लिए दो सप्ताह के लायक शाम दूंगा।)

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

संपीड़न जोड़ना पहली बार में आसान लग सकता है, लेकिन ऐसा नहीं है। हमें बहुत सावधान रहने की आवश्यकता है कि आकस्मिक रूप से अनपेक्षित हमलों के लिए रेस्टिक को असुरक्षित न बनाया जाए (यह टीएलएस प्रोटोकॉल के साथ लगातार कई बार हुआ है (हाँ, मुझे पता है कि यह एक अलग स्थिति है))।

पूरी परियोजना में सबसे महत्वपूर्ण बात कोड नहीं है: यह भंडार प्रारूप है। उपयोगकर्ता अपने डेटा के साथ हम पर भरोसा करते हैं, और वे लंबे समय तक रेस्टिक का उपयोग करने के बाद डेटा को पुनर्स्थापित करने में सक्षम होने पर निर्भर करते हैं, इसलिए रिपोजिटरी प्रारूप स्थिरता अत्यंत महत्वपूर्ण है। तो संपीड़न का समर्थन करने के लिए, हमें सबसे पहले भंडार प्रारूप के अगले संस्करण को तय करने (और कार्यान्वित) करने की आवश्यकता है। चर्चा यहाँ है: https://github.com/restic/restic/issues/628

मैं देख सकता हूं कि आप इसे लागू करने के लिए बहुत उत्सुक हैं (और यहां तक ​​​​कि कोड का योगदान भी), लेकिन कृपया इस पर तब तक कोई समय न लगाएं जब तक कि हम रिपोजिटरी प्रारूप पर सहमत न हों और इस समस्या के सभी कोणों पर चर्चा न करें। धन्यवाद!

हटाए गए क्रिप्टो के लिए, मैं इसे मर्ज करने का प्रस्ताव नहीं करने जा रहा हूं। मैंने ऐसा केवल यह देखने के लिए

चूंकि हम json.Unmarshal उपयोग करते हैं,

एल्गोरिदम पसंद मुख्य बिंदु नहीं, समझा: लेकिन भविष्य के संदर्भ के लिए, ब्रॉटली एक मजबूत दावेदार लगता है।

सभी के लिए मुझे पता है कि ब्रॉटली संपीड़न बहुत धीमा है (iirc 60 गुना gzip), इसलिए डेटा के लिए अनुशंसा की जाती है जिसे लिखित और संपीड़ित होने की तुलना में बहुत बार पढ़ा जाता है जो शायद बैकअप के लिए आम नहीं है। लेकिन हाँ, आइए अभी तक विवरण में नहीं जाते हैं :)

यह विभिन्न संपीड़न एल्गोरिदम के लिए एक अच्छा अवलोकन देता है।

ब्रॉटली हमेशा तेज होता है या इसमें बेहतर संपीड़न होता है। संपीड़न स्तर पर निर्भर करता है।

@ibib आप उस निष्कर्ष पर कैसे पहुँचते हैं? मुझे ऐसा लगता है जैसे brotli विशेष रूप से आश्चर्यजनक संपीड़न दरों को प्राप्त नहीं करते हुए अन्य (मिश्रित डेटासेट पर) की तुलना में धीमा दिखाई देता है। शायद यह विशिष्ट प्रकार के संरचित डेटा के लिए बेहतर है?

जैसा कि स्क्वाश बेंचमार्क पर तुलनाओं में सूचीबद्ध किया गया है, इसके द्वारा जाने के लिए तीन पैरामीटर हैं:

• प्राप्त संपीड़न अनुपात: डिस्क स्थान (और I/O से बैकएंड) को बचाने के लिए यह कितनी अच्छी तरह से संपीड़ित होता है।

• संपीड़न गति: महत्वपूर्ण है क्योंकि हम हर बार जब हम एक ब्लॉक जोड़ते हैं तो हम इस ऑपरेशन को करने जा रहे हैं, इसलिए हम वास्तव में कुछ ऐसा चाहते हैं जो एईएस-एनआई और सामान्य I/O के साथ बना रहे ताकि बाधा न बने। हम शायद ऐसा एल्गोरिथम नहीं चुनना चाहते हैं जो डीकंप्रेस की तुलना में धीमी गति से संपीड़ित हो क्योंकि हमारे पास वेब ब्राउज़र के विपरीत उपयोग का मामला है कि ये नए एल्गोरिदम (जैसे zstd , lz4 , brotli ) के लिए अनुकूलित किया गया है (हमारे पास "अक्सर संपीड़ित करें, शायद ही कभी डिकम्प्रेस करें" "एक बार संपीड़ित करें, अक्सर डीकंप्रेस करें") के विपरीत।

• डीकंप्रेसन गति: डीकंप्रेसन गति केवल तभी प्रासंगिक होती है जब हम पुनर्स्थापित कर रहे होते हैं। यदि हम धीमी बहाली के साथ ठीक हैं, तो हम धीमी डीकंप्रेसन गति को स्वीकार कर सकते हैं। दूसरी ओर हमारे पास मेटाडेटा भी है जिसे हम धीरे-धीरे डीकंप्रेस नहीं करना चाहते हैं, जिससे कि दो अलग-अलग एल्गोरिदम भी वारंट हो सकते हैं।

ऐसा प्रतीत होता है कि density सबसे तेज़ है, यद्यपि संपीड़न अनुपात के मामले में विशेष रूप से कुशल नहीं है। एक अड़चन नहीं होने के संदर्भ में ऐसा लगता है कि यह हमें (औसत पर) 2: 1 संपीड़न अनुपात लगभग मुफ्त में मिल जाएगा। अगर हम 4:1 चाहते हैं तो हमें एक अलग एल्गोरिदम चुनना होगा, लेकिन फिर हम बैठे-बैठे उसकी प्रतीक्षा करेंगे।

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

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

इसके अतिरिक्त उच्च संपीड़न अनुपात उपयोगकर्ताओं को अपने डेटा के अधिक संस्करण एक ही स्थान पर रखने की अनुमति देते हैं।

याद रखें कि स्नैपी के साथ मेरे परीक्षणों का परिणाम था: 1) छोटे बैकअप आकार (यह संपीड़ित, सामान्य), और 2) तेज बैकअप और पुनर्स्थापना (कम डेटा सिफरिंग, एचएमएसी और स्थानांतरण)। बहुत सस्ते लैपटॉप का उपयोग करना।

@cfcs मैंने gzip और brotli . की तुलना का हवाला दिया

यहां ब्रॉटली में हमेशा तेज और बेहतर कंप्रेशन होता है।

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

आप "कई बार छोटे इनपुट" के बारे में बहुत अच्छी बात करते हैं।

@viric जिस प्रभाव का आप उल्लेख कर रहे हैं उसे Transfer + Processing नामक अनुभाग के तहत स्क्वैश बेंचमार्क में माना जाता है :-)

@ibib आह,

@ibib क्या आप लिंक कर सकते हैं कि आपको वह चार्ट कहाँ से मिला है?

चार्ट https://quixdb.github.io/squash-benchmark/ से है

मैं brotli और zstd के साथ कुछ परीक्षण कर रहा हूं, और मैंने देखा कि मेरे परिणाम स्क्वैश बेंचमार्क से मेल नहीं खाते। तब मुझे समझ आया कि वह बेंचमार्क 1,5 साल पुराना है।

zstd मेरे लिए बहुत अच्छा काम करता है। तेज़ + उच्च अनुपात, और इसका "स्तर" तेज़ और उच्च अनुपात के बीच एक बहुत बड़ी अवधि की अनुमति देता है। बड़ी बात यह है।

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

हाल ही के बेंचमार्क मुझे मिले: https://github.com/inikep/lzbench

इसलिए मैंने अपने परीक्षण बिस्तर को एक बार फिर LZMA संपीड़न के साथ

35G backup-unencrypted
6.4G    backup-unencrypted.tgz
2.5G    zbackup

प्रभावशाली, है ना?

यह कहने के लिए पर्याप्त है कि zbackup की अपनी सीमाएं और कमियां हैं।

तो, @viric lzbench लिंक के अनुसार, सबसे उपयुक्त कंप्रेसर वह है जो बैकअप को धीमा नहीं करता है (उच्च संपीड़न गति?,> 200 एमबी/सेकंड), जिसका वास्तव में एक अच्छा संपीड़न अनुपात (> = 50) है, है ना?

इसलिए, मैंने ऑर्डर-दर-अनुपात तालिका से परिणामों को फ़िल्टर कर दिया है।

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

| कंप्रेसर का नाम | संपीड़न| डीकंप्रेस.| कॉम्प. आकार | अनुपात |
| --------------- | -----------| -----------| ----------- | ----- |
| जेडएसटीडी 1.1.4 -1 | २४२ एमबी/एस | ६३६ एमबी/एस | ७३६५४०१४ | 34.75 |
| छिपकली 1.0 -30 | २५८ एमबी/एस | 867 एमबी/एस | 85727429 | 40.45 |
| घनत्व 0.12.5 बीटा -3 | २५३ एमबी/एस | 235 एमबी/एस | ८७६२२९८० | 41.34 |
| जिपफेलि 2016-07-13 | 233 एमबी/एस | 451 एमबी/एस | 87931759 | 41.49 |
| पिथी 2011-12-24 -9 | २५७ एमबी/एस | १२६३ एमबी/एस | 90360813 | 42.63 |
| पिथी 2011-12-24 -6 | २९५ एमबी/एस | १२६८ एमबी/एस | ९२०९०८९८ | 43.45 |
| Quicklz 1.5.0 -1 | 346 एमबी/एस | 435 एमबी/एस | 94720562 | 44.69 |
| छिपकली 1.0 -20 | २८४ एमबी/एस | १७३४ एमबी/एस | ९६९२४२०४ | 45.73 |
| पिथी 2011-12-24 -3 | 352 एमबी/एस | १२२२ एमबी/एस | ९७२५५१८६ | 45.89 |
| lzrw १५-जुलाई-१९९१ -4 | २४३ एमबी/एस | 392 एमबी/एस | १००१३१३५६ | 47.24 |
| lzo1x 2.09 -1 | ३९४ एमबी/एस | ५५१ एमबी/एस | 100572537 | 47.45 |
| lz4 1.7.5 | 452 एमबी/एस | २२४४ एमबी/एस | 100880800 | 47.60 |
| Fastlz 0.1 -2 | २४३ एमबी/एस | 469 एमबी/एस | १००९०६०७२ | 47.61 |
| lzo1y 2.09 -1 | 397 एमबी/एस | ५५६ एमबी/एस | १०१२५८३१८ | 47.78 |
| lzo1x 2.09 -15 | ४०६ एमबी/एस | ५४९ एमबी/एस | १०१४६२०९४ | 47.87 |
| घनत्व 0.12.5 बीटा -2 | ४८० एमबी/एस | ६५५ एमबी/एस | १०१७०६२२६ | 47.99 |
| एलजेएफ 3.6 -1 | २५१ एमबी/एस | ५६५ एमबी/एस | १०२०४१०९२ | 48.14 |
| तेज़ 1.1.4 | 327 एमबी/एस | १०७५ एमबी/एस | 102146767 | 48.19 |
| ब्लोस्क्लज़ 2015-11-10 -9 | २२० एमबी/एस | ६९६ एमबी/एस | 102817442 | 48.51 |
| पिथी 2011-12-24 -0 | ३८४ एमबी/एस | १२२१ एमबी/एस | १०३०७२४६३ | 48.63 |
| lzo1x 2.09 -12 | 418 एमबी/एस | 550 एमबी/एस | 103238859 | 48.71 |
| छिपकली 1.0 -10 | 360 एमबी/एस | २६२५ एमबी/एस | १०३४०२९७१ | 48.79 |
| Fastlz 0.1 -1 | २३५ एमबी/एस | 461 एमबी/एस | 104628084 | 49.37 |
| lzrw १५-जुलाई १९९१ -3 | 226 एमबी/एस | 449 एमबी/एस | 105424168 | 49.74 |
| एलजेडएफ 3.6 -0 | 244 एमबी/एस | 550 एमबी/एस | 105682088 | 49.86 |
| lzo1x 2.09 -11 | 424 एमबी/एस | ५६० एमबी/एस | 106604629 | 50.30 |
| lz4फास्ट 1.7.5 -3 | 522 एमबी/एस | २२४४ एमबी/एस | १०७०६६१९० | 50.52 |
| बवंडर 0.6a -1 | 233 एमबी/एस | 334 एमबी/एस | १०७३८१८४६ | 50.66 |
| memcpy | ८६५७ एमबी/एस | ८८९१ एमबी/एस | 211947520 |100.00 |

LZ4 सबसे उपयुक्त कंप्रेसर की तरह दिखता है?

लगता है कि आप lz4 (>=1.7.0 r129) और zstd (>=1.3.0), यदि कोई हो, चाहते हैं। हम इनका उपयोग बोर्गबैकअप के लिए भी करते हैं।

लेकिन zstd lz4 गति से बेहतर . तक एक एकल पूर्णांक के साथ बहुत अनुकूल है
xz संपीड़न की तुलना में। यह घने धीमे उपयोगकर्ताओं को खुश कर देगा
संपीड़न और तेजी से संपीड़न के। उल्लेख नहीं है कि zstd
संपीड़न प्रयास की परवाह किए बिना, बहुत तेजी से विघटित होता है।

lz4 काफी संकीर्ण उद्देश्य वाला है।

शनिवार, 16 दिसंबर, 2017 को 09:50:49 पूर्वाह्न -0800 बजे, TW ने लिखा:

लगता है कि आप lz4 और zstd चाहते हैं, यदि कोई हो। हम इनका उपयोग बोर्गबैकअप के लिए भी करते हैं।

--
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/restic/restic/issues/21#issuecomment -352199097

--
(Escriu-me xifrat si ने PGP को हटा दिया है / यदि आप PGP जानते हैं तो सिफर लिखें)
पीजीपी कुंजी 7CBD1DA5 - https://emailselfdefense.fsf.org/

खैर .. के अनुसार https://github.com/restic/restic/issues/21#issuecomment -250983311 रेस्टिक डिपेंडेंसी फ्री रखने के लिए, zstd अभी के लिए कोई विकल्प नहीं है। इसके अलावा, पेटेंट/लाइसेंसिंग मुद्दों के बारे में कुछ सूत्र हैं।

तालिका के अनुसार, xz और उच्च संपीड़न अनुपात के लिए, यहां तक ​​​​कि कम संपीड़न सेटिंग्स के लिए, सबसे तेज़ संपीड़न लगभग 15 एमबी/सेकंड है।

यदि तेज़ बैकअप की आवश्यकता कम हो जाती है, तो मान लें, >=30MB/सेकंड, हम जोड़ सकते हैं:

| कंप्रेसर का नाम | संपीड़न| डीकंप्रेस.| कॉम्प. आकार | अनुपात |
| --------------- | -----------| -----------| ----------- | ----- |
| xz 5.2.3 -9 | 1.70 एमबी/एस | 56 एमबी/एस | 48745306 | 23.00 |
| xz 5.2.3 -6 | 1.89 एमबी/एस | 58 एमबी/एस | 49195929 | 23.21 |
| xz 5.2.3 -3 | 4.18 एमबी/एस | 55 एमबी/एस | 55745125 | 26.30 |
| जेडएसटीडी 1.1.4 -8 | ३० एमबी/एस | ६०९ एमबी/एस | ६१०२११४१ | 28.79 |
| ज़लिंग 2016-01-10 -2 | 32 एमबी/एस | 136 एमबी/एस | ६१९१७६६२ | 29.21 |
| xz 5.2.3 -0 | 15 एमबी/एस | ४४ एमबी/एस | 62579435 | 29.53 |
| ज़लिंग 2016-01-10 -0 | 38 एमबी/एस | 134 एमबी/एस | 63407921 | 29.92 |
| जेडएसटीडी 1.1.4 -5 | ८८ एमबी/एस | ५५३ एमबी/एस | 64998793 | 30.67 |
| lzfse 2017-03-08 | 48 एमबी/एस | ५९२ एमबी/एस | ६७६२४२८१ | 31.91 |
| libdeflate 0.7 -6 | 64 एमबी/एस | ६०९ एमबी/एस | ६७९२८१८९ | 32.05 |
| ब्रोटली 2017-03-10 -2 | ९८ एमबी/एस | २८९ एमबी/एस | 68085200 | 32.12 |
| जेडएसटीडी 1.1.4 -2 | १८५ एमबी/एस | ५८७ एमबी/एस | 70164775 | 33.10 |
| बवंडर 0.6a -4 | ९१ एमबी/एस | १९७ एमबी/एस | 70513617 | 33.27 |
| libdeflate 0.7 -3 | ९६ एमबी/एस | 602 एमबी/एस | 70668968 | 33.34 |
| एक्सपैक 2016-06-02 -1 | ९८ एमबी/एस | 506 एमबी/एस | 71090065 | 33.54 |
| बवंडर 0.6a -3 | 119 एमबी/एस | १८८ एमबी/एस | 72662044 | 34.28 |
| libdeflate 0.7 -1 | 117 एमबी/एस | ५७० एमबी/एस | 73318371 | 34.59 |
| छिपकली 1.0 -42 | ९० एमबी/एस | ९३८ एमबी/एस | 73350988 | 34.61 |
| जेडएसटीडी 1.1.4 -1 | २४२ एमबी/एस | ६३६ एमबी/एस | ७३६५४०१४ | 34.75 |

कई अपस्फीति कार्यान्वयन हैं, लेकिन अनिश्चित हैं कि क्या वे तुलनीय हैं।
संदर्भ के लिए बायां xz
zstd बहुत आशाजनक लग रहा है। बहुत बुरा कोई गो कार्यान्वयन नहीं है

@viric zstd काफी lz4 गति नहीं है।

लेकिन अगर कोई एकाधिक के बजाय सिर्फ एक कंप्रेसर रखना चाहता है, तो zstd अधिक लचीला है।

मेरी विलंबता को क्षमा करें। कुछ टिप्पणियां:

संपीड़न गति: महत्वपूर्ण है क्योंकि हम हर बार जब हम एक ब्लॉक जोड़ते हैं तो हम इस ऑपरेशन को करने जा रहे हैं, इसलिए हम वास्तव में कुछ ऐसा चाहते हैं जो एईएस-एनआई और सामान्य I/O के साथ बना रहे ताकि बाधा न बने। हम संभवत: ऐसा एल्गोरिथम नहीं चुनना चाहते हैं जो कम्प्रेस होने की तुलना में धीमी गति से संपीड़ित हो क्योंकि हमारे पास वेब ब्राउज़र के विपरीत उपयोग का मामला है कि इन नए एल्गोरिदम (जैसे zstd, lz4, brotli) को अनुकूलित किया गया है (हमारे पास "अक्सर संपीड़ित होता है, शायद ही कभी विघटित होता है" "एक बार संपीड़ित करें, अक्सर डीकंप्रेस करें" के विपरीत)।

नहीं, हार्डवेयर-त्वरित एईएस गति पर संपीड़ित करना आवश्यक नहीं है। संपीड़न आकार के लिए व्यापार समय के बारे में है। यह पूरी तरह से अपेक्षित है कि संपीड़ित बैकअप में अधिक समय लगेगा।

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

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

डीकंप्रेसन गति: डीकंप्रेसन गति केवल तभी प्रासंगिक होती है जब हम पुनर्स्थापित कर रहे होते हैं। यदि हम धीमी बहाली के साथ ठीक हैं, तो हम धीमी डीकंप्रेसन गति को स्वीकार कर सकते हैं। दूसरी ओर हमारे पास मेटाडेटा भी है जिसे हम धीरे-धीरे डीकंप्रेस नहीं करना चाहते हैं, जिससे कि दो अलग-अलग एल्गोरिदम भी वारंट हो सकते हैं।

बैकअप की तुलना में पुनर्स्थापना बहुत कम बार की जाती है, इसलिए डीकंप्रेसन गति उतनी महत्वपूर्ण नहीं है। किसी ने उल्लेख किया है कि वे अक्सर समय के दबाव में किए जाते हैं: यह सच है, लेकिन इसका मतलब यह नहीं है कि पुनर्स्थापना को बैकअप के रूप में तेज़ होना चाहिए, या इसके करीब कहीं भी होना चाहिए।

हमारे पास दो (कम से कम?) विभिन्न प्रकार के डेटा भी हैं: अनुक्रमणिका; और डेटा खंड। दोनों का अलग-अलग उपयोग किया जाता है, और मुझे लगता है कि इस पर चर्चा की जा सकती है कि क्या उनके लिए अलग-अलग एल्गोरिदम चुनने का कोई मतलब होगा।

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

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

मैं इन चिंताओं को समझता हूं, लेकिन मुझे लगता है कि यह एक गलती होगी। कम से कम, रेपो प्रारूप को कई संपीड़न एल्गोरिदम की अनुमति देनी चाहिए ताकि भविष्य में नए जोड़े जा सकें। संपीड़न के लिए प्लग करने योग्य मॉड्यूल होने चाहिए ताकि उपयोगकर्ता उन लोगों का चयन कर सकें जिन्हें वे उपयोग करना चाहते हैं, उदाहरण के लिए मैं डेबियन पैकेज जैसे restic-xz , restic-zstd इत्यादि की कल्पना कर सकता हूं। यदि उपयोगकर्ता चाहें तो इंस्टॉल कर सकते हैं उन एल्गोरिदम का उपयोग करें। बैकअप डेटा के कंप्रेशन को सारगर्भित किया जाना चाहिए ताकि रेस्टिक हैंड एक कंप्रेशन को कुछ डेटा को फंक्शन करता है और इसे वापस कंप्रेस्ड करता है, और रेस्टिक को इस बात की परवाह नहीं करनी चाहिए कि बीच में क्या होता है; डीकंप्रेसन के लिए वही।

यदि तेज़ बैकअप की आवश्यकता कम हो जाती है, तो मान लें, >=30MB/सेकंड, हम जोड़ सकते हैं

यह मुझे उचित लगता है। याद रखें कि स्थानीय बैकअप केवल एक ही प्रकार के होते हैं; संपीड़न गति से नेटवर्क बैकअप के बाधित होने की संभावना कम होती है।

लेकिन, फिर से, यह उपयोगकर्ताओं द्वारा ट्यून करने योग्य होना चाहिए ताकि वे अपनी आवश्यकताओं के लिए उपयुक्त समाधान का चयन कर सकें।

एक बियर के लिए 10$ का इनाम जोड़ा गया: :)

++

यदि कोई अन्य व्यक्ति योगदान देना चाहता है तो यहां बाउंटीसोर्स का लिंक दिया गया है

https://api.bountysource.com/badge/issue?issue_id=6096108

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

आइए तय करें कि हम वहां कब पहुंचेंगे। रिकॉर्ड के लिए: मैं गति बनाम आकार के मामले में उपयोगकर्ता को थोड़ा नियंत्रण देने के साथ ठीक हूं।

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

मुझे परीक्षण में मदद करने में खुशी हो रही है क्योंकि इसे आगे देखा गया है।

@ fd0 मुझे रेस्टिक कोड बेस पर काम करते हुए कुछ समय हो गया है। क्या आपके लिए यह संभव है कि आप एक अच्छे दृष्टिकोण पर एक त्वरित दिशा दें और मुझे कहाँ देखना चाहिए?

@klauspost यह तकनीकी स्तर पर इतना अधिक संपीड़न नहीं जोड़ रहा है, यह करना आसान है, लेकिन हम रेपो प्रारूप को पीछे की ओर संगत तरीके से अपग्रेड करने का प्रबंधन कैसे करते हैं। मैं वर्तमान में संग्रहकर्ता भाग को फिर से लिखने में व्यस्त हूं (ताकि #549 जैसी बदसूरत चीजें चली जाएं), उसके बाद मैं संपीड़न जोड़ना चाहता हूं और फिर रेपो v2 पर स्विच करना चाहता हूं।

हमें किस कंप्रेशन एल्गोरिथम का उपयोग करना चाहिए, इस पर आपका क्या विचार है? मैं तीन मोड का समर्थन करने के बारे में सोच रहा हूं:
1) कोई संपीड़न नहीं
2) "रैखिक समय" संपीड़न (अधिक CPU लोड नहीं जोड़ता है)
3) "अधिकतम संपीड़न"

शायद पहला और दूसरा मोड समान होगा, मुझे अभी तक यकीन नहीं है

यह zstd जैसी किसी चीज़ का उपयोग करने में सक्षम होने के लिए सबसे बढ़िया होगा, लेकिन मूल गो कोड के रूप में। डेमियन ने संकेत दिया कि यह जावा या सी संस्करण को पोर्ट करने के लिए ज्यादा काम नहीं हो सकता है: https://twitter.com/dgryski/status/947259359628738560, क्या ऐसा कुछ है जो मैं आपको कोशिश करने में दिलचस्पी लेने के लिए कर सकता हूं? :)

मैंने zstd प्रारूप युक्ति को देखा है, और मेरे लिए इसे लागू करने के लिए तुच्छ नहीं है (अच्छी तरह से)। जावा स्रोत केवल डीकंप्रेसन हैं।

तेजी से संपीड़न के लिए, LZ4 को बहुत अच्छा करना चाहिए। गो पोर्ट बेहतरीन है। zstd बेहतर होगा, लेकिन मैं एक आजमाए हुए पैकेज के साथ जाऊंगा, जब तक कि आप cgo कार्यान्वयन का उपयोग नहीं करना चाहते।

मध्य सड़क के लिए, अपस्फीति संपीड़न अभी भी अच्छी गति/संपीड़न-वार है। अच्छी तरह से परीक्षण किया, आदि।

उच्च संपीड़न थोड़ा और मुश्किल है। हालांकि, ऐसा लगता है कि github.com/ulikunitz/xz पैकेज में एक देशी LZMA(2) गो कार्यान्वयन है। README पर स्थिरता और प्रदर्शन के बारे में कुछ चेतावनी हैं। xz आवरण की कोई आवश्यकता नहीं है, क्योंकि आपके पास पहले से ही असम्पीडित हैश और आकार है। मैं इसे एक चक्कर दे सकता हूं और देख सकता हूं कि यह कैसे तुलना करता है।

मैंने संपीड़न चरण सम्मिलित करने के लिए प्राकृतिक स्थान खोजने के लिए स्रोत पर एक नज़र डाली। मेरे लिए जो मायने रखता था वह था यहाँ कम्प्रेशन और यहाँ डीकंप्रेसन । लेकिन मुझे संपीड़न की पहचान करने और उसे ट्रैक करने में चुनौती दिखाई देती है।

आप मेरे द्वारा बनाए गए "संपीड़न क्षमता अनुमानक" पर भी नज़र डाल सकते हैं। यह एक त्वरित अनुमान देगा कि डेटा का एक बूँद कितना संकुचित है। यह आमतौर पर> 500MB/s पर संचालित होता है, इसलिए इसका उपयोग हार्ड-टू-कंप्रेस डेटा को जल्दी से अस्वीकार करने के लिए किया जा सकता है।

आप मेरे द्वारा बनाए गए "संपीड़न क्षमता अनुमानक" पर भी नज़र डाल सकते हैं। यह एक त्वरित अनुमान देगा कि डेटा का एक बूँद कितना संकुचित है। यह आमतौर पर> 500MB/s पर संचालित होता है, इसलिए इसका उपयोग हार्ड-टू-कंप्रेस डेटा को जल्दी से अस्वीकार करने के लिए किया जा सकता है।

संपीड़ितता अनुमानक से प्यार करो! असम्पीडित डेटा को संपीड़ित करने के प्रयासों से बचने से बहुत गति प्राप्त होगी।

Zstd में कुछ ऐसा है जो बिल्ट-इन है: [1]

Zstd असम्पीडित डेटा पर तेजी से गुजरता है। कुछ अपेक्षा करें > 1 GB/s

हालांकि मुझे इसका कोई स्पष्ट बेंचमार्क नहीं मिला है।

xz पैकेज lzma के लिए एक अच्छे सौदे की तरह दिखता है। डिफ़ॉल्ट सेटिंग्स के साथ कुछ त्वरित परीक्षण किए:

| एल्गोरिथम | स्तर | आकार देना | बड़ा आकार | मिली | एमबी/एस | अनुपात |
|----------|-------|-----------|-----------|---- ----|-----------|--------|
| lz4 | - | 1000000000 | 625968314 | 5454 | 174.85 | 62.60% |
| फ्लैटेकप | 1 | 1000000000 | 391051805 | 12367 | 77.11 | 39.11% |
| फ्लैटेकप | 5 | 1000000000 | ३४२५६१३६७ | २०१६४ | 47.3 | 34.26% |
| फ्लैटेकप | 9 | 1000000000 | 324191728 | 43351 | 22 | 32.42% |
| lzma2 | | 1000000000 | २९१७३११७८ | १४९४३७ | 6.38 | 29.17% |
| ल्ज़्मा | | 1000000000 | २९१६८८७७५ | १६११२५ | 5.92 | 29.17% |

बहुत ही उचित गति/संपीड़न ट्रेडऑफ। सभी enwik9 पर सिंगल कोर परफॉर्मेंस हैं - मीडियम 10GB कॉर्पस जैसी किसी चीज़ का परीक्षण करने का समय नहीं था।

ऐसा प्रतीत नहीं होता है कि lzma2 अपने वर्तमान कार्यान्वयन में मानक lzma पर बहुत कुछ प्रदान करता है। चूंकि आप छोटे ब्लॉक के साथ काम कर रहे हैं, अंतर काफी छोटा होना चाहिए।

Zstd में कुछ ऐसा है बिल्ट-इन

हां, जैसा कि lz4 और deflate करते हैं, हालांकि, मैंने इसे एक समर्पित फ़ंक्शन के रूप में तेज़ नहीं देखा है।

zstd वास्तव में प्रभावशाली है, इसमें कोई संदेह नहीं है। सीजीओ कार्यान्वयन का उपयोग कर बेंचमार्क:

| स्तर | आकार देना | बड़ा आकार | मिली | एमबी/एस | अनुपात |
|----------|-----------|-----------|-----------|------- -|----------|
| 1 | 1000000000 | 358512492 | 5100 | १८६.९६ | 35.85% |
| 2 | 1000000000 | ३३२२६५५८२ | 6264 | १५२.२४ | 33.23% |
| 3 | 1000000000 | 314403327 | 8099 | 117.75 | 31.44% |
| 4 | 1000000000 | ३१०३४६४३९ | 8588 | 111.04 | ३१.०३% |
| 5 | 1000000000 | ३०५६४४४५२ | १२७३९ | 74.86 | ३०.५६% |
| 6 | 1000000000 | 292551252 | १८५३१ | 51.46 | 29.26% |
| 7 | 1000000000 | २८७४१४८२७ | 23212 | 41.08 | 28.74% |
| 8 | 1000000000 | २८२७८३८०४ | 27811 | 34.29 | २८.२८% |
| 9 | 1000000000 | २८०४३२९०७ | ३१७५२ | 30.03 | २८.०४% |

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

1. ऐसा लगता है कि हम फ़ाइल स्तर पर नहीं, खंड स्तर पर संपीड़न के बारे में बात कर रहे हैं, है ना?
2. यदि ऐसा है, तो यह स्पष्ट रूप से प्रभावशीलता को सीमित करता है क्योंकि एक फ़ाइल के कई हिस्सों में डुप्लिकेट डेटा प्रत्येक खंड के लिए संग्रहीत और संपीड़ित किया जाएगा।
3. हालाँकि, यह स्पष्ट रूप से चंक के आकार पर भी निर्भर करता है।
4. तो, औसत चंक आकार क्या है? ऐसा लगता है कि संपीड़न कितना उपयोगी है, यह एक महत्वपूर्ण कारक है।
5. यदि चंक का आकार काफी छोटा है, तो शायद हमें अत्यधिक संपीड़ित फ़ाइलों के लिए पूर्ण-फ़ाइल, पूर्व- चंकिंग संपीड़न पर विचार करना चाहिए (उदाहरण के लिए करना )। उदाहरण के लिए, 50 एमबी टेक्स्ट फ़ाइल (जैसे लॉग फ़ाइलें, बड़ी ऑर्ग-मोड फ़ाइलें, आदि) एकल फ़ाइल के रूप में अत्यधिक संपीड़ित होने की संभावना है। लेकिन अगर इसे पहले खंडित किया जाता है, और फिर प्रत्येक खंड को व्यक्तिगत रूप से संकुचित किया जाता है, एक सूचकांक साझा नहीं किया जाता है, तो यह संपीड़न (IIUC) की प्रभावशीलता को बहुत सीमित कर देगा।

धन्यवाद।

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

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

@alphapapa

ऐसा लगता है कि हम फ़ाइल स्तर पर नहीं, खंड स्तर पर संपीड़न के बारे में बात कर रहे हैं, है ना?

हाँ, चंक स्तर पर।

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

हम 1MiB का लक्ष्य बना रहे हैं, लेकिन यह 8MiB जितना बड़ा हो सकता है।

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

सबसे पहले मैं खंड स्तर पर संपीड़न को एकीकृत करना चाहता हूं, और देखता हूं कि वास्तविक जीवन परिदृश्यों में यह कितना अच्छा प्रदर्शन करता है। हम बाद में इस विचार पर फिर से विचार कर सकते हैं।

@klauspost कुछ एल्गोरिदम/कार्यान्वयन और आपकी सिफारिशों को बेंचमार्क करने के लिए समय निकालने के लिए बहुत बहुत धन्यवाद, मैं इसकी सराहना करता हूं! जबकि zstd होना अच्छा होगा, मुझे लगता है कि cgo आधार पर पूरी परियोजना के लिए अधिक महत्वपूर्ण नहीं है। और एक संपीड़ितता अनुमानक का उपयोग करना एक अच्छा विचार है, मुझे वह पसंद है।

संपीड़न/विघटन जोड़ने के लिए आपने जिन स्थानों का उल्लेख किया है, वे अच्छे लगते हैं, लेकिन हमें इसके लिए मेटाडेटा को कहीं और ट्रैक करने की आवश्यकता है। मुझे लगता है कि हम शायद पैक हेडर में बाइट में बिट्स का अर्थ जोड़ देंगे, http://restic.readthedocs.io/en/latest/100_references.html#pack -format देखें। यह वह हिस्सा है जिसे बहुत सावधानी से करने की आवश्यकता है।

तो, मैं #1494 के साथ समाप्त करता हूं, फिर हम देखेंगे कि यह हल हो गया है।

@sanmai re: साइड-चैनल: मैंने इसे मूल रूप से लाया।
विभिन्न समाधान सुझाए गए थे, मैं व्यक्तिगत रूप से इससे संतुष्ट रहूंगा:

• संपीड़न के श्वेतसूची/ब्लैकलिस्टिंग उपयोग के लिए कॉन्फ़िगरेशन विकल्प होना (फ़ाइल समावेशन के लिए हमारे पास जो है उसके समान)

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

यह कमाल होगा! :बीयर: +$10

बस इसे वहां फेंकना, लेकिन lzma या किसी भी अधिक सामान्य संपीड़न एल्गो को अलग करना, केवल रन-लम्बाई एन्कोडिंग या शून्य-स्क्वैशिंग के बारे में क्या? या यह पर्याप्त लोगों के लिए पर्याप्त रूप से उपयोगी नहीं होगा?

(इस शिकार में मेरे पास एक कुत्ता है, मैं अक्सर बहुत सारी चुप्पी के साथ विशाल WAV फ़ाइलों का बैकअप ले रहा हूं।)

+$15

बस इसे वहां फेंकना, लेकिन lzma या किसी भी अधिक सामान्य संपीड़न एल्गो को अलग करना, केवल रन-लम्बाई एन्कोडिंग या शून्य-स्क्वैशिंग के बारे में क्या? या यह पर्याप्त लोगों के लिए पर्याप्त रूप से उपयोगी नहीं होगा?

ज्यादातर खाली जगह/विरल फाइलों के साथ वीएम ड्राइव का बैकअप लेने के लिए भी उपयोगी है (सुनिश्चित नहीं है कि रेस्टिक पहले से ही बैकअप का समर्थन करता है/स्पैस फाइलों को बहाल करता है)

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

मैं बस जांचना चाहता था, क्या पहले से ही किसी प्रकार का संपीड़न है? मैंने कई कंप्यूटरों का बैकअप लिया है, जिनमें से एक 50GB डेटा वाला है, और मुझे सर्वर पर बहुत कम संख्या मिलती है:

# du -shc /home/restic/
40G     /home/restic/
40G     total

@Alwaysin यह शायद डिडुप्लीकेशन है , जब तक कि कुछ फाइलों को निश्चित रूप से बाहर नहीं किया गया था।

@rawtaz धन्यवाद, मुझे

@rawtaz द्वारा उल्लिखित बड़े दोहराए गए ब्लॉकों के

@klauspost क्या आपने इसे देखा? https://github.com/mvdan/zstd

हां, लेकिन ईमानदारी से एक स्ट्रीम डिकोडर आसान हिस्सा है। मैंने एफएसई एन/डिकोडिंग समाप्त कर लिया है और एक हफमैन एन्कोडर तैयार है। एक बार हफ़मैन डिकोडिंग हो जाने के बाद एक zstd स्ट्रीम डिकोडर बहुत सीधा होता है, जिसमें पूरा एनकोडर अंतिम भाग होता है।

LZ4 पूरी तरह से पर्याप्त है और एक त्वरित जीत भी होगी।

lz4 क्यों न जोड़ें और zstd का समर्थन करने के लिए एक और पीआर बनाएं?

lz4 क्यों न जोड़ें और zstd का समर्थन करने के लिए एक और पीआर बनाएं?

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

मुझे लगता है कि हम कंप्रेशन के साथ ज्यादा इंतजार नहीं कर सकते। मैंने सर्वर बैकअप के कुछ भंडारों पर कुछ परीक्षण किए हैं, जब मैं भंडार को gzip करता हूं तो मैं वास्तव में कुछ भी नहीं जीतता! @Alwaysin की तरह मैं पहले से ही डिडुप्लीकेशन के साथ 30% जीत चुका हूं।

बैकवर्ड-संगत तरीके के बारे में, आपका मतलब है कि रेस्टिक को पुराने से नए में माइग्रेट करने के लिए दोनों प्रारूपों या टूल को पढ़ना चाहिए? जब रेस्टिक v1.0.0 पर नहीं है तो मेरा मानना ​​है कि बस माइग्रेट करना ठीक है।

मैंने सर्वर बैकअप के कुछ भंडारों पर अभी कुछ परीक्षण किए हैं, जब मैं भंडार को gzip करता हूं तो मैं वास्तव में कुछ भी नहीं जीतता!

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

मैं नहीं देखता कि कैसे एलजेड 4 का उपयोग चीजों को पीछे की ओर संगत बनाता है। संपीड़न संपीड़न है। एकाधिक प्रारूपों का समर्थन क्यों नहीं करते?

तुम सही हो, मैंने इसके बारे में नहीं सोचा था।
हालांकि जब मैं स्रोत को gzip करता हूं तो मैं 30% से अधिक नहीं जीतता, कई डुप्लीकेट के साथ एक बड़ी निर्देशिका पर डिडुप्लीकेशन पहले से ही बहुत कुशल है। लेकिन निश्चित रूप से दोनों के साथ यह प्रभावशाली हो सकता है।
Zpaq के साथ जो संपीड़न और डुप्लीकेशन करता है, मैं थोड़ा और जीतता हूं, इतना नहीं।
मैं संपीड़न के साथ एक शाखा का परीक्षण करने के लिए बहुत खुला हूं, इससे कोई फर्क नहीं पड़ता कि यह संगत नहीं है!

मैं नहीं देखता कि कैसे एलजेड 4 का उपयोग चीजों को पीछे की ओर संगत बनाता है। संपीड़न संपीड़न है। एकाधिक प्रारूपों का समर्थन क्यों नहीं करते?

क्या होता है यदि 2 क्लाइंट एक ही रेपो का उपयोग कर रहे हैं लेकिन उनमें से 1 रेस्टिक के पुराने संस्करण का उपयोग करता है जो संपीड़न का समर्थन नहीं करता है? इस सुविधा को सभी संभावित कोने के मामलों को ध्यान में रखते हुए सावधानीपूर्वक डिजाइन करने की आवश्यकता है।

मैं आधे काम करने वाले समाधान पर कोई संपीड़न पसंद नहीं करूंगा जो पिछले बैकअप को संभव बनाता है।

मुझे लगता है कि संपीड़न जोड़ने के मुद्दे पर पर्याप्त चर्चा हुई है। मैं देख सकता हूं कि यह एक बहुप्रतीक्षित विशेषता है। नया संग्रह कोड समाप्त करने के बाद मैं इससे निपटूंगा (देखें #1494)।

कृपया कोई और टिप्पणी न जोड़ें, धन्यवाद!

@dimejo आप जो कह रहे हैं उसका मेरे द्वारा प्रस्तावित किए गए

मैं यह कहने की हिम्मत करता हूं कि zstd का CGO संस्करण कुछ पोर्टेबल दिखता है :)

मैंने देखा कि विनिर्देश के आधार पर, बहुत संक्षेप में, zstd का गोलांग कार्यान्वयन लिखना कितना संभव होगा।

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

जहां यह मुश्किल हो जाता है, निश्चित रूप से, जहां एंट्रॉपी कोडिंग शुरू होती है। zstd वहां एक उपन्यास दृष्टिकोण का उपयोग करता है जिसे परिमित राज्य एन्ट्रॉपी (एफएसई, [एएनएस] (https://en.wikipedia.org/wiki/Asymmetric_numeral_systems#, का एक रूपांतर) कहा जाता है। जिनमें से केवल एक सी कार्यान्वयन के साथ-साथ मौजूद अन्य एन्ट्रापी बिट्स कोडिंग के साथ लागू कर रहे हैं। कोडिंग Huffman , जिनमें से दो मानक पुस्तकालय में सहित कई कार्यान्वयन हैं,: एक compress.flate में और दूसरे में net.http2.hpack है, जो थोड़ा अलग।

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

zstd मोटे तौर पर gzip या xzip की तुलना में अधिक जटिल है, कोड की लगभग 70k लाइनें (क्लॉक के अनुसार) क्रमशः 36k और 12k की तुलना में। जिसमें परीक्षण शामिल हैं, हालांकि, जो असंख्य हैं: जब उन्हें अनदेखा कर दिया जाता है, तो कार्यान्वयन स्वयं gzip (~ 34k) के साथ तुलनीय होता है।

इसलिए, संक्षेप में, इसे चलते-फिरते लागू किए जाने में कुछ ही समय लगता है। मेरा मानना ​​​​है कि ऐसा इंजन गोलांग की समानता का भी लाभ उठा सकता है क्योंकि zstd "फ्रेम" एक दूसरे से स्वतंत्र हैं। हालांकि, यह मेरे लिए स्पष्ट नहीं है कि फ्रेम का उपयोग कैसे किया जाता है: मैंने जिन धाराओं का परीक्षण किया उनमें केवल एक ( zstd /etc/motd ) या दो ( zstd isos/Fedora-Workstation-Live-x86_64-27-1.6.iso ) फ्रेम थे (जैसा कि binwalk -R "\x28\xb5\x2f\xfd" द्वारा पाया गया), तो शायद वहां ऐसा कोई लाभ नहीं है, क्योंकि ब्लॉक परस्पर जुड़े हुए हैं और कम समानांतर हैं ...

वैसे भी, जब तक कोई यहां वास्तव में बैठना और पोर्ट नहीं करना चाहता है, लेकिन मुझे लगा कि मैं इस बात को पढ़ते हुए जो मिला उसे साझा करूंगा ... यह देखते हुए कि zstd कम्प्रेसर के LZ77 परिवार के LZMA भाग का विस्तार है, इसे चाहिए बंदरगाह के लिए अक्षम्य नहीं हो...

संपीड़न के बारे में कोई अद्यतन? मुझे पता है कि बहुत से लोग प्रतीक्षा करना चाहते हैं zstd , लेकिन lz4 या lzo या lzma को लागू करने में क्या गलत होगा?

अगर कोई अपडेट होता, तो यह समस्या अपडेट हो जाती।

आइए इस बीच लेखक के अनुरोध का सम्मान करने का प्रयास करें, हालांकि:

कृपया कोई और टिप्पणी न जोड़ें, धन्यवाद!

@ fd0 , बस यह बताना चाहता था कि zstd एल्गोरिथम https://github.com/klauspost/compress/tree/master/zstd का शुद्ध गो कार्यान्वयन प्रतीत होता है। मैंने खुद यह कोशिश नहीं की है। लेकिन इसने मुझे रेस्टिक में संपीड़न समर्थन की संभावना के बारे में उत्साहित किया।

मैं गो zstd सामान (गति? कोड गुणवत्ता? रखरखाव?) नहीं जानता, लेकिन C zstd सामान एक बैकअप उपकरण की जरूरत के बारे में है क्योंकि यह तेज/छोटे से धीमी/उच्च संपीड़न की एक विस्तृत श्रृंखला का समर्थन करता है।

यदि हमारे पास बोर्गबैकअप में पहले से ही अन्य सभी संपीड़न एल्गोस (lz4, zlib, lzma) नहीं थे और अब संपीड़न जोड़ना शुरू कर देंगे, तो अनुमान लगाएं कि हम केवल zstd के साथ रह सकते हैं और कोई नहीं।

स्वाद/वरीयता के मामले में, डिफ़ॉल्ट कोई भी नहीं हो सकता है (जैसा कि पहले था) या बहुत तेज़ zstd स्तर (जो कुल मिलाकर अभी भी अधिकांश बैकअप को तेज़ बनाता है क्योंकि स्थानांतरण के लिए कम डेटा है)।

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

धन्यवाद @fd0 और सभी योगदानकर्ताओं को धन्यवाद!

@filippobottega यदि आपने अपने प्रयोग में कोई बड़ा अंतर नहीं देखा, जिसका अर्थ है:

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

दोनों का मतलब यह नहीं है कि संपीड़न व्यर्थ है।

@ThomasWaldmann मुझे पहले कारण से कोई बड़ा अंतर नहीं दिख रहा है।
डेटा आज पहले से ही कई तरीकों से संकुचित है: docx, xlsx, pptx, zip, 7z, jpeg, tif इत्यादि सभी संपीड़ित प्रारूप हैं। और आईएसओ छवियों में संपीड़ित फ़ाइलें भी होती हैं। इस कारण से मुझे लगता है कि रेस्टिक में संपीड़न व्यर्थ है।

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

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

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

@mrschyte

रेस्टिक टू बैकअप लोग किस डेटा का उपयोग कर रहे हैं, इस पर आपका विचार थोड़ा संकीर्ण है।

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

SQL डंप के बारे में क्या?

क्या आप वाकई अपने एसक्यूएल डंप को असम्पीडित करते हैं? मैं उनका बैकअप लेने से पहले अपना सब कुछ देखता हूं, क्योंकि मुझे उन्हें कच्चा रखने की कोई आवश्यकता नहीं है।

स्रोत कोड, डेटा सेट, कच्ची छवियां इत्यादि

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

हालांकि यह डेटा सेट के मूल आकार को कम करने के लिए कुछ नहीं करता है।

यकीनन, यह बैकअप प्रोग्राम का काम नहीं है। इसे मूल डेटा को नहीं छूना चाहिए।

यह उल्लेख नहीं करने के लिए कि एक असम्पीडित प्रारूप को संग्रहीत करना और फिर संपीड़ित करना + डुप्लीकेट करना पहले से संपीड़ित फ़ाइलों को डीडुप्लिकेट करने से बेहतर परिणाम प्राप्त कर सकता है।

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

(मैं यह नहीं कह रहा हूं कि रेस्टिक में कंप्रेशन _bad_ है जब सही तरीके से किया जाता है, मैं सिर्फ यह तर्क दे रहा हूं कि इसे प्राथमिकता की आवश्यकता नहीं है - विशेष रूप से सुस्त प्रदर्शन के मुद्दों की तुलना में - और हमें @ fd0 के समय की कमी का सम्मान करना चाहिए और दृष्टि के संबंध में कामना करता है।)

@mholt मैं सामान्य रूप से सहमत हूं, हालांकि रूट बैकअप (कुछ डंप के माध्यम से या यहां तक ​​​​कि / की सामग्री पर पुनरावृत्ति) करने से मेरे लिए एक अच्छा संपीड़न अनुपात उत्पन्न होता है। जरूरी नहीं

इस परीक्षण का प्रयास करें।

1. SQL डंप या कोई अन्य असम्पीडित फ़ाइल लें। इसे कंप्रेस करें और फिर
   इसे वापस रेस्टिक का उपयोग करें।
2. SQL डेटाबेस से एक तालिका निकालें, दूसरा डंप लें, फिर इसे संपीड़ित करें,
   फिर इसका बैक अप लेने के लिए रेस्टिक का उपयोग करें।

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

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

शुक्रवार 2 अगस्त 2019 दोपहर 1:29 बजे ब्रैंडन श्नाइडर नोटिफिकेशन @github.com
लिखा था:

@mholt https://github.com/mholt मैं सामान्य रूप से सहमत हूँ, हालाँकि कर रहा हूँ
एक रूट बैकअप (कुछ डंप के माध्यम से या यहां तक ​​कि / की सामग्री पर पुनरावृति),
मेरे लिए एक अच्छा संपीड़न अनुपात पैदा करता है। आवश्यक नहीं, कुल मिलाकर
उपयोग किया गया पहले से ही छोटा है, लेकिन मुझे लगभग 50% बचत मिलती है, और यह हमेशा अच्छा होता है
जहां तक ​​अंतिम उपयोगकर्ता का संबंध है "मुफ्त" के लिए।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/restic/restic/issues/21?email_source=notifications&email_token=AC3I762ZVGTTJL4TF3ODZILQCRVIXA5CNFSM4AXPP352YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVWW783576WSमुद्दा
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AC3I767IQQD3CZBIWM37C6TQCRVIXANCNFSM4AXPP35Q
.

क्या आप वाकई अपने एसक्यूएल डंप को असम्पीडित करते हैं? मैं उनका बैकअप लेने से पहले अपना सब कुछ देखता हूं, क्योंकि मुझे उन्हें कच्चा रखने की कोई आवश्यकता नहीं है।
यकीनन, यह बैकअप प्रोग्राम का काम नहीं है। इसे मूल डेटा को नहीं छूना चाहिए।

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

संपीड़न को शीर्ष रेस्टिक के डुप्लीकेशन पर केवल एक अतिरिक्त अनुकूलन के रूप में देखा जा सकता है, लेकिन वे एक-दूसरे के साथ असंगत लगते हैं यदि अलग से किया जाता है... यह सुझाव देना कि किसी को फ़ाइलों का बैकअप लेने से पहले उन्हें संपीड़ित और प्रीप्रोसेस करना चाहिए, सब कुछ एक वर्कफ़्लो पर वापस ले जाता है जहाँ आप भी कर सकते हैं इसके बजाय बस rsync/rclone का उपयोग करें, तो पहले स्थान पर रेस्टिक का उपयोग क्यों करें?

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

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

अब ऐसे मामले हैं जहां भंडारण से पहले संपीड़ित करना समझ में आता है, खासकर धीमी भंडारण प्रणालियों पर बहुत संकुचित डेटा के साथ, लेकिन यह मेरे अनुभव में नियम से अधिक अपवाद है।

+1 संपीड़न वास्तव में मेरी मदद करेगा! एक सॉफ्टवेयर इंजीनियर के रूप में काम करते समय मैं अपने पूरे होम फोल्डर का बैकअप लेता हूं, जिसमें बहुत सारे असम्पीडित स्रोत कोड होते हैं (और गतिशील भाषाओं में, जैसे रूबी या पायथन, यह लगभग हमेशा स्रोत कोड होता है - यहां तक ​​​​कि अधिकांश निर्भरताएं भी)।

घर पर मैं अपने पूरे / का बैक अप लेता हूं, जिसमें कई चीजें शामिल हैं जो संपीड़न से लाभान्वित होती हैं, जैसे कि बायनेरिज़, मैन फाइल्स, रिसोर्स फाइल्स, आदि।

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

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

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

अंत में, मैं क्लाउड प्रदाता को 4tb से थोड़ा अधिक बैकअप देता हूं और मेरी अपलोड गति वैसे भी कमजोर है, इसलिए एक बोनस संपीड़न के रूप में मेरी बैक अप प्रक्रिया तेज हो जाएगी, धीमी नहीं - मेरा सीपीयू मेरे खराब वीडीएसएल कनेक्शन के साथ बना रह सकता है .

हां, मैं यहां अन्य सभी से सहमत हो सकता हूं। संपीड़न बहुत महत्वपूर्ण है और मुझे वास्तव में कोई तर्क नहीं दिखता कि रेस्टिक के पास क्यों नहीं होना चाहिए।

@mholt मैं
मेरे टूल चेन कंप्रेशन में रेस्टिक डिडुप्लीकेशन से पहले आता है क्योंकि, उदाहरण के लिए, मैं स्रोत नियंत्रण के रूप में टीएफएस का उपयोग करता हूं और सभी स्रोत पहले से ही एसक्यूएल बैकअप में संकुचित होते हैं और एमएसआई सेटअप फाइलों या 7z अभिलेखागार में एप्लिकेशन छवियों को संपीड़ित किया जाता है। मुझे हर दिन डेल्टा प्राप्त करने और एक सुरक्षित आपदा वसूली योजना को लागू करने के लिए इसे क्लाउड पर भेजने के लिए केवल एक तेज़ और सरल तरीके की आवश्यकता है।
मुझे लगता है कि @ fd0 को उत्पाद में अन्य जटिलता जोड़ने की कोशिश करने के बजाय मुद्दों को हल करने के लिए अपना समय केंद्रित करने की आवश्यकता है।

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

/ : 1053136 फाइलें, 92.9 जीआईबी

• बोर्ग, कोई नहीं: १७:२७ मिनट, ६४.१ जीआईबी
• बोर्ग, जेडएसटीडी: १९:२९ मिनट, ४०.६ जीआईबी
• रेस्टिक: 09:45 मिनट, 62.4 जीआईबी

/home : 221338 फाइलें, 58.3 जीआईबी

• बोर्ग, जेडएसटीडी: 09:06 मिनट, 30.7 जीआईबी
• रेस्टिक: 04:36 मिनट, 39.4 GiB
  मैंने यहाँ बिना कंप्रेशन के बोर्ग को छोड़ दिया, क्योंकि यह मोटे तौर पर रेस्टिक के समान ही है जहाँ तक स्टोरेज स्पेस का सवाल है।

सबसे पहले, मैं उस परीक्षण मामले में लगभग दोगुना तेज होने के लिए रेस्टिक की सराहना करना चाहता हूं। बोर्ग धीमा होने के अलावा, यह दिलचस्प हो सकता है कि संपीड़न केवल कुल बैकअप अवधि (+11%) में ~2 मिनट जोड़ता है, लेकिन / केस (-35) के लिए संग्रहीत किए जाने वाले डेटा को काफी कम कर देता है %)। मेरी होम निर्देशिका के मामले में, भंडारण बचत लगभग 20% है।

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

@nioncode यदि मेरी गणना सही है, तो आप लगभग 100/150MB/s का बैकअप लेते हैं। यह नीचे है जिसे zstd कंप्रेस कर सकता है। चूंकि संपीड़न async है, वास्तव में कोई मंदी नहीं होनी चाहिए। यह थोड़ा तेज भी हो सकता है क्योंकि लिखने के लिए कम है।

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

आइए इस धागे को अव्यवस्थित न करें कि कौन कैसे काम करता है। काफी हो गया।

संपीड़न एक ऐसी सुविधा है जो बहुत से लोग चाहते हैं (स्वयं शामिल) और यह धीमी-मध्यम इंटरनेट कनेक्टिविटी के मामले में बैकअप स्टोरेज और अपलोड समय दोनों को बचा सकता है, कुछ लोगों के लिए 30% या उससे भी अधिक।

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

बहरहाल, दोनों पक्षों ने बात की है।

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

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

मुझे विश्वास नहीं है कि कोई भी संपीड़न अनिवार्य बनाने के बारे में बात कर रहा है।

मेरा विशेष उपयोग मामला सीएसवी और एसक्यूएल डंप के बड़े सेट का बैक अप ले रहा है। ये फ़ाइलें बहुत कम्प्रेसेबल होंगी... और मैं उन्हें प्रीकंप्रेस नहीं करना चाहता/चाहती।

मैं वास्तव में संपीड़न सुविधा रखना चाहता हूं क्योंकि मैं प्रत्येक जीबी ऑनलाइन स्टोरेज के लिए भुगतान करता हूं

चूंकि यह चर्चा अब थोड़ी अधिक सक्रिय हो रही है, इसलिए मैं अपने कुछ दोस्तों के पैच किए गए रेस्टिक संस्करण के साथ कुछ निष्कर्ष साझा करना चाहता हूं। उन्होंने रेस्टिक में संपीड़न जोड़ा (जहां तक ​​​​मुझे पता है कम या ज्यादा त्वरित और गंदा) और मैं उन्हें इस पोस्ट के बारे में सूचित करूंगा ताकि अगर कोई दिलचस्पी लेता है तो वे कार्यान्वयन विनिर्देशों पर टिप्पणी कर सकते हैं।
मेरा उपयोग मामला कुछ वास्तव में बदसूरत बैंकिंग सॉफ़्टवेयर है जिसका अपना डेटाबेस प्रारूप है। हमें इस सॉफ़्टवेयर का उपयोग नियामक कारणों से करना पड़ता है और हमारे पास जो डेटा है वह बड़ी फ़ाइलों के कई टीबी हैं जिन्हें उनके मूल आकार के 90% तक संकुचित किया जा सकता है। तो, स्पष्ट रूप से, संपीड़न हमें बैकअप स्टोरेज, बैकअप समय और पुनर्स्थापना समय में बहुत कुछ बचाएगा।
रेस्टिक अपस्ट्रीम की तुलना करते समय मेरे निष्कर्ष, संपीड़न के साथ पैच किए गए रेस्टिक और टार के साथ हमारे वर्तमान बैकअप समाधान यहां पाए जा सकते हैं: https://gist.github.com/joerg/b88bf1de0ce824894ffc38f597cfef5f

| उपकरण | बैकअप समय (एम: एस) | पुनर्स्थापना समय (एम: एस) | बैकअप स्पेस (जी) | बैकअप स्पेस (%) | बैकअप (एमबी/एस) | पुनर्स्थापित करें (एमबी/एस) |
| --------------------------- | ----------------- | ------------------ | ---------------- | ---------------- | ------------- | -------------- |
| टार | 4:42 | 5:19 | 11 | 9.6% | 404 | 357 |
| रेस्टिक S3 लोकल अपस्ट्रीम | 10:04 | 30:56 | 102 | 89.5% | १८९ | 61 |
| रेस्टिक S3 लोकल कंप्रेस | 5:43 | 19:28 | 8.6 | 7.5% | 332 | 98 |
| रेस्टिक लोकल अपस्ट्रीम | 8:33 | 26:06 | 102 | 89.5% | 222 | 73 |
| रेस्टिक लोकल कंप्रेस | 5:21 | 16:57 | 8.6 | 7.5% | 355 | 112 |
| रेस्टिक S3 रिमोट अपस्ट्रीम | 17:12 | 46:06 | 102 | 89.5% | 110 | 41 |
| रेस्टिक S3 रिमोट कंप्रेस | 5:27 | 21:42 | 8.6 | 7.5% | 349 | 88 |

मुझे लगता है कि किसी भी प्रकार के वैकल्पिक संपीड़न के साथ रेस्टिक बड़े पैमाने पर लाभ प्राप्त करेगा क्योंकि यह बहुत कुछ सब कुछ कम कर देता है।

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

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

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

नमस्ते @joerg , अपने परीक्षण साझा करने के लिए धन्यवाद।
क्या आपने टैर संपीड़न कार्य के आउटपुट को रेस्टिक के साथ बैकअप करने का प्रयास किया है?
मैं "Restic S3 Remote Compress" और "Tar" + "Restic S3 Remote Upstream" की तुलना करने के लिए उत्सुक हूं।
इसके अलावा आप जो कहते हैं वह वास्तव में सच नहीं लगता है:

मुझे लगता है कि किसी भी प्रकार के वैकल्पिक संपीड़न के साथ रेस्टिक बड़े पैमाने पर प्राप्त होगा क्योंकि यह सब कुछ बहुत कम कर देता है

परीक्षण के परिणामों को देखकर, ऐसा लगता है कि स्थानीय बैकअप के लिए रेस्टिक द्वारा आवश्यक CPU समय 2x लंबा और पुनर्स्थापना पर 6x लंबा है। टार की तुलना में वास्तव में अच्छा नहीं है।

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

परीक्षण के परिणामों को देखकर, ऐसा लगता है कि रेस्टिक द्वारा उपयोग किया जाने वाला CPU समय स्थानीय बैकअप में 2x धीमा और पुनर्स्थापना पर 6x धीमा है। टार की तुलना में वास्तव में अच्छा नहीं है।

मुझे यहाँ आपकी बात पर पूरा यकीन नहीं है। रेस्टिक टार की तुलना में धीमा है, निश्चित है, लेकिन कंप्रेशन के साथ रेस्टिक बिना रेस्टिक के हमेशा तेज होता है, इसलिए रेस्टिक को स्पष्ट रूप से फायदा होगा।

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

@joerg क्या आपके मित्र पुल अनुरोध खोल सकते हैं और संपीड़न के साथ अपने पैच को सार्वजनिक रूप से उपलब्ध करा सकते हैं? वे किस संपीड़न एल्गोरिदम का उपयोग करते हैं?

@joerg @thedaveCA
मैं क्षमा चाहता हूं, मैंने @joerg के दावे का अर्थ गलत समझा। स्पष्ट रूप से कंप्रेशन के साथ रेस्टिक कंप्रेशन के बिना रेस्टिक से बेहतर है। अब मेरा प्रश्न है: टार + रेस्टिक कंप्रेशन के साथ रेस्टिक की तुलना में बेहतर है या नहीं?

कृपया ध्यान दें कि हम नंगे टार अभिलेखागार का उपयोग नहीं कर रहे हैं, लेकिन एक विशेष समानांतर ज़िप कार्यान्वयन के साथ टार वाले gzipped हैं, अन्यथा डेटा के टेराबाइट्स को संग्रहीत करने में अभी लगने वाले "बस" घंटों के बजाय दिन लगेंगे: https://gist.github। com/joerg/b88bf1de0ce824894ffc38f597cfef5f#tarpigz
@shibumi मैंने उन्हें इस मुद्दे और मेरी पोस्टिंग के बारे में सूचित किया है, इसलिए अब यह उन पर निर्भर करता है कि वे इसमें शामिल होना चाहते हैं या नहीं। व्यक्तिगत रूप से, मुझे आशा है कि वे उस पुल अनुरोध को खोलेंगे...

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

आइए एक ज्ञात समस्या न बनाएं जहां कोई नहीं है, है ना?

(मुझे लगता है कि इस समस्या का पहले ही उल्लेख किया जा चुका है, और संभवत: एक बार भी नहीं। फिर भी यह मुद्दा खुला है, जहां मुझे ऐसा लगता है कि इसे एक बार और सभी के लिए बंद कर दिया जाना चाहिए।)

आप इस मुद्दे को स्पैम क्यों कर रहे हैं? :( इस पर कई बार चर्चा की गई है कि यह लगभग ऑफटॉपिक है। आपको संपीड़न को सक्षम करने के लिए मजबूर नहीं किया जाएगा !!

इसके अलावा, मुझे लगता है कि आपके हमले के विचार के लिए हमलावर को संपीड़ित और एन्क्रिप्टेड होने के लिए डेटा को नियंत्रित करने में सक्षम होना चाहिए (हालांकि मुझे यकीन नहीं है!) https://en.m.wikipedia.org/wiki/CRIME

लेकिन किसी भी मामले में, भले ही यह एक सुरक्षा चिंता का विषय हो, कोई व्यक्ति केवल उस भंडारण के लिए संपीड़न का उपयोग करना चाह सकता है जो केवल भंडारण स्थान को बचाने के लिए उसके अपने नियंत्रण में है।

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

लेकिन मुझे लगता है कि एक संपीड़न को इस तरह से जोड़ना कि इसे एन्क्रिप्शन के साथ कभी भी उपयोग नहीं किया जाएगा, एक व्यवहार्य विकल्प है।

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

वास्तव में CRIME को सिफरटेक्स्ट की लंबाई जानने की जरूरत है, जो मूल रूप से रेस्टिक में असंभव है।
कोई "सुरक्षित" बैकअप प्रोग्राम भी नहीं है। यदि बैकअप फ़ाइलें तृतीय पक्षों द्वारा एक्सेस की जा सकती हैं, तो हमेशा एक मौका होता है कि कोई व्यक्ति छेड़छाड़ कर सकता है या खराब कर सकता है, डेटा पढ़ें।
इसलिए यह कहना कि संपीड़न इसे बदतर बना देता है, बस बेवकूफी है।

वास्तव में CRIME को सिफरटेक्स्ट की लंबाई जानने की जरूरत है

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

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

कोई "सुरक्षित" बैकअप प्रोग्राम नहीं है

इसके बाद इसे अपडेट की जरूरत है।

सुरक्षित-बाय-डिफॉल्ट पर भी ध्यान दें।

रेस्टिक स्टोर केवल टुकड़ों को पैक करते हैं, इसलिए टुकड़ों का आकार स्पष्ट नहीं है
किसी के पास चाबी नहीं है।

शुक्र, अगस्त 09, 2019 को 02:09:23 पूर्वाह्न -0700 पर, एलेक्सी कोप्यट्को ने लिखा:

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

आइए एक ज्ञात समस्या न बनाएं जहां कोई नहीं है, है ना?

--
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/restic/restic/issues/21#issuecomment -519844526

--
(Escriu-me xifrat si ने PGP को हटा दिया है / यदि आप PGP जानते हैं तो सिफर लिखें)
पीजीपी कुंजी 7CBD1DA5 - https://emailselfdefense.fsf.org/

जो लोग इन सुरक्षा चिंताओं के बारे में अधिक जानना चाहते हैं, उनके लिए http://www.iacr.org/cryptodb/archive/2002/FSE/3091/3091.pdf का वर्णन करने वाला एक अच्छा पेपर है
मेरी समझ में यदि फ़ाइल को खंडित किया जाता है और फिर संपीड़ित और एन्क्रिप्ट किया जाता है तो एक दोष हो सकता है। लेकिन अगर फ़ाइल को चंक करने से पहले संपीड़ित किया जाता है, तो यह किसी भी अन्य की तरह एक बाइनरी फ़ाइल है और वे सादे टेक्स्ट हमले बेकार हो जाते हैं।

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

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

रेस्टिक स्टोर केवल टुकड़ों को पैक करते हैं, इसलिए चाबियों का आकार किसी के पास चाबी नहीं होने के कारण स्पष्ट नहीं होता है

कि एक राहत की बात है।

मेरी बात अभी भी कायम है: कि ऐसे कई तरीके हैं जिनसे कोई प्रोग्राम में एक छिपी हुई कमजोरी को जोड़ सकता है जब यह एन्क्रिप्शन के साथ एक साथ संपीड़न लागू करता है, इसलिए सबसे अच्छा है कि इसे बिल्कुल भी न जोड़ें। यहां तक ​​कि एन्क्रिप्शन _विशेषज्ञों_ ने TLS के बारे में निर्णय लेते हुए संपीड़न को हटाना चुना। मान लीजिए कि उनके पास भी ऐसा ही तर्क था।

बीटीडब्ल्यू.:

However, it is important to note that these attacks have little security impact on, say, a bulkencryption application which compresses data before encrypting

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

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

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

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

@sanmai , मुझे यह उदाहरण नहीं मिलता है

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

इसका क्या मतलब है? कि कोई यह अनुमान लगा सकता है

असल में, बैक अप लेने से पहले फ़ाइलों को gzipping के बारे में कैसे? क्या यह सुरक्षा भेद्यता भी खोलता है?

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

मुझे विश्वास नहीं है कि संपीड़न एन्क्रिप्शन को काफी कम सुरक्षित बना सकता है।

अधिकांश संपीड़न साइड-चैनल हमलों में कई कारक शामिल होते हैं:
1) हमलावर इनपुट को नियंत्रित कर सकता है
2) हमलावर आउटपुट के आकार का निरीक्षण कर सकता है
3) इनपुट डेटा में छोटे परिवर्तन के परिणामस्वरूप आउटपुट आकार में मापन योग्य परिवर्तन होते हैं
4) हमलावर इनपुट को बदल सकता है और सैकड़ों हजारों बार पुनः प्रयास कर सकता है

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

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

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

तथ्य यह है कि, ऐसे सैकड़ों या हजारों उपयोगकर्ता हैं जो बिना किसी डाउन-साइड के एक संपीड़न सुविधा से लाभान्वित होंगे। क्या हम कृपया इस 5 साल पुराने मुद्दे को उन डेवलपर्स पर छोड़ दें जो इस पर काम कर रहे हैं?

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

मैंने वृद्धिशील बैकअप की चार पीढ़ियों के साथ परीक्षण किया और मेरी फाइलों को 7:1 का संपीड़न मिलता है और साथ में डुप्लीकेशन के साथ मैं> 20:1 प्राप्त करता हूं। मैं इसे अनदेखा नहीं कर सकता क्योंकि मैंने पहले ही कहा था कि मैं प्रति जीबी अपने ऑनलाइन बैकअप स्टोरेज के लिए भुगतान करता हूं।

root<strong i="7">@xxxx</strong>:~# borg list
2019-08-08_14:37                     Thu, 2019-08-08 14:37:10 [5e113a8102f2bd7e40d100343f849dc73843d145011c7214d5fa0895927eb6d1]
2019-08-08_22:28                     Thu, 2019-08-08 22:28:21 [17d815d000212a576610b2fd5688ab87cce00039bb89f63722c6a7819dec1821]
2019-08-09_02:00                     Fri, 2019-08-09 02:00:23 [217c53b07f30dfbca584c49468cfa624a2445a005890220509c97715f7007e81]
2019-08-10_02:00                     Sat, 2019-08-10 02:00:10 [5dd45b8ccf0aa382bf00d5b08e1d5d88daae014f0a1a42b3e2b0fc368623bba0]
root<strong i="8">@xxxx</strong>:~# borg info
Repository ID: xxxx
Location: ssh://xxxx
Encrypted: Yes (repokey)
Cache: /var/lib/borg/cache/xxxx
Security dir: /var/lib/borg/security/xxxx
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
All archives:               69.02 GB             11.24 GB              2.80 GB

                       Unique chunks         Total chunks
Chunk index:                    9227                41812

इसका क्या मतलब है? कि कोई _अनुमान_ कर सकता है कि एन्क्रिप्टेड स्नैपशॉट में ये फ़ाइलें केवल आकार को देखकर हैं? यह मानता है कि फ़ाइलें अकेले या अन्य ज्ञात फ़ाइलों के साथ संपीड़ित हैं। लेकिन फिर वही अनुमान एक अनएन्क्रिप्टेड शापशॉट के साथ किया जा सकता है।

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

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

क्या संपीड़न जोड़ने से रेस्टिक को किसी अतिरिक्त भेद्यता का पता चलता है, यह देखते हुए कि यह पहले से ही डुप्लीकेशन करता है?

यदि आपकी चिंता एक हमलावर है जो असम्पीडित आकार का अनुमान लगाने के लिए संपीड़ित ब्लॉक आकारों पर अनुमान लगा रहा है, ठीक है, लेकिन क्या संपीड़न इसे और खराब कर देता है? क्या एक हमलावर के पास समान बुनियादी जानकारी नहीं होगी?

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

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

मुझे समझ में नहीं आता कि आप एन्क्रिप्टेड चंक के आकार को देखकर फ़ाइल उपस्थिति का अनुमान लगाने के बारे में काल्पनिक सुरक्षा चिंताओं के बारे में क्यों चर्चा करते हैं ..,

आप लोग ZIP या GZ का उपयोग करते हैं? तब आपको ठीक होना चाहिए।

आपको लगता है कि ईरानी अधिकारी आकार के आधार पर मेरी सामग्री का अनुमान लगा सकते हैं? तो बस संपीड़न (!) का उपयोग न करें। इसका सीधा मतलब यह नहीं है कि संपीड़न उपलब्ध नहीं होना चाहिए।

मुझे लगता है कि हमने रेस्टिक में संपीड़न जोड़ने के सभी प्रासंगिक कोणों को कवर किया है, आपके सभी इनपुट के लिए बहुत-बहुत धन्यवाद।

मुझे लगता है कि हमें संपीड़न जोड़ना चाहिए और इसे डिफ़ॉल्ट रूप से सक्षम करना चाहिए, लेकिन उपयोगकर्ताओं को संपीड़न को अक्षम करने की अनुमति देना चाहिए। कृपया तब तक धैर्य रखें जब तक मेरे पास इस पर काम करने के लिए कुछ और समय न हो।

मुझे ऐसा लगता है कि यह चर्चा हाथ से निकल गई है, इसलिए मैं इस मुद्दे को अभी के लिए बंद कर रहा हूं। यदि आप इस चर्चा को जारी रखना चाहते हैं, तो कृपया मंच पर जाएँ । धन्यवाद!