عند تنفيذ ذلك ، أضف معايير وألق نظرة خاصة على استخدام الذاكرة مع -benchmem و benchcmp!

lz4 ، lzo ، lzma ، null. bz2 بطيء نوعًا ما.

لاذع سريع مع ضغط معتدل

إذا تم الضغط على كل قطعة ، فيجب توخي الحذر حتى لا تترك النسخ الاحتياطية مفتوحة أمام هجمات وضع العلامات المائية / بصمات الأصابع.

هذه هي نفس المشكلة التي ناقشناها فيما يتعلق ببصمات الأصابع لعملية إلغاء تكرار CDC:
باستخدام CDC "ساذج" ، يمكن التحقق من وجود ملف "نص عادي معروف" داخل النسخة الاحتياطية إذا كان يمكن للمهاجم ملاحظة حجم الكتل الفردية ، وذلك باستخدام CDC في الملف بالتوازي ومقارنة الكمية الناتجة من الأجزاء والأفراد أطوال مقطوعة.
كما تمت مناقشته سابقًا ، يمكن تخفيف ذلك إلى حد ما عن طريق تمليح خوارزمية CDC بقيمة سرية ، كما هو الحال في العلية.

مع CDC المملح ، أفترض أن الضغط سيحدث على كل قطعة فردية ، بعد تقسيم الملف الإشكالي إلى أجزاء. قطع Restic في نطاق 512 كيلوبايت إلى 8 ميجابايت (ولكن ليست موزعة بالتساوي - أليس كذلك؟).

• يعرف المهاجم أن خوارزمية CDC تستخدم ملحًا سريًا ، لذلك يولد المهاجم مجموعة من الأجزاء تتكون من أول 512 كيلوبايت إلى 8 ميجابايت من الملف ، واحدة لكل قطعة طول صالحة. يستطيع المهاجم أيضًا تحديد أطوال القطع المضغوطة.
• ثم يضغط المهاجم ذلك الجزء باستخدام خوارزمية الضغط.
• يقارن المهاجم أطوال القطع الناتجة بالجزء الأول في مجموعات النسخ الاحتياطي الثابتة.
• إذا تم العثور على طول كتلة مطابق ، يكرر المهاجم التمرين مع القطعة التالية ، والقطعة التالية ، والقطعة التالية ، ... والقطعة التالية.
• في اعتقادي أنه مع وجود ملفات كبيرة بما فيه الكفاية ، وبالنظر إلى حقيقة أن خوارزمية CDC "منحازة" (في غياب أفضل الكلمات) نحو إنشاء كتل تبلغ حوالي 1 ميجابايت ، فسيكون هذا كافيًا للتأكد مما إذا كان الملف موجود في النسخة الاحتياطية.

كما هو الحال دائمًا ، تيار من الوعي بجنون العظمة وغير علمي للغاية.

أفكار؟

مثير للإعجاب. لا أفهم كيف يعتمد الهجوم الذي تصفه على استخدام الضغط ، هل هو ضروري على الإطلاق؟ ألا يعمل هذا الهجوم بضغط وبدون ضغط؟

في الوقت الحالي أفكر في كيفية تنفيذ # 56. ما هي أفكارك حول تجميع عدة نقاط في ملف واحد؟

الإجراءات الدقيقة لتنفيذ CDC غير واضحة بعض الشيء بالنسبة لي:

• هل تقسم على حدود بايت دقيقة أم أن الكتل 512 كيلوبايت - 8 ميجابايت "مقربة" إلى مضاعف لشيء ما؟
• (السؤال الحقيقي هو: هل هناك (15 * 512 * 1024) / (16 بسبب AES-CTR) حجم قطعة محتمل أم أقل؟)
• لدي فضول أيضًا حول مدى جدوى إعادة بناء البذرة إذا أعطيت قطعًا كافية من ملف معروف - ليست مجدية جدًا ، على ما أظن؟

للإجابة على سؤالك الأول:
باستخدام CDC المصنف ، تعتمد "بصمة الإصبع" على (المحتوى + البذرة السرية) ، ولكن الاختلاف هو أنه عندما يتم الضغط _ بعد_ التقسيم ، وبافتراض أنه يمكنك تمييز الكتل الفردية عن بعضها البعض ، يكون لديك بصمة / العلامة المائية (معدل ضغط كتلة معينة) التي تعتمد فقط على المحتوى ، في هذا السيناريو نص عادي معروف.

مثال:
إذا كان الملف الذي يحمل علامة مائية يحتوي على 64 ميجابايت (8-128 قطعة) من "AAAA" ، ثم 64 ميجابايت من "ABCABCABCABC" ، فإن 64 ميجابايت من البيانات العشوائية ، ستكون الأجزاء 16-256 الأولى صغيرة جدًا (لأن هذه التسلسلات تنضغط جيدًا جدًا ، حيث يتم ضغط الأجزاء 8-128 بشكل سيئ نوعًا ما).
سيكون المهاجم أيضًا قادرًا على العمل بشكل عكسي ، بدءًا من الجزء الأخير (24 - 384) وضغط 512 كيلو بايت - 8 ميجا بايت حتى يجد المهاجم حجمًا ينضغط إلى نفس حجم القطعة بالضبط. بمجرد العثور على ذلك ، يتم ضغط 512 كيلو بايت -8 ميجا بايت من النص العادي الأصلي "التالي" لمعرفة أي طول يتم ضغطه على طول الكتلة من الثانية إلى الأخيرة (23 - 383) ، وهكذا ، حتى يلتقي المهاجم قطع صغيرة ناتجة عن سلاسل "AAAA".
هذا لا يمكّن الخصم من التأكيد بشكل إيجابي على تخزين ملف ذي علامة مائية في النسخة الاحتياطية ، لكنني أعتقد أنه من الناحية الإحصائية يمكنه إنشاء نتائج واضحة تمامًا ، مع توفير بيانات كافية.

أرى بعض الحلول المحتملة ، ربما لديك المزيد من الأفكار:

• السماح بإيقاف الضغط و / أو إلغاء البيانات المكررة لأدلة معينة (ربما يكون هذا هو الأسهل في التنفيذ)
• قم بترتيب قواميس الضغط بشكل عشوائي (لم أفكر حقًا في هذا ، ولكن يبدو أنها فكرة مثيرة للاهتمام)
• امنع المهاجمين من تعلم أطوال الأجزاء المضغوطة الفردية ، على سبيل المثال عن طريق الحشو (الذي قد يكون مكلفًا للغاية) أو عن طريق تجميع عدة قطع صغيرة معًا وحشو الأجزاء المتبقية (أكثر تعقيدًا ، ولكن أكثر كفاءة)

شكرا لتوضيحك ، أنا أفهم السيناريو الخاص بك الآن.

من المحتمل ألا يكون هناك أي خيار لإيقاف ميزة إلغاء البيانات المكررة في restic ، لأنه من الصعب فعل ذلك نظرًا للهيكل الحالي للبرنامج ، فقد تم إنشاء restic حول CDC. تعد إضافة دعم الضغط ذات أولوية منخفضة في الوقت الحالي وليست هدفًا لإصدار ألفا.

سيتم تنفيذ فكرتك الثالثة في رقم 56 (تجميع أجزاء متعددة معًا) ، وأنا أعمل على ذلك الآن. وربما سأضيف المزيد من الوثائق إلى doc/Design.md فيما يتعلق بكيفية عمل chunker.

شكرا مرة أخرى على طرح هذا السيناريو!

لست متأكدًا مما إذا كنت أتبع cfcs - أليس الحجم المضغوط تمامًا مثل تجزئة سيئة بشكل لا يصدق؟ بالنظر إلى حجم الملف المضغوط ، فإن عدد المدخلات الممكنة التي تولد حجم الملف هذا لا نهائي. لكن ربما لا أفهم.

على أي حال. أردت فقط توجيهك بلا خجل إلى مكتبة انكماش / gzip معدلة قمت وضع ضغط زمني ثابت ، والذي يتيح سرعة نقل تصل إلى 150 ميجابايت / ثانية / أساسية على أي بيانات ، مما يجعلها غير مرئية تقريبًا في سيناريوهات النسخ الاحتياطي. هناك أيضًا حزمة gzip موازية تضغط gzip الملفات الأكبر حجمًا على عدة مراكز.

klauspost: نضع في اعتبارنا أن نناقشه أحجام مضغوط من قطع الفردية بدلا من الملفات. سيحتوي ملف 100 جيجا بايت بمتوسط ​​حجم مقطع 1 ميجا بايت على حوالي 100 × 1024 قطعة ، كل منها يتسرب من نسبة الضغط لجزء معين من الملف. ينتج عن هذا بيانات إحصائية أكثر بكثير من حجم ملف مضغوط واحد ، مما يجعل من الممكن مقارنة نص عادي معروف بملف مضغوط ومقطع حتى لو كان ملح CDC (وبالتالي حدود محاذاة القطع الدقيقة) غير معروف.

تم دمج 151 ، على الرغم من أن هذه ليست مشكلة الآن.

في رأيي ، فإن تسريب المعلومات هذا ليس له سوى أهمية ثانوية ، مع الأخذ في الاعتبار أن لدينا وحدة تخزين مصنفة (عبر متعدد الحدود لكل ريبو مخصص) وتعبئة النقطة (حيث لا يمكن للمهاجم رؤية القطع الفردية ، ولكن فقط مجموعات القطع وعدد القطع في مجموعة ، عبر طول رأس النص الواضح). أعتقد أنه من الجيد تقديم ضغط معطل تمامًا لمخاوف تتعلق بالسرعة أو الخصوصية ، ولكن الافتراضي (عند تنفيذ ذلك) من المحتمل أن يكون "تمكين".

klauspost سأنظر بالتأكيد إلى مكتبتك ، شكرًا على الإشارة إليها!

أتفق مع ملاحظاتك أعلاه ، @ fd0 ، ولكن أود أن أضيف أنني أعتقد أنه يمكن أن يكون هناك حالة استخدام أخرى مهمة لتعطيل الضغط بشكل انتقائي لملفات / أدلة / أجهزة مستهدفة محددة ، على سبيل المثال عند النسخ الاحتياطي لتنسيقات الوسائط المتعددة الموجودة بالفعل ملفات ثنائية مضغوطة ذات إنتروبيا عالية لا تنضغط جيدًا ، أو عند عمل نسخ احتياطية متزايدة من وحدات التخزين المشفرة.

cfcs - حسنًا - من النص الخاص بك اعتقدت أنك ضمنيًا أنه يمكنك استنتاج البيانات. لذلك لكي يحدث هذا أي فرق ، ستحتاج إلى البيانات الأصلية ، وهو أمر نادر الحدوث.

فيما يتعلق بالملفات غير القابلة للضغط ، هذا هو السبب في أنني ذكرت وضع Huffman للوقت الثابت الذي أضعه في وضع الانكماش ، حيث يشير الاسم إلى أنه يضغط جميع البيانات بنفس السرعة ، وله تراجع تلقائي في تخزين البيانات غير المضغوطة. لذا فإن الحد الأقصى للمصروفات يكون حوالي 0.04٪ إذا تم ضغط المحتوى.

فيما يلي بعض المعايير . الأكثر قابلية للتطبيق للنسخ الاحتياطية هو على الأرجح "الضغط المتوسط" ، وهو عبارة عن محتوى مختلط 10 جيجابايت - قابل للضغط وغير قابل للضغط.

قد يكون التقصير في gzip Huffman فقط ووجود خيار لتحديد مستوى ضغط أكثر استهلاكًا لوحدة المعالجة المركزية أمرًا منطقيًا.

في رأيي ، قد يكون من المفيد تمكين / تعطيل الضغط بشكل منفصل للبيانات وكائنات الشجرة. يجب أن تنضغط أجسام الأشجار الكبيرة بشكل جيد حقًا.

نظرت في بعض "النقاط" حيث يكون من المنطقي إدخال ضغط. سيكون المكان الأكثر شفافية وتنوعًا في مكان ما بين المستودع والواجهة الخلفية.

نظرت بإيجاز في تعديل 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) {

يتم استبدال الواجهة الخلفية بعد 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: هل نهتم بالأحجام الموجودة على القرص؟ إذا تم تنفيذ ما ورد أعلاه ، فلن يعرف المستودع ذلك.

شكرا لمشاركة أفكارك ، ها أنا أفكر:

أعتقد أنه يجب دمج الضغط والتشفير مع بعضهما البعض ، سأفكر في هذا الأمر. في الوقت الحالي ، لا أحب فكرة تجريد طبقة الضغط / التشفير تمامًا من بعضها البعض. كما وصفت سابقًا ، يجب أن نحرص على عدم القيام بأشياء غبية ، مثل ضغط البيانات المشفرة. بالإضافة إلى ذلك ، يجب أن نقدم خيارًا لتعطيل الضغط لصالح السرعة و / أو مخاوف الأمان. فيما يتعلق بالتشفير: قد يكون هناك وضع غير تشفير لـ restic لاحقًا ، لكن التشفير ليس اختياريًا في الوقت الحالي.

كما أن الملفات المعبأة هي مستوى من التجريد بحد ذاته (على سبيل المثال ، يمكن إعادة حزم الأشياء) ، والتي لا تعمل مع تجريد التشفير.

أعتقد أن الكائن Repository معقد للغاية ويحتاج إلى إصلاح عام قبل معالجة هذا الأمر. ليس لدي بالفعل خطة جيدة جاهزة لذلك الآن.

فيما يتعلق بخوارزميات وخيارات الضغط المختلفة: أعتقد أنه يجب علينا تحديد خوارزمية واحدة (بما في ذلك مجموعة من المعلمات) للبيانات ، وربما أخرى لضغط هياكل شجرة JSON ، ولكن هذا كل شيء. بالنسبة لجميع الأشياء الاختيارية (مثل خوارزميات و / أو معلمات ضغط مختلفة قابلة للتكوين) ، أود الحصول على اعتبار سليم يرجح الفائدة مقابل التعقيد الإضافي ومقدار الكود الإضافي.

من فضلك لا تفهموني بشكل خاطئ ، أود إضافة ميزات إلى restic ، لكن على وجه الخصوص بالنسبة للتغييرات التي تعدل تنسيق القرص ، أحتاج إلى حجج جيدة جدًا. في الحالة العامة لإضافة الضغط ، يمكنني رؤية الفائدة ، لكن التعقيد والتغييرات التي تطرأ على تنسيق القرص يجب أن تكون قابلة للإدارة.

ستحتاج إلى خوارزميات ومعلمات مختلفة (وليس فقط لكل ريبو ، ولكن حتى لكل تشغيل نسخ احتياطي) ، لا يوجد ضغط "أفضل لكل حالة استخدام".

فقط كمثال عملي:

أقوم بعمل نسخ احتياطية من خادم شركتي إلى خادم النسخ الاحتياطي في المنزل. dsl مع ~ 700 كيلوبت / ثانية.
لهذا أريد أفضل ضغط (مثل lzma + مستوى عالٍ). تحتوي وحدة المعالجة المركزية على الكثير من وقت الفراغ في الليل أثناء انتظار الاتصال السيء لقبول الحزمة التالية.

في نفس المستودع ، أقوم أيضًا بعمل نسخ احتياطي للكمبيوتر المحمول الخاص بي عندما أكون في المنزل ، لدي اتصال لاسلكي "N". بالطبع لا أريد إبطاء الاتصال باستخدام lzma + high level هناك ، لكنني أريد شيئًا سريعًا جدًا لا يبطئ على الإطلاق - مثل lz4. ما زلت أريد الضغط على الرغم من أن عدم استخدام lz4 سيستغرق حوالي 2x من المساحة.

أريد lzma هنا لكن lz4 هناك (معاد صياغته :-))

هذا هو كل ما يتعلق بركوب الدراجات ... دعنا نختار افتراضيًا معقولًا ولا نكشف الكثير من التكوين ، والذي سيقدم الكثير من التعقيد لتحقيق مكاسب قليلة ، imho.

أعتقد أن الكائن Repository معقد للغاية ويحتاج إلى إصلاح عام قبل معالجة هذا الأمر. ليس لدي بالفعل خطة جيدة جاهزة لذلك الآن.

عادل بما يكفي. لقد بدأت بالبحث في repository.go ووجدت جميع الأماكن التي تريد إدراج خطوة ضغط / فك الضغط فيها ، ولم يكن التعقيد الإضافي شيئًا جيدًا. من خلال تنفيذه كواجهة backend ، يمكنك فجأة إزالة كل التشفير ، وجعله جزءًا من سلسلة الخلفية. يمكنك إجراء اختبار عام يضمن تناسق أجزاء الواجهة الخلفية ، بما في ذلك الضغط والتشفير.

فيما يتعلق بالتشفير: قد يكون هناك وضع غير تشفير لـ restic لاحقًا ، لكن التشفير ليس اختياريًا في الوقت الحالي.

وهذا هو السبب في أن تسلسل الواجهة الخلفية يجعلها لطيفة للغاية. ما عليك سوى استبعاد التشفير (أو إنشاء واجهة مرور خلفية) وتعمل بسلاسة.

في الحالة العامة لإضافة الضغط ، يمكنني رؤية الفائدة ، لكن التعقيد والتغييرات التي تطرأ على تنسيق القرص يجب أن تكون قابلة للإدارة.

كانت هذه أقل طريقة تدخلاً يمكنني رؤيتها. إذا كانت هناك طريقة لإصلاح مشكلة "الملف المضغوط" ، تظل عمليات إعادة الشراء غير المضغوطة متوافقة تمامًا مع الإصدارات السابقة ؛ سيتمكن العميل القديم من العمل عليها كما كان من قبل جنبًا إلى جنب مع العملاء الجدد.

من الواضح أن عمليات إعادة الشراء المضغوطة لن تكون كذلك ، ولكن يمكننا تغيير version إلى 2 فقط إذا تم ضغط الريبو ، وهذا سيجعل العملاء الأكبر سناً يفشلون. من الواضح أنه يجب تغيير الشيك إلى if cfg.Version > RepoVersion { ، لكن ذلك لا يحتوي على مشاكل في التوافق.

هذا هو كل ما يتعلق بركوب الدراجات ... دعنا نختار افتراضيًا معقولًا ولا نكشف الكثير من التكوين ، والذي سيقدم الكثير من التعقيد لتحقيق مكاسب قليلة ، imho.

يوافق على. تتمتع معظم الخوارزميات (lzma / deflate) بقدر كبير من المرونة في نفس تنسيق إلغاء الضغط.

لاختبار الانضغاط ، يوجد DataSmoke: 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 هو

نشكرك على تجربة mappu ، ولكن قبل تنفيذ ذلك ، نحتاج إلى الاتفاق على استراتيجية. الأسئلة المفتوحة (من أعلى رأسي) هي على الأقل:

• متى يتم تطبيق الضغط؟ (البيانات؟ البيانات الوصفية / JSON؟)
• ما الخوارزمية التي يجب أن نطبقها؟ أعتقد أن لدى klauspost بعض الاقتراحات لنا :)
• كيف نقوم بتخزين هذا في مستودع دون كسر العملاء؟

متى يتم تطبيق الضغط؟ (البيانات؟ البيانات الوصفية / JSON؟)

من الواضح أن البيانات نعم.
البيانات الوصفية / json ، ربما لا معنى لها ولكن أعتقد أنها يمكن أن تساعد في ملفات البيانات الوصفية الكبيرة لأن بيانات JSON هي في الغالب ASCII وستستفيد من مرحلة الترميز الحسابي / huffman (gzip has).

نظرًا لأن البيانات / البيانات الوصفية دائمًا ما تكون مشفرة ، أعتقد أن الإضافة إلى روتين التشفير / فك التشفير هي طريقة بسيطة للقبض على جميع الاستخدامات ، بدون ذلك "بدأت في البحث في repository.go ووجدت جميع الأماكن التي ستدرج فيها خطوة ضغط / فك الضغط ، ولم يكن التعقيد الإضافي شيئًا جيدًا ". من klauspost .
أيضًا نظرًا لأنه يتم تخزين النقاط الكبيرة باسم التجزئة (نص عادي) وليس التجزئة (النص المشفر) {{من الواضح أنه ضروري لـ dedup وإلا سيكون عشوائية IV قد تدمر dedup}} ، فمن الآمن القيام بذلك دون الإضرار بحذف البيانات.

ما الخوارزمية التي يجب أن نطبقها؟ أعتقد أن لدى klauspost بعض الاقتراحات لنا :)

لا يهمني على الرغم من أنني أتفق مع @ ThomasWaldmann أنه يجب أن يكون قابلاً للتكوين. على الأقل لحالة استخدام --best و --fast .

أود أن أقترح gzip فقط لأنه خالص ، إنه موجود في مكتبة golang القياسية ، ويحظى باهتمام الأداء من Google. xz هو ضغط بطيء أقوى بكثير. lz4 هو ضغط سريع أضعف بكثير. gzip متوازن ويمكن ضبطه بسهولة ، حتى لو لم يصل إلى أقصى الحدود.

كيف نقوم بتخزين هذا في مستودع دون كسر العملاء؟

يجب أن يكون المستودع متوافقًا في اتجاه واحد فقط. أعتقد أنه لا بأس إذا كان restic القديم لا يستطيع قراءة الريبو الجديد ، طالما أن restic الجديد يمكنه قراءة الريبو القديم.

ربما يمكنك إضافة علامة بايت بعد MAC. غير موجود - لا يوجد ضغط (restic القديم). بعد ذلك ، يمكن أن يشير البايت أيضًا إلى خوارزمية الضغط التي تم استخدامها. 0x01 gzip 0x02 lz4 أو نحو ذلك.

يبدو أن نفس المشكلة (أو أسوأ) كما في العلية موجودة (لا يوجد نوع ضغط / بايت (بايت) معلمة مستخدمة في التنسيق الحالي).

في العلية (borg) كنت محظوظًا لأن التنسيق القديم كان gzip فقط ويمكن اكتشاف تنسيق gzip من أول 2 بايت. لذلك احتفظت بـ gzip بدون بايتات إضافية (مثل وحدات البايت القديمة) وأضفت نوع بايت (لعدم وجود ضغط أو أي ضغط آخر) التي لا تكون غامضة أبدًا مع أول 2 بايت من gzip.

من الواضح أنه لا يمكنك فعل ذلك على هذا النحو إذا كان التنسيق القديم مجرد بيانات أولية عشوائية.

لا. ولكن هناك طرق أخرى للإشارة إلى هذه المعلومات. على سبيل المثال ، إذا كان IV عند بداية المقطع المشفر هو "NEWFORMAT" بالضبط (احتمال حدوث تصادم 1 :: 2 ^ xyz) ، ثم تحليله باعتباره تنسيقًا جديدًا. إنه ليس "نظيفًا" ولكني أعتقد أنه جيد في الممارسة.

كما هو الحال مع EXTENDEDPROTOCOL في مصافحة قفل nmdc.

أوه لا ، لن نفعل شيئًا قبيحًا مثل هذا ، ولسنا بحاجة إلى ذلك. إذا قررنا تنفيذ ذلك ، فإن ملفات الحزمة تحتوي على حقل type لكل فقاعة. هذا uint8 ، وفي الوقت الحالي محدد فقط لـ data و tree ، يمكننا بسهولة إضافة compressed data و compressed tree . https://github.com/restic/restic/blob/master/doc/Design.md#pack -format

في الوقت الحالي ، لا أعتبر هذه الميزة ذات أولوية عالية.

تعد إضافة أنواع blob جديدة لتنسيق الحزمة أمرًا مقبولاً لضغط البيانات ، ولكنها لا توفر ضغط الفهرس. نظرًا لأن الفهارس يمكن أن تصبح كبيرة ، ولدى JSON نسبة ضغط جيدة ، وربما لا يحتوي الفهرس على ذاكرة تخزين مؤقت محلية ، لذلك أعتقد أنه من المهم ضغط الفهارس أيضًا.

من المهم أن يعمل restic الجديد مع old-repo ، للسماح بالترقية السهلة. يجب أن يكون إما سلسًا (مفضلًا) أو يحتوي على أداة restic upgrade-repo (غير مفضل).

إذن ماذا عن هذا؟

جميع أوامر restic تقوم بالفعل بالتحميل الأول + فك تشفير config .

• إذا كان أول config بايت هو { (هو أول بايت كائن json) ، فإن الريبو بالكامل هو تنسيق قديم (غير مضغوط)
• خلاف ذلك ، أول config بايت هو {tag byte} و الريبو بالكامل هو تنسيق جديد. يشير {tag byte} في بداية البيانات التي تم فك تشفيرها إلى تنسيق الضغط. مثال 0x00 غير مضغوط 0x01 gzip

شكرا على الاقتراح. أعتقد أنه من غير الضروري ضغط التكوين ، لأن هذا ملف صغير حقًا ويمكن أن يظل دائمًا بتنسيق JSON ، ويمكننا إضافة الحقول حسب الضرورة ، على سبيل المثال ما إذا كانت ملفات الفهرس مضغوطة أم لا.

لقد وجدت بالأمس restic أثناء البحث عن حل نسخ احتياطي جيد. أحد اهتماماتي الرئيسية هو الحد من مقدار المساحة التي تشغلها بياناتي. خاصة إذا كنت أرسل البيانات إلى الأماكن التي أدفع مقابلها ، مثل S3. سيساعد Dedup بالتأكيد ، لكني نوعًا ما من الضغط المتوقع سيكون جزءًا لا يتجزأ من حل النسخ الاحتياطي ... في https://github.com/restic/restic/issues/21#issuecomment -185920429 أنت ( @ fd0 ) قل هذا هي أولوية منخفضة ، هل يمكن أن تشرح لماذا؟ هل هناك خارطة طريق يمكنني الاطلاع عليها في أي مكان؟

أيضا ، +1. ؛)

في الوقت الحالي ، أعمل على إزالة بيانات النسخ الاحتياطي القديمة (# 518). ليس من السهل الضغط بشكل صحيح وآمن في نفس الوقت ، وأحتاج إلى التفكير أكثر قليلاً في كيفية دمج هذا في تنسيق المستودع.

سنقوم بتنفيذ الضغط (بعد كل ما يدور حوله هذا الموضوع) ، لم يتم تنفيذه بعد. restic مشروع جديد نوعًا ما ، يرجى تحمله معنا :)

هذه القضية مرتبطة بالرقم 116. بسبب التشفير لا يمكننا ضغط النسخة الاحتياطية بعد ذلك بأدوات أخرى أليس كذلك؟ ما هي الأولوية التي لديك بين الضغط وجعل التشفير اختياريًا؟ (أراهن على الضغط أولاً!)
_اسفًا للضغط حول هذا الأمر ، فأنت محق في أنه يجب التعامل مع تنسيق المستودع بعناية! _

من السهل الإجابة على هذا السؤال: سيتم تنفيذ الضغط أولاً.

هذا لأنه ليس لدي أي خطط في الوقت الحالي لجعل التشفير اختياريًا. أعتقد أنه من الصعب جدًا القيام بذلك بشكل صحيح أيضًا. سنحتاج إلى التفكير في النزاهة ، لأن هذا شيء لا ينبغي أن يكون اختياريًا ، ولكنه (على الأقل في الوقت الحالي) مقترن بإحكام بالتشفير.

@ fd0 شكرا لإجابتك على سؤالي. يجعلني أتمنى أن مهاراتي في التطوير ساعدت في ذلك. لكنني لم أتطرق إلا بالكاد ، ومعظم أجهزة إكس بي الأخرى موجودة في نصوص webdev أو sysadmin.

أوافق تمامًا على أنك بحاجة للتأكد من أن الضغط يتم "بشكل صحيح وآمن". إذا كان هذا يؤخر الأشياء ، فليكن. :ابتسامة:

قمت بتطبيق ضغط سريع في restic هنا: https://github.com/viric/restic/tree/snappy

إنه مجرد اقتراح. في الأساس ، أضفت ضغطًا سريعًا / فك ضغطًا للنقاط في الحزم ، وأستخدم القليل من بايت نوع blob كعلامة. أضفت أيضًا حقلاً في فهارس الحزمة: الطول (طول النص العادي) ، والذي لم يتم تخزينه حتى ذلك الحين ولكن تم حسابه على أنه "طول bloblength - crypto.Extension".

لقد لاحظت أنه بالنسبة لبعض النسخ الاحتياطية الخاصة بي ، لا يستغرق الأمر مساحة أقل فحسب ، بل إنه يعمل بشكل أسرع (بيانات أقل للتعامل معها).

جميع اختبارات الراحة تمر بشكل جيد. يمكن أن يعمل على مستودعات restic السابقة ، لكن restic العادي (ذلك الرئيسي) لا يمكنه التعامل مع النقط الجديدة.

لقد استخدمت snappy (https://github.com/golang/snappy) لأنني اعتقدت أنه سيكون أقل تأثيرًا على هدف السرعة @ fd0.

تمت إضافة مكافأة بقيمة 50 دولارًا مقابل هبوط الضغط على المستوى الرئيسي

كما ذكرنا أعلاه ، يجب أن تكون هناك طريقة آلية غير قابلة للتكوين لتجنب محاولة ضغط الملفات غير القابلة للضغط مثل الوسائط أو المشفرة أو المضغوطة بالفعل. تتفاقم المشكلة بسبب بعض تنسيقات الحاويات مثل PDF التي تكون محتوياتها قابلة للضغط أحيانًا ، وأحيانًا لا تكون كذلك.

سيكون من الأسهل استخدام بعض الخوارزمية التي تتعامل مع هذا الأمر بشفافية ، مثل وضع ضغط الوقت الثابت المذكور في التعليق الأول بواسطةklauspost.

بخلاف ذلك ، ستكون هناك حاجة إلى قوائم نوع الملف: قائمة سوداء لا يتم ضغطها أبدًا ، قائمة بيضاء يجب ضغطها دائمًا ، إرشادية للبقية التي تحاول ضغط جزء صغير من الملف ، وتتخلى إذا لم يكن تقليل الحجم فوق عتبة معينة.

لست متأكدًا من مدى جودة تعيين هذا على المقطع ، بدلاً من مستوى الملف.

سأجادل ضد إضافته إلى ممر التشفير / فك التشفير.
لا نريد مزج أنواع مختلفة من البيانات ، نظرًا لأن بعضها قد يكون متوقعًا ، ويمكن أن تؤدي أطوال الحزمة / النقطة الناتجة إلى تسريب معلومات حول النص الصريح للبيانات السرية / غير المتوقعة.
أعتقد أنه يجب أن يكون لكل ملف ، حتى لو كان هذا يجعله "أقل جمالًا". ومع ذلك ، يأتي ذلك مع ميزة عدم الاضطرار إلى القيام بفك ضغط طائش لأطنان من ملفات الحزم (حيث توجد نقطة واحدة فقط في كل مهمة) لقراءة ملف.

تضمين التغريدة

كما ذكرنا أعلاه ، يجب أن تكون هناك طريقة آلية غير قابلة للتكوين لتجنب محاولة ضغط الملفات غير القابلة للضغط مثل الوسائط أو المشفرة أو المضغوطة بالفعل.

تنفذ حزمة الانكماش المعدلة الخاصة بي تخطي البيانات المضغوطة بالفعل وتقوم بذلك بمعدل ~ 250 ميجابايت / ثانية لكل مركز. يدعم Go 1.7 انكماش ذلك فقط في أسرع مستويات الضغط.

يدعم Snappy و LZ4 وظائف تخطي مماثلة.

سيكون من الأسهل استخدام بعض الخوارزمية التي تتعامل مع هذا الأمر بشفافية ، مثل وضع ضغط الوقت الثابت.

يجب أن يكون بالتأكيد خيارًا. في Go 1.7 (يسمى الآن HuffmanOnly وما يعادله) ، يدعم هذا الوضع حوالي 200 ميجابايت / ثانية لكل مركز بغض النظر عن المدخلات. ومع ذلك ، يتم إعاقة الضغط بشدة مقارنة بـ "أفضل سرعة" ، والتي تعمل عادةً بسرعة 80 ميجابايت / ثانية / مركز.

تضمين التغريدة

أعتقد أنه يجب أن يكون لكل ملف ، حتى لو كان هذا يجعله "أقل جمالًا".

عموما أنا أوافق. سأضطر إلى القراءة على restic. هل الحجم الثنائي لكل حجم حزمة متاح غير مشفر؟

klauspost يبدو أن بعض

تتمثل ميزة استخدام تنسيق DEFLATE في توفر العديد من الضواغط المختلفة التي تنتج دفق بتات متوافق ، لذا فهي شفافة تمامًا بالنسبة إلى برنامج إلغاء الضغط.

نظرًا لطبيعة كيفية عمل restic (تقسيم الملفات إلى blobs ، فقط التعامل مع النقط بعد ذلك) أسهل طريقة لإضافة الضغط هي على مستوى blob. ربما يمكننا إضافة بعض الأساليب التجريبية لتحديد ما إذا كان يجب ضغط النقطة أم لا ، ولكن يمكن أن تكون هذه هي الخطوة الثانية.

يتم دمج النقط في ملفات الحزم ، والتي يتم تخزينها بعد ذلك في المستودع. يحتوي ملف الحزمة على عدد من النقاط (مشفرة بشكل منفصل) ، متبوعًا برأس (مشفر) ، متبوعًا بطول الرأس (غير المشفر). المهاجمون بدون مفتاح فك التشفير يرون فقط النص المشفر وطول الرأس وطول الملف. بناءً على حجم ملف الحزمة وطول الرأس ، يمكن للمهاجمين حساب متوسط ​​حجم النقطة في ملف حزمة معين ، ولكن هذا كل شيء. تحتوي ملفات الفهرس أيضًا على جميع البيانات (الحجم والحجم المشفر وبعد ذلك ربما الحجم المضغوط) ، ولكن يتم تشفيرها أيضًا. لا أرى أي خطر هنا.

اختبار الكشف عن مجريات الأمور "القابل للضغط" عرضة للأخطاء ومكلف إلى حد ما. أود أن أقدر أنه سيكون من الصعب الحصول على ما يزيد عن 200 ميجابايت / ثانية / نواة - هذه هي سرعة البحث عن الطلب 1 في حزمة الخصم على AMD64.

أيضًا ، سيعتمد ذلك كثيرًا على الضاغط المستخدم. لن يكون Snappy قادرًا على ضغط بيانات القاعدة 64 العشوائية ، ولكن على سبيل المثال ، قد ينكمش الهواء ، لذلك سأترك هذا الجزء للضاغط - لدينا هذا الجزء المدمج في Snappy و LZ4 وتفريغ الهواء.

@ fd0 آسف ، قصدته لكل نقطة ، وليس لكل ملف.
ما لم نختار خوارزمية خفيفة الوزن ، فإن الضغط ، كونه ثقيلًا إلى حد ما في وحدة المعالجة المركزية ، من المحتمل أن يصبح عنق الزجاجة (بجانب AES ، والذي نأمل أن يتم الاعتناء به في المستقبل بواسطة AES-NI).

@ fd0 - لقد قمت بعمل "مقدر https://play.golang.org/p/Ve5z3txkyz - فهو يقدّر إمكانية التنبؤ وانتروبيا البيانات العشوائية. رغم ذلك ، كما ذكرت ، يجب أن يكون الأمر متروكًا للضاغط ليقرر.

سيكون لدى borg 1.1 عدد 2 من "أدوات تحديد الضغط":

1. تحديد كل ملف بناءً على تطابق نمط المسار ( *.zip ، *.mp3 ، /htdocs/photos/* ، ...)
2. إذا لم يتم تحديده ، حدد لكل جزء ، استخدم lz4 كاختبار للانضغاط - إذا كان هذا ضغطًا ، فاضغط مرة أخرى باستخدام الضغط المطلوب (lz4 ، zlib ، lzma) ، وإذا لم يكن كذلك ، فلا تقم بالضغط.

klauspost hm ، هذا الاختبار ليس سيئًا للغاية على جهازي:

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

رمز المعيار هنا: https://gist.github.com/908c23123dda275a479cf931f2784f5d

لا يحتوي Lz4 على مبرمج إنتروبيا ، لذلك سوف يخطئ السلبية عدة مرات
المحتمل؟

أعتقد أننا بحاجة إلى ثلاثة أوضاع (عالميًا):

• ضغط جميع البيانات الكبيرة باستخدام ضاغط زمني خطي (افتراضي)
• لا يوجد ضغط
• أقصى ضغط (للأشخاص الذين لديهم قدر كبير من طاقة وحدة المعالجة المركزية ، ولكن فقط النطاق الترددي الصغير)

أرغب دائمًا في ضغط كائنات الشجرة (JSON) ، لذلك يجب علينا تحديد خوارزمية مناسبة لنص ASCII.

وإلا سأعمل مع viric لبناء نموذج أولي ، ثم يمكننا التفكير في تنفيذ ملموس.

أفكار؟

klauspost hm ، هذا الاختبار ليس سيئًا للغاية على جهازي

أنسى دائمًا كيف يمكن لمترجم Go الجديد أن يفعل بشكل جيد بجنون. ما لا يقل عن ضعف ما كنت أتوقعه.

أعتقد أننا بحاجة إلى ثلاثة أوضاع (عالميًا):

يعمل الانكماش على أداء الثلاثة بشكل جيد ، على الرغم من وجود ضواغط أكثر كفاءة (LZMA في الغالب). إن الانكماش بدون ضغط هو بالطبع غير ضروري ، ولكنه بالطبع سريع وبأقل قدر من النفقات العامة ، لذلك يمكن استخدام نهج الانكماش العام ، مع إمكانية تحديد الآخرين لاحقًا.

لقد بدأت في البحث عن تسريع آخر ، والذي سيكون بين المستوى 1 و Huffman من حيث السرعة والضغط. ومع ذلك ، فإن الوقت ثمين بعض الشيء في الوقت الحالي ، وما زلت بحاجة إلى اختبار منفذ خلفي لبعض تغييرات Go 1.7 النهائية قبل أن أتمكن من الانتقال إلى أشياء جديدة.

إذا كنت تريد فقط خوارزمية ضغط واحدة ، فعليك إلقاء نظرة على المنافس الجديد zstd: https://github.com/facebook/zstd

تم تطويره بواسطة نفس مطور lz4 ولديه نسبة ضغط أفضل من gzip بينما يكون أسرع بثلاث مرات: https://code.facebook.com/posts/1658392934479273/smaller-and-faster-data-compression-with -المعيار /

يبدو zstd واعدًا جدًا ، على الرغم من أنني لم أتمكن من العثور على تطبيق في Go.

الموقع الرسمي http://facebook.github.io/zstd/#other -languages ​​روابط لتنفيذ Go: https://github.com/DataDog/zstd

أم تقصد تطبيق Go الخالص؟

نعم ، يعني تطبيق Go الخالص. في الوقت الحالي ، لا يعتمد restic على أي كود C ، ومن الناحية المثالية أرغب في الاحتفاظ به على هذا النحو.

هل هناك أي توقعات لتنفيذ الضغط؟

يعتمد تنفيذ الضغط على تغيير تنسيق المستودع (التخطيط / الأفكار في # 628) ، الأمر الذي يتطلب عناية كبيرة. لذلك ، لا ، لا يوجد تاريخ محدد عند إضافة الضغط ؛)

هل هناك أي شيء يمكننا القيام به أو المساهمة فيه للمساعدة في تحقيق ذلك؟

لا أظن ذلك ، آسف: غمزة: إنها تحتاج إلى وقت فقط.

لذلك اعتقدت أنه يمكنني استخدام سرير الاختبار الخاص بي من # 790 مرة أخرى. في تصميم restic الخاص بي ، قمت بإزالة كل التشفير ، ثم قمت بعمل نسخة احتياطية كاملة مرة أخرى. لقد جاء بنفس حجم التشفير - لا مفاجآت هنا. ولكن بعد ذلك قمت بضغط المستودع ، وما وجدته هو:

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

ما الاختلاف! للمقارنة ، إليك حجم ملف تفريغ قاعدة بيانات واحد مضغوط:

1.7G    single-backup.sql.gz

لدي 29 من هؤلاء أعلاه. حوالي 100 ضعف التوفير مقارنة بالنسخ الاحتياطية العادية!

نظرًا لأنني وجدت جميع الأماكن التي تمت إضافة التشفير إليها ، أعتقد أنه يمكنني إضافة ضغط قابل للتكوين بسيط للغاية باستخدام تطبيق gzip ، مع إمكانية استخدام محرك ضغط مختلف في المستقبل. أي اعتراضات؟

(سأمنح نفسي على الأرجح أمسيات لمدة أسبوعين لكي أنجح أو أفشل).

شكرا لبحثك ونشر النتائج هنا! كنت أتوقع نتائج مماثلة. لأكون صادقًا معك: لن أدمج أي شيء يزيل التشفير ، أو حتى يجعله اختياريًا. هذا شيء يمكننا القيام به لاحقًا ، لكن يجب التخطيط له بعناية.

قد تبدو إضافة الضغط سهلة في البداية ، لكنها ليست كذلك. يجب أن نكون حريصين جدًا على عدم جعل restic عرضة للهجمات غير المتوقعة (حدث هذا لبروتوكول TLS عدة مرات متتالية (نعم ، أنا أدرك أن هذا وضع مختلف)).

أهم شيء في المشروع بأكمله ليس الكود: إنه تنسيق المستودع. يثق المستخدمون بنا ببياناتهم ، ويعتمدون على قدرتهم على استعادة البيانات بعد استخدام restic لفترة طويلة ، لذا فإن استقرار تنسيق المستودع له أهمية قصوى. لذلك من أجل دعم الضغط ، نحتاج أولاً إلى تحديد (وتنفيذ) الإصدار التالي من تنسيق المستودع. المناقشة هنا: https://github.com/restic/restic/issues/628

أستطيع أن أرى أنك حريص جدًا على تنفيذ هذا (وحتى المساهمة في الكود) ، لكن من فضلك لا تقضي أي وقت في هذا حتى نتفق على تنسيق المستودع ونناقش جميع زوايا هذه المشكلة. شكرا!

بالنسبة إلى التشفير الذي تمت إزالته ، لن أقترح دمج ذلك. لقد فعلت ذلك فقط لمعرفة ما إذا كان الضغط سيعمل. ونعم ، كان يجب التخطيط لذلك بعناية (لا أحد يريد أن يفقد فجأة القدرة على التحقق من مستودع مع تعطيل التشفير).

نظرًا لأننا نستخدم json.Unmarshal يمكننا إضافة العديد من المفاتيح الجديدة إلى التكوين كما نريد. إذا لم يتم العثور عليهم في JSON ، فسيحتفظون بقيمهم الافتراضية.

إن اختيار الخوارزمية ليس هو النقطة الرئيسية ، كما هو مفهوم: ولكن فقط للرجوع إليها في المستقبل ، يبدو Brotli منافسًا قويًا.

لكل ما أعرفه ، يكون ضغط Brotli بطيئًا جدًا (iirc 60 مرة gzip) ، لذلك يوصى بالبيانات التي تتم قراءتها بشكل متكرر مقارنةً بالكتابة والضغط ، وهو أمر قد لا يكون شائعًا بالنسبة للنسخ الاحتياطية. لكن نعم ، دعونا لا ندخل في التفاصيل بعد :)

هذا يعطي نظرة عامة جيدة لخوارزميات الضغط المختلفة.

يكون Brotli دائمًا أسرع أو يتمتع بضغط أفضل. يعتمد على مستوى الضغط.

ibib كيف تصل إلى هذا الاستنتاج؟ يبدو لي أن brotli يبدو أبطأ من معظم الآخرين (في مجموعات البيانات المختلطة) مع عدم تحقيق معدلات ضغط مذهلة بشكل خاص. ربما يكون من الأفضل لأنواع معينة من البيانات المنظمة؟

كما هو مدرج في المقارنات في معيار الاسكواش ، هناك ثلاثة معايير يجب اتباعها:

• نسبة الضغط المحققة: من المهم مدى جودة الضغط من أجل توفير مساحة على القرص (والإدخال / الإخراج إلى الواجهة الخلفية).

• سرعة الضغط: مهمة لأننا سنقوم بهذه العملية في كل مرة نضيف فيها كتلة ، لذلك نريد حقًا شيئًا يمكنه مواكبة AES-NI والإدخال / الإخراج العام حتى لا يصبح عنق الزجاجة. ربما لا نرغب في اختيار خوارزمية تضغط بشكل أبطأ من فك الضغط نظرًا لأن لدينا حالة استخدام معاكسة لمتصفحات الويب مثل هذه الخوارزميات الجديدة (مثل zstd ، lz4 ، brotli ) من أجل (لدينا "الضغط كثيرًا ، ونادرًا ما يتم فك الضغط" بدلاً من "الضغط مرة واحدة ، وفك الضغط كثيرًا").

• سرعة فك الضغط: تكون سرعة فك الضغط ذات صلة فقط عندما نقوم بالاستعادة. إذا كنا على ما يرام مع استعادة بطيئة ، فيمكننا قبول سرعة إزالة الضغط البطيئة. من ناحية أخرى ، لدينا أيضًا بيانات وصفية لا نريد فك ضغطها ببطء ، لذلك قد يتطلب الأمر خوارزميتين مختلفتين.

يبدو أن density من بين الأسرع ، وإن لم يكن فعالًا بشكل خاص من حيث نسبة الضغط. من حيث عدم كونه عنق زجاجة ، يبدو أنه سيوفر لنا (في المتوسط) نسبة ضغط 2: 1 مجانًا تقريبًا. إذا أردنا 4: 1 ، فسيتعين علينا اختيار خوارزمية مختلفة ، ولكن بعد ذلك سننتهي بالجلوس وننتظرها.

لدينا أيضًا نوعان مختلفان (على الأقل؟) من البيانات: الفهارس ؛ وقطع البيانات. يتم استخدام الاثنين بشكل مختلف ، وأعتقد أنه يمكن مناقشة ما إذا كان من المنطقي اختيار خوارزميات مختلفة لهما. أنا شخصياً أعتقد أننا يجب أن نلتزم بخوارزمية واحدة (أيًا كان ما نختاره) حتى لا تكون إعادة تطبيق Restic (بلغة جديدة أو أيًا كانت) صعبة بشكل غير معقول. وحتى يتسنى لنا لا تعرض أنفسنا البق من اثنين من خوارزميات ضغط مثيرة منذ تلك من الصعب اختبار للحالات الزاوية.

يجب أن أختلف مع المقايضات الموصى بها. يمكن تشغيل النسخ الاحتياطية في الخلفية في وقت مناسب (ربما مع 10 لطيفة). استعادتها تحدث تحت ضغط الوقت. المفاضلة ذات الصلة التي أراها هي بين حجم الكتلة ونسبة الضغط. لن يتم ضغط الكتل الصغيرة جدًا بشكل جيد وتزيد من حجم البيانات الوصفية. الكتل الكبيرة جدًا تقلل من نسبة الحذف. بالنسبة لمعظم خوارزميات الضغط ، لن تعمل إعدادات المستوى الأعلى على تحسين نسب الضغط للإدخالات الصغيرة.

بالإضافة إلى ذلك ، تسمح نسب الضغط الأعلى للمستخدمين بالاحتفاظ بنسخ أكثر من بياناتهم في نفس المساحة.

تذكر أن اختباراتي مع snappy كانت نتيجة: 1) حجم نسخ احتياطي أصغر (يتم ضغطه ، عادي) ، و 2) نسخ احتياطي واستعادة أسرع (تشفير أقل للبيانات ، HMAC ونقلها). استخدام جهاز كمبيوتر محمول رخيص للغاية.

cfcs أشرت إلى المقارنة بين gzip و brotli

هنا ، يتمتع brotli دائمًا بالضغط الأسرع والأفضل.

Crest هذا عادل بما فيه الكفاية ، ربما لدينا حالات استخدام مختلفة - أنا لا أستخدم restic بنفس الطريقة التي تستخدمها. أقوم بعمل نسخ احتياطية من جهاز الكمبيوتر المحمول الخاص بي وأريد أن ينتهي بسرعة حتى أتمكن من المغادرة مع جهاز الكمبيوتر المحمول الخاص بي. أعتبر أنك تتحدث عن النسخ الاحتياطية للخوادم أو غيرها من الأجهزة المتصلة باستمرار حيث لا يكون معدل النسخ الاحتياطي مهمًا للغاية. وبالمثل ، لا أحتاج أبدًا إلى استعادة جميع بياناتي تحت ضغط الوقت ؛ إذا كان هناك ضغط زمني (لأنك تستخدمه في سياقات مهنية؟) ، يمكنني بشكل انتقائي استعادة البيانات التي أحتاجها ، والمضي قدمًا في القيام بالباقي لاحقًا.

لقد أوضحت نقطة جيدة جدًا حول "المدخلات الصغيرة في كثير من الأحيان ؛"

viric تم Transfer + Processing :-)

ibib آه ، مسكتك!

ibib هل يمكنك الارتباط من أين حصلت على هذا المخطط؟

الرسم البياني من https://quixdb.github.io/squash-benchmark/

لقد أجريت بعض الاختبارات مع brotli و zstd ، ولاحظت أن نتائجي لا تتطابق على الإطلاق مع نتائج اختبار الاسكواش. ثم فهمت أن هذا المعيار يبلغ من العمر 1.5 سنة.

zstd يعمل بشكل جيد بالنسبة لي. نسبة سريعة + عالية ، ويسمح "مستواها" بمدى كبير جدًا بين النسبة السريعة والعالية. شيء عظيم.

يعمل Brotli ببطء شديد بالنسبة لي ، مع عدم وجود نسبة ضغط أفضل من zstd الأسرع بكثير. ويبدو أن brotli يركز على ملفات صغيرة من النصوص الإنجليزية (يتضمن قاموسًا باللغة الإنجليزية). لضغط html أو ما شابه.

المزيد من المعايير الحديثة التي وجدتها: https://github.com/inikep/lzbench

لذلك رميت سرير الاختبار الخاص بي مرة أخرى ضد zbackup بضغط LZMA.

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

مثير للإعجاب ، أليس كذلك؟

يكفي أن نقول أن zbackup لديه مجموعة من القيود والعيوب الخاصة به.

لذلك ، وفقًا لرابطviric lzbench ، فإن الضاغط الأنسب هو الذي لا يبطئ النسخ الاحتياطية (سرعة ضغط عالية ؟،> 200 ميجابايت / ثانية) ، والذي يحتوي بالفعل على نسبة ضغط جيدة (> = 50) ، أليس كذلك؟

لذلك ، قمت بتصفية النتائج من جدول مرتبة حسب النسبة.

لقد أجريت أيضًا بحثًا سريعًا عن تطبيقات Go (ولهذا السبب احتفظت بها في الجدول). يتوسطه خط يعني أنني لم أجد أي تطبيق ، مما أدى إلى القضاء على كل شيء تقريبًا. نظرًا لأنه كان مجرد بحث سريع ، فقد احتفظت بالنتائج. استثناء لـ zstd الذي هو مجرد غلاف.

| اسم الضاغط | ضغط | فك الضغط كومبر. الحجم | النسبة |
| --------------- | ----------- | ----------- | ----------- | ----- |
| zstd 1.1.4 -1 | 242 ميغا بايت / ثانية | 636 ميغا بايت / ثانية | 73654014 | 34.75 |
| سحلية 1.0 -30 | 258 ميغا بايت / ثانية | 867 ميغا بايت / ثانية | 85727429 | 40.45 |
| الكثافة 0.12.5 بيتا -3 | 253 ميغا بايت / ثانية | 235 ميغا بايت / ثانية | 87622980 | 41.34 |
| gipfeli 2016-07-13 | 233 ميغا بايت / ثانية | 451 ميغا بايت / ثانية | 87931759 | 41.49 |
| pithy 2011-12-24 -9 | 257 ميغا بايت / ثانية | 1263 ميغا بايت / ثانية | 90360813 | 42.63 |
| بيثي 2011-12-24 -6 | 295 ميغا بايت / ثانية | 1268 ميغا بايت / ثانية | 92090898 | 43.45 |
| Quicklz 1.5.0 -1 | 346 ميغا بايت / ثانية | 435 ميغا بايت / ثانية | 94720562 | 44.69 |
| سحلية 1.0 -20 | 284 ميغا بايت / ثانية | 1734 ميغا بايت / ثانية | 96924204 | 45.73 |
| pithy 2011-12-24 -3 | 352 ميغا بايت / ثانية | 1222 ميغا بايت / ثانية | 97255186 | 45.89 |
| lzrw 15 يوليو 1991 -4 | 243 ميغا بايت / ثانية | 392 ميغا بايت / ثانية | 100131356 | 47.24 |
| lzo1x 2.09 -1 | 394 ميغا بايت / ثانية | 551 ميغا بايت / ثانية | 100572537 | 47.45 |
| lz4 1.7.5 | 452 ميغا بايت / ثانية | 2244 ميغا بايت / ثانية | 100880800 | 47.60 |
| fastlz 0.1 -2 | 243 ميغا بايت / ثانية | 469 ميغا بايت / ثانية | 100906072 | 47.61 |
| lzo1y 2.09 -1 | 397 ميغا بايت / ثانية | 556 ميغا بايت / ثانية | 101258318 | 47.78 |
| lzo1x 2.09-15 | 406 ميغا بايت / ثانية | 549 ميغا بايت / ثانية | 101462094 | 47.87 |
| الكثافة 0.12.5 بيتا -2 | 480 ميغا بايت / ثانية | 655 ميغا بايت / ثانية | 101706226 | 47.99 |
| lzf 3.6 -1 | 251 ميغا بايت / ثانية | 565 ميغا بايت / ثانية | 102041092 | 48.14 |
| snappy 1.1.4 | 327 ميغا بايت / ثانية | 1075 ميغا بايت / ثانية | 102146767 | 48.19 |
| blosclz 2015-11-10 -9 | 220 ميغا بايت / ثانية | 696 ميغا بايت / ثانية | 102817442 | 48.51 |
| بيثي 2011-12-24 -0 | 384 ميغا بايت / ثانية | 1221 ميغا بايت / ثانية | 103072463 | 48.63 |
| lzo1x 2.09-12 | 418 ميغا بايت / ثانية | 550 ميغا بايت / ثانية | 103238859 | 48.71 |
| سحلية 1.0 -10 | 360 ميغا بايت / ثانية | 2625 ميغا بايت / ثانية | 103402971 | 48.79 |
| fastlz 0.1 -1 | 235 ميغا بايت / ثانية | 461 ميغا بايت / ثانية | 104628084 | 49.37 |
| lzrw 15 يوليو 1991 -3 | 226 ميغا بايت / ثانية | 449 ميغا بايت / ثانية | 105424168 | 49.74 |
| lzf 3.6 -0 | 244 ميغا بايت / ثانية | 550 ميغا بايت / ثانية | 105682088 | 49.86 |
| lzo1x 2.09-11 | 424 ميغا بايت / ثانية | 560 ميغا بايت / ثانية | 106604629 | 50.30 |
| lz4fast 1.7.5 -3 | 522 ميغا بايت / ثانية | 2244 ميغا بايت / ثانية | 107066190 | 50.52 |
| تورنادو 0.6a -1 | 233 ميغا بايت / ثانية | 334 ميغا بايت / ثانية | 107381846 | 50.66 |
| memcpy | 8657 ميغا بايت / ثانية | 8891 ميغا بايت / ثانية | 211947520 | 100.00 |

يبدو LZ4 وكأنه أكثر ضاغط مبتدئ؟

أعتقد أنك تريد lz4 (> = 1.7.0 r129) و zstd (> = 1.3.0) ، إن وجد. نستخدمها أيضًا في borgbackup.

لكن zstd قابل للضبط مع عدد صحيح واحد ، من سرعة lz4 إلى الأفضل
من ضغط xz. هذا من شأنه أن يجعل المستخدمين السعداء للكثافة أبطأ
الضغط وتلك ذات الضغط السريع. ناهيك عن أن zstd
يقوم بفك الضغط بسرعة كبيرة ، بغض النظر عن جهد الضغط.

lz4 هو هدف ضيق للغاية.

يوم السبت ، 16 ديسمبر 2017 الساعة 09:50:49 صباحًا -0800 ، كتب TW:

أعتقد أنك تريد lz4 و zstd ، إن وجدت. نستخدمها أيضًا في borgbackup.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/restic/restic/issues/21#issuecomment -352199097

-
(Escriu-me xifrat si saps PGP / اكتب مشفرًا إذا كنت تعرف PGP)
مفتاح PGP 7CBD1DA5 - https://emailselfdefense.fsf.org/

حسنًا .. وفقًا لـ https://github.com/restic/restic/issues/21#issuecomment -250983311 للحفاظ على عدم الاعتماد على الراحة ، فإن zstd ليس خيارًا ، في الوقت الحالي. أيضًا ، هناك عدد قليل من المواضيع حول قضايا براءات الاختراع / الترخيص.

بالنسبة إلى xz ونسب الضغط العالية ، حتى بالنسبة لإعدادات الضغط المنخفضة ، وفقًا للجدول ، فإن أسرع ضغط هو حوالي 15 ميغا بايت / ثانية.

إذا تم تخفيض متطلبات النسخ الاحتياطي السريع ، دعنا نقول ،> = 30 ميغا بايت / ثانية ، يمكننا إضافة:

| اسم الضاغط | ضغط | فك الضغط كومبر. الحجم | النسبة |
| --------------- | ----------- | ----------- | ----------- | ----- |
| 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 |
| zstd 1.1.4 -8 | 30 ميغا بايت / ثانية | 609 ميغا بايت / ثانية | 61021141 | 28.79 |
| zling 2016-01-10 -2 | 32 ميغا بايت / ثانية | 136 ميغا بايت / ثانية | 61917662 | 29.21 |
| xz 5.2.3 -0 | 15 ميغا بايت / ثانية | 44 ميغا بايت / ثانية | 62579435 | 29.53 |
| zling 2016-01-10 -0 | 38 ميغا بايت / ثانية | 134 ميغا بايت / ثانية | 63407921 | 29.92 |
| zstd 1.1.4 -5 | 88 ميغا بايت / ثانية | 553 ميغا بايت / ثانية | 64998793 | 30.67 |
| lzfse 2017-03-08 | 48 ميغا بايت / ثانية | 592 ميغا بايت / ثانية | 67624281 | 31.91 |
| libdeflate 0.7 -6 | 64 ميغا بايت / ثانية | 609 ميغا بايت / ثانية | 67928189 | 32.05 |
| brotli 2017-03-10 -2 | 98 ميغا بايت / ثانية | 289 ميغا بايت / ثانية | 68085200 | 32.12 |
| zstd 1.1.4 -2 | 185 ميغا بايت / ثانية | 587 ميغا بايت / ثانية | 70164775 | 33.10 |
| تورنادو 0.6a -4 | 91 ميغا بايت / ثانية | 197 ميغا بايت / ثانية | 70513617 | 33.27 |
| libdeflate 0.7 -3 | 96 ميغا بايت / ثانية | 602 ميغا بايت / ثانية | 70668968 | 33.34 |
| xpack 2016-06-02 -1 | 98 ميغا بايت / ثانية | 506 ميغا بايت / ثانية | 71090065 | 33.54 |
| تورنادو 0.6a -3 | 119 ميغا بايت / ثانية | 188 ميغا بايت / ثانية | 72662044 | 34.28 |
| libdeflate 0.7 -1 | 117 ميغا بايت / ثانية | 570 ميغا بايت / ثانية | 73318371 | 34.59 |
| سحلية 1.0 -42 | 90 ميغا بايت / ثانية | 938 ميغا بايت / ثانية | 73350988 | 34.61 |
| zstd 1.1.4 -1 | 242 ميغا بايت / ثانية | 636 ميغا بايت / ثانية | 73654014 | 34.75 |

هناك العديد من تطبيقات الانكماش ، ولكن غير متأكد ما إذا كانت قابلة للمقارنة.
اليسار xz كمرجع
zstd تبدو واعدة جدا. سيء للغاية لا يوجد تطبيق Go

viric zstd ليست سرعة lz4 تمامًا.

ولكن إذا كان المرء يرغب في الحصول على ضاغط واحد فقط بدلاً من ضاغط متعدد ، فإن zstd يكون أكثر مرونة.

اغفر تأخري. بعض التعليقات:

سرعة الضغط: مهمة لأننا سنقوم بهذه العملية في كل مرة نضيف فيها كتلة ، لذلك نريد حقًا شيئًا يمكنه مواكبة AES-NI والإدخال / الإخراج العام حتى لا يصبح عنق الزجاجة. ربما لا نرغب في اختيار خوارزمية تقوم بالضغط بشكل أبطأ من فك الضغط نظرًا لأن لدينا حالة استخدام معاكسة لمتصفحات الويب التي تم تحسين هذه الخوارزميات الجديدة (مثل zstd و lz4 و brotli) من أجلها (لدينا "ضغط كثيرًا ، ونادرًا ما يفك الضغط" على عكس "الضغط مرة واحدة ، فك الضغط كثيرًا").

لا ، ليس من الضروري الضغط على سرعات AES التي يتم تسريعها بالأجهزة. يتعلق الضغط بوقت التداول بالنسبة للحجم. من المتوقع تمامًا أن تستغرق النسخ الاحتياطية المضغوطة وقتًا أطول.

على سبيل المثال ، بدلاً من استخدام restic على النسخ الاحتياطية الشخصية الخاصة بي ، ما زلت أستخدم Obnam ، لأنه على أحد الخوادم الصغيرة التي أخزنها عليها ، إذا لم تكن مضغوطة ، فلن تناسبها. تستغرق النسخ الاحتياطية ساعات بالفعل ، ويتم تشغيلها في الخلفية حتى لا ألاحظ ذلك.

لا يهمني إذا كانت النسخ الاحتياطية المضغوطة لـ restic تستغرق وقتًا أطول. في الواقع ، أتوقع منهم أن يفعلوا ذلك ، وهذه هي المقايضة التي أحتاج إلى القيام بها. بدون هذا النوع من الضغط ، لن يكون restic مفيدًا بالنسبة لي.

سرعة فك الضغط: تكون سرعة فك الضغط ذات صلة فقط عندما نقوم بالاستعادة. إذا كنا على ما يرام مع استعادة بطيئة ، فيمكننا قبول سرعة إزالة الضغط البطيئة. من ناحية أخرى ، لدينا أيضًا بيانات وصفية لا نريد فك ضغطها ببطء ، لذلك قد يتطلب الأمر خوارزميتين مختلفتين.

تتم عمليات الاستعادة بشكل أقل تكرارًا من النسخ الاحتياطية ، لذا فإن سرعة فك الضغط ليست بنفس الأهمية. ذكر شخص ما أنه يتم إجراؤها غالبًا تحت ضغط الوقت: هذا صحيح ، لكن هذا لا يعني أن عمليات الاستعادة يجب أن تكون بنفس سرعة النسخ الاحتياطية ، أو في أي مكان قريب منها.

لدينا أيضًا نوعان مختلفان (على الأقل؟) من البيانات: الفهارس ؛ وقطع البيانات. يتم استخدام الاثنين بشكل مختلف ، وأعتقد أنه يمكن مناقشة ما إذا كان من المنطقي اختيار خوارزميات مختلفة لهما.

قد لا يكون من الضروري (أو بالضرورة فكرة جيدة) ضغط الفهارس على الإطلاق. نظرًا لكونها فهارس ، يبدو من غير المحتمل أن تنضغط جيدًا في المقام الأول ، لأن الغرض الأساسي منها هو تخزين البيانات الفريدة.

أنا شخصياً أعتقد أننا يجب أن نلتزم بخوارزمية واحدة (أيًا كان ما نختاره) حتى لا تصبح إعادة تطبيق Restic (بلغة جديدة أو أيًا كانت) صعبة بشكل غير معقول. وحتى لا نعرض أنفسنا لأخطاء من خوارزميات ضغط مثيرة حيث يصعب اختبارها لحالات الزاوية.

أتفهم هذه المخاوف ، لكنني أعتقد أن ذلك سيكون خطأ. على الأقل ، يجب أن يسمح تنسيق الريبو بخوارزميات ضغط متعددة بحيث يمكن إضافة أحدثها في المستقبل. من المحتمل أن تكون هناك وحدات قابلة للتوصيل للضغط حتى يتمكن المستخدمون من اختيار الوحدات التي يريدون استخدامها ، على سبيل المثال ، يمكنني تخيل حزم دبيان مثل restic-xz ، restic-zstd ، إلخ. يمكن للمستخدمين تثبيتها إذا أرادوا ذلك استخدم تلك الخوارزميات. يجب استخلاص ضغط البيانات الاحتياطية بحيث يقوم restic بوظيفة ضغط بعض البيانات وإعادة ضغطها ، ولا ينبغي أن يهتم restic بما يحدث بينهما ؛ الشيء نفسه بالنسبة لتخفيف الضغط.

إذا تم تخفيض متطلبات النسخ الاحتياطي السريع ، دعنا نقول ،> = 30 ميغا بايت / ثانية ، يمكننا أن نضيف

الذي يبدو معقولا بالنسبة لي. تذكر أن النسخ الاحتياطية المحلية هي نوع واحد فقط ؛ تقل احتمالية اختناق النسخ الاحتياطية للشبكة بسبب سرعة الضغط.

ولكن ، مرة أخرى ، يجب أن يكون هذا مضبوطًا من قبل المستخدمين حتى يتمكنوا من تحديد الحل المناسب لاحتياجاتهم.

تمت إضافة مكافأة قدرها 10 دولارات مقابل: بيرة: :)

🍺 ++

هذا رابط إلى BountySource إذا كان هناك شخص آخر يرغب في المساهمة

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

أتساءل عما إذا كان يمكن تنفيذ ذلك بطريقة قابلة للتكوين من قبل المستخدم بحيث يُترك اختيار السرعة مقابل الحجم للمستخدم ليقرره. أفضل ضغط أعلى كإعداد افتراضي.

دعنا نقرر متى نصل إلى هناك. للتسجيل: أنا بخير مع إعطاء المستخدم القليل من التحكم من حيث السرعة مقابل الحجم.

+1 للراحة التي تحتاج إلى تنفيذ ضغط. أنا أستخدم restic لنسخ صور VM احتياطيًا للرجوع إلى الخلف وأحب أن أكون قادرًا على ضغطها قبل التحميل. في حالة الاستخدام الخاصة بي ، سأقوم بالتداول بكمية غير محدودة تقريبًا من الوقت / وحدة المعالجة المركزية لتقليل حجم البيانات المنقولة / المخزنة. أدرك أن السرعة هي مصدر قلق للبعض. يعد وجود بنية قابلة للتوصيل حيث يمكن تحديد خوارزميات متعددة أمرًا أساسيًا.

يسعدني المساعدة في الاختبار حيث يتم النظر في هذا الأمر بمزيد من التفصيل.

@ fd0 لقد مر وقت طويل منذ أن عملت على قاعدة الكود الثابت. هل من الممكن أن تعطي توجيهًا سريعًا حول نهج جيد وأين يجب أن أنظر؟

klauspost ليس هناك الكثير من الضغط على المستوى الفني ، بل من السهل القيام به ، ولكن كيف نتعامل مع ترقية تنسيق الريبو بطريقة متوافقة مع الإصدارات السابقة. أنا مشغول حاليًا بإعادة كتابة جزء أرشيفي (بحيث تختفي الأشياء القبيحة مثل # 549) ، بعد ذلك أود إضافة ضغط ثم التبديل إلى repo v2.

ما رأيك في أي خوارزمية ضغط يجب أن نستخدمها؟ أفكر في دعم ثلاثة أوضاع:
1) لا يوجد ضغط
2) ضغط "الوقت الخطي" (لا يضيف الكثير من تحميل وحدة المعالجة المركزية)
3) "أقصى ضغط"

ربما يكون الوضع الأول والثاني هو نفسه ، لست متأكدًا من ذلك

سيكون من الرائع أن تكون قادرًا على استخدام شيء مثل zstd ، ولكن ككود Go أصلي. ألمح داميان إلى أنه قد لا يكون هناك الكثير من العمل لنقل إصدار Java أو C: https://twitter.com/dgryski/status/947259359628738560 ، هل هناك أي شيء يمكنني القيام به لإثارة اهتمامك بتجربة ذلك؟ :)

لقد ألقيت نظرة على مواصفات تنسيق zstd ، وبالنسبة لي ليس من السهل تنفيذها (جيدًا). مصادر Java هي فقط فك الضغط.

للضغط السريع ، يجب أن يعمل LZ4 بشكل جيد جدًا. منفذ Go ممتاز. سيكون zstd أفضل ، لكنني سأختار حزمة مجربة ومختبرة ، إلا إذا كنت ترغب في استخدام تطبيق cgo.

بالنسبة إلى منتصف الطريق ، لا يزال ضغط الانكماش جيدًا من حيث السرعة / الضغط. تم اختباره جيدًا ، إلخ.

الضغط العالي أكثر تعقيدًا بعض الشيء. ومع ذلك ، يبدو أن هناك تطبيق LZMA (2) Go أصلي في حزمة github.com/ulikunitz/xz . هناك بعض التحذيرات حول الاستقرار والأداء في README. ليست هناك حاجة إلى غلاف xz ، نظرًا لأن لديك تجزئة وحجم غير مضغوطين بالفعل. يمكنني أن أعطيها دوامة وأرى كيف تقارن.

ألقيت نظرة على المصدر للعثور على المكان الطبيعي لإدخال خطوة الضغط. ما كان منطقيًا بالنسبة لي هو الضغط هنا وإزالة الضغط هنا . لكني أرى التحدي في تحديد وتتبع الضغط.

يمكنك أيضًا إلقاء نظرة على "مقدر الانضغاط" الذي صنعته. سيعطي تقديرًا سريعًا لمدى انضغاط كتلة البيانات. تعمل عادةً بسرعة> 500 ميجابايت / ثانية ، لذلك يمكن استخدامها لرفض البيانات التي يصعب ضغطها بسرعة.

يمكنك أيضًا إلقاء نظرة على "مقدر الانضغاط" الذي صنعته. سيعطي تقديرًا سريعًا لمدى انضغاط كتلة البيانات. تعمل عادةً بسرعة> 500 ميجابايت / ثانية ، لذلك يمكن استخدامها لرفض البيانات التي يصعب ضغطها بسرعة.

أحب مقدر الانضغاطية! يؤدي تجنب محاولات ضغط البيانات غير القابلة للضغط إلى زيادة السرعة.

يحتوي Zstd على شيء من هذا القبيل مضمّن: [1]

Zstd تمر بشكل أسرع على البيانات غير القابلة للضغط. توقع شيئًا> 1 غيغابايت / ثانية

على الرغم من أنني لم أجد أي معايير واضحة لذلك.

تبدو حزمة xz صفقة جيدة لـ lzma. أجرى بعض الاختبارات السريعة بالإعدادات الافتراضية:

| الخوارزمية | المستوى | حجم | بحجم | ميلي | ميغا بايت / ثانية | نسبة |
| ----------- | ------- | ------------ | ----------- | ---- ---- | -------- | -------- |
| lz4 | - | 1000000000 | 625968314 | 5454 | 174.85 | 62.60٪ |
| flatekp | 1 | 1000000000 | 391051805 | 12367 | 77.11 | 39.11٪ |
| flatekp | 5 | 1000000000 | 342561367 | 20164 | 47.3 | 34.26٪ |
| flatekp | 9 | 1000000000 | 324191728 | 43351 | 22 | 32.42٪ |
| lzma2 | | 1000000000 | 291731178 | 149437 | 6.38 | 29.17٪ |
| lzma | | 1000000000 | 291688775 | 161125 | 5.92 | 29.17٪ |

سرعة معقولة للغاية / مقايضة ضغط. كلها أداء أحادي النواة على enwik9 - نص متوسط ​​مضغوط. من الواضح أنه لم يكن لدي الوقت لاختبار صورة VM كاملة أو شيء مثل مجموعة 10GB مع محتوى مختلط أكثر.

لا يبدو أن lzma2 يقدم قدرًا كبيرًا في تنفيذه الحالي على lzma القياسي. نظرًا لأنك تتعامل مع الكتل الصغيرة ، يجب أن يكون الفرق صغيرًا جدًا.

Zstd لديه شيء من هذا القبيل مضمّن

نعم ، كما هو الحال مع lz4 وتفريغ الهواء ، ومع ذلك ، لم أره بسرعة مثل وظيفة مخصصة.

zstd مثير للإعجاب حقًا ، بلا شك. المعايير باستخدام تنفيذ cgo:

| المستوى | حجم | بحجم | ميلي | ميغا بايت / ثانية | نسبة |
| ------- | ------------ | ----------- | -------- | ------- - | -------- |
| 1 | 1000000000 | 358512492 | 5100 | 186.96 | 35.85٪ |
| 2 | 1000000000 | 332265582 | 6264 | 152.24 | 33.23٪ |
| 3 | 1000000000 | 314403327 | 8099 | 117.75 | 31.44٪ |
| 4 | 1000000000 | 310346439 | 8588 | 111.04 | 31.03٪ |
| 5 | 1000000000 | 305644452 | 12739 | 74.86 | 30.56٪ |
| 6 | 1000000000 | 292551252 | 18531 | 51.46 | 29.26٪ |
| 7 | 1000000000 | 287414827 | 23212 | 41.08 | 28.74٪ |
| 8 | 1000000000 | 282783804 | 27811 | 34.29 | 28.28٪ |
| 9 | 1000000000 | 280432907 | 31752 | 30.03 | 28.04٪ |

سامحني إذا فاتني شيء ما ، لكني لم أجد إجابة لهذه الأسئلة تمامًا في وقت سابق.

1. يبدو أننا نتحدث عن الضغط على مستوى الكتلة ، وليس على مستوى الملف ، أليس كذلك؟
2. إذا كان الأمر كذلك ، فمن الواضح أن هذا يحد من الفعالية حيث سيتم تخزين البيانات المكررة في أجزاء متعددة من ملف واحد وضغطها لكل جزء.
3. ومع ذلك ، من الواضح أن هذا يعتمد على حجم القطعة أيضًا.
4. إذن ، ما هو متوسط ​​حجم القطعة؟ يبدو أن هذا عامل مهم في مدى فائدة الضغط.
5. إذا كان حجم المقطع صغيرًا إلى حد ما ، فربما يجب أن نأخذ في الاعتبار ضغط الملف الكامل والمقطع مسبقًا للملفات شديدة الانضغاط (على سبيل المثال باستخدام مقدر

شكرا.

إذا قمنا بضغط الملفات بأكملها ، فقد يؤدي ذلك إلى العبث بخوارزمية إزالة التكرار مما يجعلها أقل كفاءة.

بخلاف ذلك ، دعونا لا ننسى أن أي ضغط مع تقديم مزايا هائلة من حيث

تضمين التغريدة

يبدو أننا نتحدث عن الضغط على مستوى الكتلة ، وليس على مستوى الملف ، أليس كذلك؟

نعم ، على مستوى القطعة.

إذا كان الأمر كذلك ، فمن الواضح أن هذا يحد من الفعالية حيث سيتم تخزين البيانات المكررة في أجزاء متعددة من ملف واحد وضغطها لكل جزء. ومع ذلك ، من الواضح أن هذا يعتمد على حجم القطعة أيضًا. إذن ، ما هو متوسط ​​حجم القطعة؟ يبدو أن هذا عامل مهم في مدى فائدة الضغط.

نحن نهدف إلى الحصول على 1 ميغا بايت ، لكن يمكن أن يصل حجمها إلى 8 ميغا بايت.

إذا كان حجم المقطع صغيرًا إلى حد ما ، فربما يجب أن نأخذ في الاعتبار ضغط الملف الكامل والمقطع مسبقًا للملفات شديدة الانضغاط (على سبيل المثال باستخدام مقدر

في البداية ، أود دمج الضغط على مستوى الكتلة ، ومعرفة مدى جودة أداء ذلك في سيناريوهات الحياة الواقعية. يمكننا إعادة النظر في هذه الفكرة لاحقًا.

klauspost شكرًا جزيلاً على الوقت الذي وتوصياتك ، أنا أقدر ذلك! في حين أنه من الجيد أن يكون لديك zstd ، أعتقد أن عدم الاعتماد على cgo هو أكثر أهمية للمشروع ككل. واستخدام مقدر الانضغاط فكرة رائعة ، أحب ذلك.

تبدو الأماكن التي ذكرتها لإضافة الضغط / إلغاء الضغط جيدة ، لكننا نحتاج إلى تتبع البيانات الوصفية لذلك في مكان آخر. أعتقد أننا سنضيف على الأرجح معنى إلى البتات في البايت في رأس الحزمة ، راجع http://restic.readthedocs.io/en/latest/100_references.html#pack -format. هذا هو الجزء الذي يجب القيام به بعناية فائقة.

لذا ، اسمحوا لي أن أنهي الرقم 1494 ، ثم سنرى أن هذا قد تم حله.

@ sanmai إعادة: القنوات الجانبية: لقد طرحت ذلك في الأصل.
تم اقتراح حلول مختلفة ، وأنا شخصياً سأكتفي بما يلي:

• وجود خيارات تكوين للإدراج في القائمة البيضاء / استخدام القائمة السوداء للضغط (على غرار ما لدينا لإدراج الملف)

كانت هناك فكرة أخرى تتمثل في محاولة إخفاء الحدود المقطوعة في ملفات الحزم ، مما سيجعل الأمر أكثر صعوبة من الناحية النظرية ، لكنني أشعر أنك ستظل قادرًا على تحديد وقت كتابة الشبكة ، والقنوات الجانبية مثل مدى نظام الملفات الذي تمت كتابة الجزء إليه وهكذا يمكن استخدامها لاستنتاج الحدود ، لذلك أشعر أن الطريقة الأكثر أمانًا / الأسهل هي النصح فقط بعدم ضغط البيانات الحساسة.

سيكون هذا رائعا! : بيرة: + 10 دولارات

فقط قم برميها هناك ، ولكن ضع جانبًا lzma أو أيًا من أنظمة الضغط الأكثر عمومية ، ماذا عن مجرد تشفير طول التشغيل أو الضغط الصفري؟ أم أن هذا لن يكون مفيدًا بما فيه الكفاية لعدد كافٍ من الناس؟

(لدي كلب في هذا البحث ، غالبًا ما أقوم بعمل نسخ احتياطي لملفات WAV الضخمة مع الكثير من الصمت).

+ 15 دولارًا

فقط قم برميها هناك ، ولكن ضع جانبًا lzma أو أيًا من أنظمة الضغط الأكثر عمومية ، ماذا عن مجرد تشفير طول التشغيل أو الضغط الصفري؟ أم أن هذا لن يكون مفيدًا بما فيه الكفاية لعدد كافٍ من الناس؟

مفيد أيضًا في النسخ الاحتياطي لمحركات أقراص VM التي تحتوي في الغالب على مساحة فارغة / ملفات متفرقة (لست متأكدًا مما إذا كان restic يدعم بالفعل النسخ الاحتياطي / استعادة الملفات المتفرقة)

bherila restic لا يدعم أرشفة / استعادة الملفات المتفرقة حتى الآن ، سيتم تخزين الملفات في الريبو كما لو كانت تحتوي فقط على العديد من الأصفار. هذه الكتل الكبيرة من الأصفار غير مكررة ، لذا لن تشغل مساحة كبيرة في الريبو. على الرغم من الاستعادة ، سينتهي بك الأمر بملف عادي (غير متفرق) بدون "ثقوب".

أردت فقط التحقق ، هل يوجد بالفعل نوع من الضغط؟ لقد قمت بعمل نسخ احتياطي للعديد من أجهزة الكمبيوتر ، بما في ذلك جهاز يحتوي على 50 غيغابايت من البيانات ، وأحصل على رقم أقل بكثير على الخادم:

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

Alwaysin من المحتمل أن يكون إلغاء البيانات المكررة ، ما لم يتم استبعاد بعض الملفات بالطبع.

rawtaz شكرًا لك ، لم أكن على علم

iluvcapra تم بالفعل تنفيذ سحق الكتل الكبيرة المتكررة من خلال إلغاء البيانات المكررة ، كما هو مذكور بواسطةrawtaz.

@ klauspost هل رأيت هذا؟ https://github.com/mvdan/zstd

نعم ، ولكن بصراحة وحدة فك ترميز الدفق هي الجزء السهل. لقد انتهيت من فك تشفير FSE ولدي برنامج تشفير Huffman جاهز. بمجرد الانتهاء من فك تشفير Huffman ، يكون مفكك تشفير تيار zstd واضحًا جدًا ، مع كون التشفير الكامل هو الجزء الأخير.

LZ4 كافية تمامًا وستكون أيضًا فوزًا سريعًا.

لماذا لا تضيف lz4 وتنشئ علاقات عامة أخرى لدعم zstd؟

لماذا لا تضيف lz4 وتنشئ علاقات عامة أخرى لدعم zstd؟

@ dave-fl لأننا نحتاج إلى توخي الحذر الشديد عند تعديل تنسيق المستودع. يجب أن يتم ذلك بطريقة متوافقة مع الإصدارات السابقة. أهم جزء في المشروع بأكمله هو تنسيق الريبو ، وليس التنفيذ. يعتمد الناس علينا في عدم إفساد التنسيق حتى يتمكنوا من استعادة بياناتهم :)

أعتقد أنه لا يمكننا الانتظار كثيرًا مع الضغط. لقد أجريت للتو بعض الاختبارات على عدد قليل من مستودعات النسخ الاحتياطية للخوادم ، ولم أفز بأي شيء عندما أقوم بإدخال gzip في المستودع! أعجبني Alwaysin ، فزت بالفعل بنسبة 30٪

حول الطريقة المتوافقة مع الإصدارات السابقة ، هل تقصد أنه يجب على Restic قراءة التنسيقات أو الأدوات للانتقال من التنسيق القديم إلى الجديد؟ عندما لا يكون Restic في الإصدار 1.0.0 ، أعتقد أنه لا بأس من مجرد الترحيل.

لقد أجريت للتو بعض الاختبارات على عدد قليل من مستودعات النسخ الاحتياطية للخوادم ، ولم أفز بأي شيء عندما أقوم بتطبيق gzip على المستودع!

هذا متوقع: جميع البيانات في الريبو مشفرة ، لذا فهي بالكاد قابلة للضغط على الإطلاق. إذا تم استخدام الضغط ، فيجب القيام به على البيانات قبل تشفيرها.

لا أرى كيف أن استخدام LZ4 يجعل الأشياء غير متوافقة مع الإصدارات السابقة. الضغط هو ضغط. لماذا لا تدعم صيغ متعددة؟

أنت على حق ، لم أفكر في ذلك.
ومع ذلك ، عندما أقوم بتنسيق gzip للمصدر ، لا أفوز بأكثر من 30٪ ، يكون إلغاء البيانات المكررة فعالاً للغاية بالفعل على دليل كبير به العديد من التكرارات. لكن بالطبع مع كليهما يمكن أن يكون مثيرًا للإعجاب.
باستخدام zpaq الذي يقوم بالضغط وإلغاء البيانات المكررة ، أفوز أكثر قليلاً ، وليس كثيرًا.
أنا منفتح جدًا لاختبار فرع بالضغط ، لا يهم إذا كان غير متوافق!

لا أرى كيف أن استخدام LZ4 يجعل الأشياء غير متوافقة مع الإصدارات السابقة. الضغط هو ضغط. لماذا لا تدعم صيغ متعددة؟

ماذا يحدث إذا كان هناك عميلان يستخدمان نفس الريبو ولكن أحدهما يستخدم إصدارًا قديمًا من restic لا يدعم الضغط؟ يجب تصميم هذه الميزة بعناية مع وضع جميع حالات الزاوية الممكنة في الاعتبار.

أفضل عدم وجود ضغط على نصف حل يعمل يمكن أن يكسر النسخ الاحتياطية السابقة.

أعتقد أنه كان هناك نقاش كافٍ حول مسألة إضافة الضغط. أستطيع أن أرى أنها ميزة منتظرة للغاية. سوف أتطرق إلى هذا بعد الانتهاء من كود الأرشيف الجديد (انظر # 1494).

من فضلك لا تضيف أي تعليقات أخرى ، شكرا!

dimejo ما

أجرؤ على القول أن إصدار CGO من zstd يبدو محمولًا إلى حد ما :)

لقد بحثت في مدى جدوى كتابة تنفيذ golang لـ zstd ، باختصار شديد ، بناءً على المواصفات .

zstd في الغالب جميع الخوارزميات الداخلية ولكن (اختياريًا) تعتمد على المجموع الاختباري xxHash-64 للتحقق من الأخطاء ، وهناك منفذ golang لذلك . نظرًا لأن البتات الاختيارية ، حسنًا ، اختيارية ، فلن تضطر إلى تنفيذ هذه الأجزاء للحصول على دعم zstd للقارئ / الكاتب في وضع الراحة. يدعم zstd مفهوم "القواميس" لتحسين الضغط - لست متأكدًا من كيفية تفاعل ذلك مع restict ، ولكن سيكون مجال بحث مثيرًا للاهتمام لضغط أجزاء معينة من الأرشيف ، على سبيل المثال JSON أو تدفقات البيانات الوصفية. وإلا يمكن أيضًا تخطي هذا التنفيذ لأنه اختياري.

حيث يصبح الأمر أكثر تعقيدًا ، بالطبع ، هو المكان الذي يبدأ فيه ترميز الانتروبيا. يستخدم zstd منهجًا جديدًا هناك يسمى Finite State Entropy (FSE ، وهو نوع من [ANS] (https://en.wikipedia.org/wiki/Asymmetric_numeral_systems#، منها فقط تطبيق C موجود أيضًا. يتم تنفيذ بتات ترميز إنتروبيا أخرى باستخدام تشفير huffman ، والتي يوجد منها العديد من التطبيقات ، بما في ذلك اثنان في المكتبة القياسية: واحد في compress.flate والآخر في net.http2.hpack ، وهو شيئ غير متوقع.

مما يمكنني قوله ، كل شيء آخر هو الغراء فوق ذلك ... بعض أشجار هافمان ، والتسلسلات ، والإطارات والكتل. هناك خصائص مثيرة للاهتمام في الطريقة التي يتم بها بناء الكتل والإطارات والتي قد يتم تعيينها بشكل جيد في نقاط الراحة ، مما قد يجعل من الممكن ضغط المستودع ككل مع الاحتفاظ بنقاط منفصلة بالداخل ، على الرغم من أنني لم أبحث في ذلك بالتفصيل . قد يجعل أيضًا الاقتران بين تنسيق المستودع والضغط غير مقبول.

يعد zstd أكثر تعقيدًا إلى حد كبير من gzip أو xzip ، حيث يحتوي على حوالي 70 ألف سطر من التعليمات البرمجية (وفقًا لـ cloc) مقارنة بـ 36 كيلو و 12 كيلو على التوالي. يتضمن اختبارات عديدة: عندما يتم تجاهلها ، فإن التطبيق نفسه يمكن مقارنته بـ gzip (34 كيلو بايت تقريبًا).

لذلك ، باختصار ، إنها مجرد مسألة وقت قبل أن يتم تنفيذ ذلك في البداية. أعتقد أن مثل هذا المحرك يمكنه أيضًا الاستفادة من توازي golang لأن "إطارات" zstd مستقلة عن بعضها البعض. ومع ذلك ، ليس من الواضح بالنسبة لي كيفية استخدام الإطار: معظم التدفقات التي اختبرتها بها إطار واحد فقط ( zstd /etc/motd ) أو إطاران ( zstd isos/Fedora-Workstation-Live-x86_64-27-1.6.iso ) (كما تم العثور عليه بواسطة binwalk -R "\x28\xb5\x2f\xfd" ) ، لذلك ربما لا يوجد مثل هذا الكسب هناك ، لأن الكتل مترابطة وأقل قابلية للتوازي ...

على أي حال ، كل شيء موضع نقاش ما لم يرغب شخص ما هنا في الجلوس فعليًا ونقل ذلك ، لكنني اعتقدت أنني سأشارك ما وجدته أثناء قراءة الشيء ... بالنظر إلى أن zstd هو امتداد لجزء LZMA من عائلة LZ77 من الضواغط ، يجب أن ليس من المجدي نقل ...

أي تحديث حول الضغط؟ أعلم أن الكثير من الأشخاص يرغبون في انتظار zstd ، ولكن ما الخطأ في تنفيذ lz4 أو lzo أو lzma ؟

إذا كان هناك تحديث ، فسيتم تحديث هذه المشكلة.

دعنا نحاول احترام طلب المؤلف في هذه الأثناء ، على الرغم من:

من فضلك لا تضيف أي تعليقات أخرى ، شكرا!

@ fd0 ، أردت فقط الإشارة إلى أنه يبدو أن هناك تطبيق Go خالصًا لخوارزمية zstd https://github.com/klauspost/compress/tree/master/zstd . لم أجرب هذا بنفسي. لكن هذا جعلني متحمسًا لإمكانية دعم الضغط في حالة الراحة.

لا أعرف أشياء Go zstd (السرعة؟ جودة الكود؟ الصيانة؟) ، لكن عناصر C zstd تدور حول كل ما تحتاجه أداة النسخ الاحتياطي لأنها تدعم نطاقًا واسعًا من الضغط السريع / القليل إلى الضغط الأبطأ / العالي.

إذا لم يكن لدينا بالفعل جميع algos الانضغاطية الأخرى (lz4، zlib، lzma) في borgbackup وسنبدأ في إضافة الضغط الآن ، أعتقد أننا يمكن أن نتعايش مع zstd فقط ولا شيء.

من حيث الذوق / التفضيل ، يمكن أن يكون الإعداد الافتراضي لا شيء (كما كان من قبل) أو مستوى zstd سريع جدًا (لا يزال هذا عمومًا يجعل معظم النسخ الاحتياطية أسرع نظرًا لوجود بيانات أقل لنقلها).

أهلا،
في رأيي ، الضغط ليس ضروريًا أن يكون لديك ميزة للراحة. لقد قارنت النسخة الاحتياطية لبياناتي التي تم إجراؤها باستخدام Duplicati (مع الضغط) و restic (بدون ضغط) وكانت المساحة الإجمالية المستخدمة متشابهة حقًا.
أحتاج إلى restic فقط للحصول على نسخة احتياطية تزايدية سريعة وموثوقة. لا حاجة لكسر الشيء ...
الاستعادة مهمة أيضًا والراحة مناسبة للتعافي من الكوارث. يعد Duplicati كابوسًا لأنك إذا فقدت ديسيبل المحلي ، فستستغرق مهمة الإصلاح أيامًا ...

شكرا لك @ fd0 وشكرا لجميع المساهمين!

filippobottega إذا لم تلاحظ فرقًا كبيرًا في تجربتك ، فهذا يعني أيضًا:

• أن بياناتك لم تكن (كثيرًا) قابلة للضغط (ولكن هذا ليس هو الحال بشكل عام) ، أو
• كانت تلك النسخ ذات كفاءة تخزين أسوأ غير مرتبطة بالضغط (على سبيل المثال بسبب تنسيق التخزين المختلف ، التفصيل ، الخوارزميات ، أيًا كان ...) ، لذلك تم تعويض وفورات الضغط عن طريق الخسائر في مناطق أخرى.

كلاهما لا يعني أن الضغط لا معنى له.

ThomasWaldmann لا أرى فرقًا كبيرًا للسبب الأول.
البيانات اليوم مضغوطة بالفعل بعدة طرق: docx و xlsx و pptx و zip و 7z و jpeg و tif وما إلى ذلك كلها تنسيقات مضغوطة. وأيضًا تحتوي صور ISO على ملفات مضغوطة. لهذا السبب فإن الضغط لا معنى له في حالة الراحة على ما أعتقد.

filippobottega إن وجهة

كانت عمليات تفريغ SQL هي أول ما فكرت به ، ولكن restic تدعم أيضًا خادم البريد الخاص بي ويبدو أنها تحصل على ضغط عام أفضل بناءً على بعض لقطات RAR التي التقطتها عند الانتقال من Duplicati إلى restic.

يمكنني رؤية حالة الاستخدام لجعل الضغط اختياريًا ولديك قائمة افتراضية لأنواع الملفات ، لكن الضغط سيوفر لي مبلغًا معقولاً من المال.

تضمين التغريدة

وجهة نظرك ضيقة الأفق إلى حد ما بشأن البيانات التي يستخدمها الأشخاص للنسخ الاحتياطي.

الآن ، لا داعي لأن تكون شخصيًا. وجهة نظره صالحة تمامًا مثل منظورك وهي تستحق النظر فيها. لقد وجدت أن معظم البيانات التي أقوم بنسخها احتياطيًا مضغوطة بالفعل بسبب تنسيقات الملفات.

ماذا عن مقالب SQL

هل حقا تقوم بتخزين مقالب SQL الخاصة بك غير مضغوطة؟ أنا gz كل ما لدي قبل نسخها احتياطيًا ، لأنني لست بحاجة إلى تخزينها بشكل خام.

شفرة المصدر ومجموعات البيانات والصور الأولية وما إلى ذلك

أعتقد أن حالة الاستخدام الصالحة الوحيدة للنسخ الاحتياطي المضغوط هي الملفات الكبيرة غير المضغوطة مع الكثير من التكرار _التي يتم استخدامها بنشاط وبالتالي لا يتم تخزينها مضغوطة بالفعل_. في تجربتي (التي تشمل سنوات من إدارة بيانات الآخرين) ، يندرج القليل جدًا من البيانات في هذه الفئة. على الأقل ، لا يكفي لإحداث فرق كبير في تلك الحالات.

ومع ذلك ، فإنه لا يفعل شيئًا لتقليل الحجم الأصلي لمجموعة البيانات.

يمكن القول ، هذه ليست وظيفة برنامج النسخ الاحتياطي. لا ينبغي أن تلمس البيانات الأصلية.

ناهيك عن أن تخزين تنسيق غير مضغوط ثم ضغطه + إلغاء المضاعفة يمكن أن يؤدي إلى نتائج أفضل من إزالة تكرار الملفات المضغوطة بالفعل.

تعتمد العديد من خوارزميات الضغط على الازدواجية للقيام بعملها (انظر قواميس flate) ، لذلك لست مقتنعًا بهذا _ بشكل عام_ على الرغم من أنني أوافق على أن هذا صحيح في بعض الأحيان على الأقل.

(أنا لا أقول أن الضغط في restic هو _bad_ عند القيام به بشكل صحيح ، أنا فقط أزعم أنه لا يلزم أن يكون أولوية - خاصة بالمقارنة مع مشكلات الأداء العالقة - ويجب علينا احترام قيود الوقت الخاصة بـ @ fd0 و رغبات فيما يتعلق بالرؤية.)

mholt أوافق بشكل عام ، ولكن إجراء نسخ احتياطي للجذر (عبر بعض التفريغ أو حتى التكرار على محتويات /) ، ينتج عنه نسبة ضغط جيدة بالنسبة لي. ليس ضروريًا ، نظرًا لأن الإجمالي المستخدم صغير بالفعل ، لكني أحصل على توفير حوالي 50٪ ، وهذا أمر رائع دائمًا الحصول عليه "مجانًا" بقدر ما يتعلق الأمر بالمستخدم النهائي.

جرب هذا الاختبار.

1. خذ تفريغ SQL أو بعض الملفات غير المضغوطة الأخرى. قم بضغطه ثم
   استخدم restic احتياطيًا.
2. إزالة جدول من قاعدة بيانات SQL ، ثم تفريغ ثانيًا ، ثم ضغطه ،
   ثم استخدم restic لدعمه.

أعتقد أنك ستجد ذلك لأن الضغط يتم قبل ذلك
إلغاء البيانات المكررة سوف تهزم بالكامل تقريبًا خوارزمية حذف البيانات المكررة.
ومع ذلك ، إذا كان باستطاعة restic التعامل مع الضغط بعد إزالة المكررة لك
يجب أن تحصل على ناتج إجمالي أصغر بكثير.

في صناعة تخزين المؤسسات باستخدام أدوات مثل DataDomain ، فهي دائمًا
يوصى بتغذية البيانات إلى جهاز التخزين بشكل غير مضغوط
التنسيق والسماح للجهاز بالقيام بإزالة البيانات المكررة ثم الضغط. ال
الترتيب العام الذي يجب تطبيق هذه الأدوات فيه هو إلغاء المكررة ،
الضغط ثم التشفير. فكر في هذا لثانية .... هل أنت
تريد حقًا إنفاق كل وحدة المعالجة المركزية الإضافية لضغط نفس البيانات المتعددة
مرات فقط حتى يتم التخلص منها والتخلص منها بشكل أساسي على أي حال؟ إنه
متفقًا بشكل عام على أنه من الأفضل تقليل مجموعة البيانات من خلال حذف البيانات أولاً
قبل إنفاق المهمة الصعبة المحتملة المتمثلة في الضغط.

يوم الجمعة ، 2 أغسطس ، 2019 الساعة 1:29 مساءً براندون شنايدر إخطارات @
كتب:

mholt https://github.com/mholt أوافق بشكل عام ، ولكن أفعل
نسخة احتياطية من الجذر (عبر بعض التفريغ أو حتى التكرار على محتويات /) ،
ينتج نسبة ضغط جيدة بالنسبة لي. ليس ضروريا ، مثل المجموع
المستخدم صغير بالفعل ، لكني أحصل على توفير حوالي 50٪ ، وهذا أمر رائع دائمًا
الحصول عليها "مجانًا" بقدر ما يتعلق الأمر بالمستخدم النهائي.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/restic/restic/issues/21؟email_source=notifications&email_token=AC3I762ZVGTTJL4TF3ODZILQCRVIXA5CNFSM4AXPP352YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63TNM
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AC3I767IQQD3CZBIWM37C6TQCRVIXANCNFSM4AXPP35Q
.

هل حقا تقوم بتخزين مقالب SQL الخاصة بك غير مضغوطة؟ أنا gz كل ما لدي قبل نسخها احتياطيًا ، لأنني لست بحاجة إلى تخزينها بشكل خام.
يمكن القول ، هذه ليست وظيفة برنامج النسخ الاحتياطي. لا ينبغي أن تلمس البيانات الأصلية.

يبدو أن هذا النوع من العرض يعيق التخزين الفعال للبيانات؟ فكرة أن كل برنامج وعملية تصدير يجب أن تنفذ تنسيق الضغط المخصص الخاص بها هي شيء أحاول الابتعاد عنه ، لأنه يمنع إلغاء التكرار / الضغط / وما إلى ذلك من العمل على أي شيء باستثناء النطاق المحدد مسبقًا لكل ملف (أو نطاق تار الدليل) . يفقد ضغط الملفات بشكل فردي القدرة على إيجاد القواسم المشتركة عبر الملفات / التفريغات المختلفة / إلخ ، وبالتالي تفقد جميع مزايا إلغاء البيانات المكررة. يتيح الاحتفاظ بالأشياء غير مضغوطة لنظام ملفات (zfs و btrfs وما إلى ذلك) القيام بكل هذا من أجلك ، وأفضل لأنه يمكن ضغطه وإزالته عبر المجلدات ، واللقطات ، وما إلى ذلك ، وتجريد كل هذا بعيدًا مع الاحتفاظ بالتوافق مع الأدوات التي تحتاج إلى العمل مع البيانات غير المضغوطة.

يمكن النظر إلى الضغط على أنه مجرد تحسين إضافي لإلغاء تكرار برنامج restic العلوي ، ولكن يبدو أنهما غير متوافقين مع بعضهما البعض إذا تم القيام بهما بشكل منفصل ... اقتراح أن يقوم المرء بضغط الملفات ومعالجتها مسبقًا قبل نسخها احتياطيًا يعيد كل شيء إلى سير العمل حيث يمكنك ذلك أيضًا فقط استخدم rsync / rclone بدلاً من ذلك ، فلماذا تستخدم restic في المقام الأول؟

يبدو أن هذا النوع من العرض يعيق التخزين الفعال للبيانات؟ فكرة أن كل برنامج وعملية تصدير يجب أن تنفذ تنسيق الضغط المخصص الخاص بها هي شيء أحاول الابتعاد عنه ، لأنه يمنع إلغاء التكرار / الضغط / وما إلى ذلك من العمل على أي شيء باستثناء النطاق المحدد مسبقًا لكل ملف (أو نطاق تار الدليل) . يفقد ضغط الملفات بشكل فردي القدرة على إيجاد القواسم المشتركة عبر الملفات / التفريغات المختلفة / إلخ ، وبالتالي تفقد جميع مزايا إلغاء البيانات المكررة. يتيح الاحتفاظ بالأشياء غير مضغوطة لنظام ملفات (zfs و btrfs وما إلى ذلك) القيام بكل هذا من أجلك ، وأفضل لأنه يمكن ضغطه وإزالته عبر المجلدات ، واللقطات ، وما إلى ذلك ، وتجريد كل هذا بعيدًا مع الاحتفاظ بالتوافق مع الأدوات التي تحتاج إلى العمل مع البيانات غير المضغوطة.

إنها ليست مجرد تخزين فعال للبيانات ، بل هي أيضًا مهام سير العمل الحالية. أريد منتجًا احتياطيًا لنسخ بياناتي احتياطيًا بشكل موثوق وفعال ، وليس فرض مهام سير العمل عبر جوانب أخرى من النظام. من الأهمية بمكان تخزين النسخ الاحتياطية (التي يتم الاحتفاظ بها ، على الأرجح إلى أجل غير مسمى) بكفاءة بينما يجب تخزين بيانات العمل الحية بأفضل تنسيق لكيفية استخدامها بنشاط.

الآن هناك حالات يكون من المنطقي فيها الضغط قبل التخزين ، خاصة مع البيانات القابلة للضغط على أنظمة التخزين البطيئة ، ولكن هذا هو الاستثناء أكثر من القاعدة في تجربتي.

سيساعدني ضغط +1 حقًا! في العمل كمهندس برمجيات ، أقوم بعمل نسخة احتياطية من مجلد منزلي بالكامل ، والذي يحتوي على الكثير من التعليمات البرمجية المصدر غير المضغوطة (وفي اللغات الديناميكية ، مثل الياقوت أو الثعبان ، يكون دائمًا رمز المصدر - حتى معظم التبعيات).

في المنزل ، أقوم بعمل نسخة احتياطية من كامل / ، مرة أخرى بما في ذلك العديد من الأشياء التي تستفيد من الضغط ، مثل الثنائيات ، والملفات البشرية ، وملفات الموارد ، وما إلى ذلك.

بالطبع يمكنني ضغطها جميعًا ، وإجراء العديد من التحولات قبل نسخها احتياطيًا ، لكن هذا سيهزم الكثير من الراحة في مجرد تشغيل أمر بسيط للغاية ، والقدرة على الحصول على نسخة احتياطية ، وكذلك بسهولة استعادة الأشياء.

الآن بالطبع هناك العديد من فئات الملفات التي لا يتم ضغطها جيدًا ، لكن لا أحد يقول إنه يجب إجبارها على الضغط. هناك العديد من الطرق لحل هذا - القائمة البيضاء لأنواع الملفات التي يجب ضغطها ، أو القائمة السوداء للملفات التي لا ينبغي أن تكون ، أو حتى أبسطها: حاول الضغط ، وإذا لم يتحسن الحجم الناتج ، فقم بتخزينه غير مضغوط (أعتقد أن ZFS يستخدم هذا الأسلوب عند تمكين الضغط على القرص).

في النهاية ، يعد الضغط مثالًا على المقايضة الكلاسيكية بين المساحة والوقت: هل تريد دفع المزيد من وحدة المعالجة المركزية أو المزيد من التخزين؟ في حالتي ، يهيمن التخزين على تكاليفي ، لذلك أعتقد أنه سيكون من الرائع أن يتم تسخين رباعي النواة أكثر قليلاً ، ثم كانت فاتورة استضافة الملفات الخاصة بي أصغر.

أخيرًا ، قمت بإجراء نسخ احتياطي يزيد قليلاً عن 4 تيرابايت إلى مزود خدمة سحابية وكانت سرعة التحميل الخاصة بي ضعيفة على أي حال ، لذا فإن ضغط المكافأة سيجعل عملية النسخ الاحتياطي أسرع ، وليس أبطأ - يمكن لوحدة المعالجة المركزية الخاصة بي أكثر من مواكبة اتصال VDSL الضعيف .

نعم ، يمكنني فقط أن أتفق مع كل الآخرين هنا. يعد الضغط أمرًا مهمًا جدًا ولا أرى أي جدال حول سبب عدم استخدام restic له.

@ mholt أتفق معك تمامًا. كل كلمة.
يأتي ضغط سلسلة الأدوات الخاص بي قبل إزالة البيانات المكررة بشكل مريح لأنني ، على سبيل المثال ، أستخدم TFS كعنصر تحكم بالمصدر وجميع المصادر مضغوطة بالفعل في نسخ SQL الاحتياطية ويتم ضغط صور التطبيق في ملفات إعداد msi أو أرشيفات 7z. أحتاج فقط إلى طريقة سريعة وبسيطة للحصول على دلتا كل يوم وإرسالها إلى السحابة لتنفيذ خطة آمنة للتعافي من الكوارث.
أعتقد أن @ fd0 يحتاج إلى تركيز وقته لحل المشكلات بدلاً من محاولة إضافة تعقيد آخر إلى المنتج.

فقط تناغم مع القليل من المقارنة التي أجريتها بين borg باستخدام ضغط auto,zstd و restic (بدون ضغط) ، أولاً على / ، ثم على /home ، باستثناء أشياء مثل صور VM و صور عامل ميناء (بما أنني لا أقوم بنسخها احتياطيًا في نسخة احتياطية حقيقية أيضًا). كانت آلة الاختبار هي آلة تطوير البرامج اليومية الخاصة بي ، والتي تحتوي على العديد من الملفات الثنائية ، وبعض الصور المضغوطة وملفات الصوت ، ولكن أيضًا قدرًا لا بأس به من شفرة مصدر النص العادي ، والتي يجب ضغطها بشكل جيد:

/ : 1053136 ملفًا ، 92.9 جيجا بايت

• برج ، بلا: 17:27 دقيقة ، 64.1 جيجابايت
• برج ، zstd: 19:29 دقيقة ، 40.6 جيبي بايت
• restic: 09:45 دقيقة ، 62.4 جيجا بايت

/home : 221338 ملفًا ، 58.3 جيجا بايت

• برج ، zstd: 09:06 دقيقة ، 30.7 جيجابايت
• restic: 04:36 دقيقة ، 39.4 جيبي بايت
  لقد حذفت borg بدون ضغط هنا ، حيث إنها تقريبًا نفس الراحة فيما يتعلق بمساحة التخزين.

أولاً ، أود أن أشيد بـ restic لكونه أسرع مرتين تقريبًا في حالة الاختبار هذه. بصرف النظر عن كون borg أبطأ ، قد يكون من المثير للاهتمام أن الضغط يضيف فقط دقيقتين تقريبًا إلى إجمالي مدة النسخ الاحتياطي (+ 11٪) ، ولكنه يقلل بشكل كبير من البيانات المراد تخزينها للحالة / (-35 ٪). في حالة دليلي الرئيسي ، تبلغ نسبة التوفير في التخزين 20٪ تقريبًا.

(تم إجراء الاختبار على قرص خارجي لهذه الحالة. عند النسخ الاحتياطي إلى وحدة تخزين بعيدة ، يعتمد الوقت الذي يستغرقه النسخ الاحتياطي في الغالب على عرض النطاق الترددي للتحميل ، على الأقل عندما تكون سرعة وحدة المعالجة المركزية وسرعة الإدخال / الإخراج أعلى بكثير من الشبكة. لقد اختبرت هذا و borg مع الضغط هو في الواقع أسرع من restic بعد ذلك ، لأن الضغط يؤدي إلى نقل بيانات أقل). الكل في الكل ، أنا أؤيد بشدة الحصول على دعم للضغط ، من الناحية المثالية باستخدام الاكتشاف التلقائي للتحقق مما إذا كانت الكتلة تستفيد من الضغط.

@ nioncode إذا كانت حساباتي صحيحة ، يمكنك إجراء نسخ احتياطي لحوالي

أعلم أن أرشفة الأجهزة الافتراضية قد تكون حالة استخدام ولكني أحاول تجنب الحاجة إلى القيام بذلك.
أحاول أتمتة مبنى VM بأكمله بدءًا من ملفات iso والإعداد.
في حالة التعافي من الكوارث ، أريد أن أكون قادرًا على استعادة الجهاز الظاهري بالكامل باستخدام النسخ الاحتياطي لملفات الإعداد والمستندات وقواعد البيانات الاحتياطية. وأنا أحاول القيام بذلك دون تدخل المستخدم.
بهذه الطريقة يمكنني تجنب الحاجة إلى ضغط الكثير من ملفات المهملات الموجودة في جهاز افتراضي مثل ملفات temp والملفات غير المضغوطة مثل exe و dll وما إلى ذلك.
أعلم أن الأمر ليس بالأمر السهل ، لكن يمكنني تجنب ضغط وإلغاء تكرار نفس الملفات غير المفيدة التي توفر مساحة على القرص وعرض النطاق الترددي.

دعونا لا نشوش هذا الخيط حول من يفعل الأشياء وكيف. لقد كان كافيا.

يعد الضغط ميزة يريدها الكثير من الأشخاص (بما فيهم أنا) ويمكنه توفير مساحة تخزين النسخ الاحتياطي ووقت التحميل في حالة اتصال الإنترنت البطيء والمتوسط ​​، بالنسبة لبعض الأشخاص حتى 30٪ أو أكثر.

ومع ذلك ، لا يحتاج الجميع إلى ذلك ، وقد قام بعض الأشخاص بتكييف سير العمل بطريقة ذكية للتعامل معه - أو ببساطة لديهم المال أو النطاق الترددي أو كليهما لمجرد عدم الاهتمام.

على أي حال ، تحدث الطرفان.

@ bjoe2k4 أو تشعر بالقلق إزاء الآثار الأمنية السلبية لضغط البيانات قبل تشفيرها ، مما يعطي معلومات حول بيانات النص العادي ، كما تم طرحه أيضًا كحجة عدة مرات في هذا الموضوع خلال السنوات القليلة الماضية. :)

ما لم يصبح الضغط إلزاميًا ، فإن المخاوف الأمنية للضغط هي ببساطة مقايضة يمكن للمستخدم إجراؤها. سآخذ نسخًا احتياطيًا أسرع وخفض التكاليف الشهرية ومرة ​​واحدة على هذه المخاطر النظرية (خطر لا يمكن استغلاله على أي حال لأن مجموعات البيانات الخاصة بي كبيرة والتغييرات غير متوقعة ، لذا فإن الضوضاء ستغرق أي محاولة لتوليد إشارة من الضغط).

لا أعتقد أن أي شخص يتحدث عن جعل الضغط إلزاميًا.

حالة الاستخدام الخاصة الخاصة بي هي إجراء نسخ احتياطي لمجموعات كبيرة من عمليات تفريغ CSV و SQL. ستكون هذه الملفات قابلة للضغط جدًا ... ولا أريد / لا يمكنني الضغط عليها مسبقًا.

أرغب حقًا في الحصول على ميزة الضغط لأنني أدفع مقابل كل مساحة تخزين على الإنترنت غيغابايت

نظرًا لأن هذه المناقشة أصبحت أكثر نشاطًا الآن ، أود أن أشارك بعض النتائج التي توصلت إليها مع نسخة مصححة من بعض أصدقائي. لقد أضافوا ضغطًا إلى restic (أكثر أو أقل سرعة وقذرة على حد علمي) وسوف أخطرهم بهذا المنشور حتى يتمكنوا من التعليق على تفاصيل التنفيذ إذا كان أي شخص مهتمًا.
حالة الاستخدام الخاصة بي هي بعض البرامج المصرفية القبيحة حقًا التي لها تنسيق قاعدة البيانات الخاصة بها. يتعين علينا استخدام هذا البرنامج لأسباب تنظيمية والبيانات التي لدينا هي عدة تيرابايت من الملفات الكبيرة إلى حد ما والتي يمكن ضغطها حتى 90٪ من حجمها الأصلي. لذلك ، من الواضح تمامًا أن الضغط سيوفر لنا الكثير في تخزين النسخ الاحتياطي وأوقات النسخ الاحتياطي وأوقات الاستعادة.
النتائج التي توصلت إليها عند مقارنة restic upstream ، يمكن العثور على restic المصحح بالضغط وحل النسخ الاحتياطي الحالي مع القطران هنا: https://gist.github.com/joerg/b88bf1de0ce824894ffc38f597cfef5f

| أداة | وقت النسخ الاحتياطي (م: ث) | وقت الاستعادة (م: ث) | مساحة النسخ الاحتياطي (G) | مساحة النسخ الاحتياطي (٪) | النسخ الاحتياطي (ميغا بايت / ثانية) | استعادة (ميغا بايت / ثانية) |
| --------------------------- | ----------------- | ------------------ | ---------------- | ---------------- | ------------- | -------------- |
| القطران | 4:42 | 5:19 | 11 | 9.6٪ | 404 | 357 |
| Restic S3 المحلي المنبع | 10:04 | 30:56 | 102 | 89.5٪ | 189 | 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 |
| Restic S3 Remote Upstream | 17:12 | 46:06 | 102 | 89.5٪ | 110 | 41 |
| ريستيك S3 عن بعد ضاغط | 5:27 | 21:42 | 8.6 | 7.5٪ | 349 | 88 |

أعتقد أن restic سيكسب بشكل كبير مع الضغط الاختياري من أي نوع لأنه يقلل إلى حد كبير من كل شيء.

لن يكون لكل ملف نسبة ضغط مثيرة للاهتمام. ربما يكون ضغط ملف فيديو لا قيمة له ولكن ضغط تفريغ SQL هو بالتأكيد. لهذا السبب تحاول أنظمة الملفات مثل Btrfs أولاً ضغط أول 128 كيلوبايت من الملف وإذا كانت هناك نسبة ضغط كبيرة فستضغط الملف بأكمله. إنه بالتأكيد ليس مثاليًا ولكنه سريع ويجب أن يعمل مع معظم حالات الاستخدام إذا تقرر ضغط الملفات بشكل فردي.

بالنسبة لأولئك الذين يجادلون ضد توفير الضغط كخيار ، فإن حالة الاستخدام الخاصة بي هي أنني أقوم بعمل نسخة احتياطية من مزيج من أنواع الملفات القابلة للضغط في الغالب والتي لا أتحكم في محتواها ومن غير المعقول توقع أن أضطر إلى ضغط البيانات على أجهزة متعددة (والتي إما تشغل مساحة أكبر على القرص المحلي في حالة الضغط إلى أرشيف جديد أو تجعل الملفات غير قابلة للاستخدام من خلال التطبيقات المرتبطة بها إذا تم ضغطها في مكانها) قبل إجراء عملية النسخ الاحتياطي.

أفضل أن أكون قادرًا على استخدام restic كأداة نسخ احتياطي لـ DR ، لكنني حاليًا أستخدم borg (متطلبات ذاكرة الوصول العشوائي البطيئة الضخمة ، إلخ) لأن الضغط الناتج + الإلغاء الذي يحققه يوفر لي العديد من الجيجابايت من نقل الشبكة لكل عملية نسخ احتياطي و بسهولة على مساحة تخزين كبيرة (والتي أدفع مقابلها شهريًا) في السحابة على كامل مجموعة النسخ الاحتياطية الخاصة بي. سأكون قادرًا على الاحتفاظ بالنسخ الاحتياطية لفترة أطول أو تقليل تكاليف التخزين إذا دعم الضغط الثابت.

مرحبًا joerg ، شكرًا لك على مشاركة اختباراتك.
هل حاولت إجراء نسخ احتياطي باستخدام restic لإخراج مهمة ضغط القطران؟
أشعر بالفضول بشأن مقارنة "Restic S3 Remote Compress" و "Tar" + "Restic S3 Remote Upstream".
علاوة على ذلك ، يبدو أن ما تقوله ليس صحيحًا حقًا:

أعتقد أن restic سيكسب بشكل كبير مع الضغط الاختياري من أي نوع لأنه يقلل إلى حد كبير من كل شيء

عند رؤية نتائج الاختبار ، يبدو أن وقت وحدة المعالجة المركزية الذي يحتاجه restic أطول بمقدار 2x للنسخ الاحتياطي المحلي و 6 مرات أطول عند الاستعادة. ليست جيدة حقًا مقارنة بالقطران.

القطران ليس خوارزمية ضغط. بالطبع إنه سريع.
تحرير: أوه و راجع للشغل. إذا قمت بتعريف دليل ما ، فلن يستخدم سلاسل رسائل متعددة لكل ملف ولن يعمل أيضًا مع ملفين أو أكثر في وقت واحد ، وبدلاً من ذلك سيقوم بمسح الدليل وإضافة ملف ثم الانتقال إلى التالي. بطئ جدا. لكن المشكلة تكمن في ملف الأرشيف الذي لم يتم تصميمه للإضافة بخيوط متعددة.

عند رؤية نتائج الاختبار ، يبدو أن وقت وحدة المعالجة المركزية المستخدم بواسطة restic أبطأ بمقدار 2x في النسخ الاحتياطي المحلي و 6 x أبطأ عند الاستعادة. ليست جيدة حقًا مقارنة بالقطران.

لست متأكدًا تمامًا من وجهة نظرك هنا. restic أبطأ من القطران ، بالتأكيد ، لكن restic مع الضغط يكون دائمًا أسرع من restic بدونه ، لذلك من الواضح أن restic سيستفيد.

تعد Tar مقارنة مفيدة من "أفضل حالة على هذا الجهاز" ، ولكنها تفتقر إلى معظم ميزات restic الأخرى (تتبادر إلى الذهن اللقطات وإلغاء البيانات المكررة). يبدو أن إضافة الضغط يؤدي فقط إلى تحسين أوقات النسخ الاحتياطي وأوقات الاستعادة وتكاليف التخزين ، وكل الأشياء المهمة لمنتج النسخ الاحتياطي.

joerg هل يستطيع أصدقاؤك فتح "طلب سحب" وإتاحة تصحيحاتهم للراحة مع الضغط للجمهور؟ ما هي خوارزمية الضغط التي يستخدمونها؟

تضمين التغريدة
أعتذر ، لقد أسأت فهم معنى تأكيد

يرجى الانتباه إلى أننا لا نستخدم أرشيفات القطران العارية ، ولكن ملفات gzip مع تطبيق zip موازٍ خاص ، وإلا فإن أرشفة تيرابايت من البيانات قد تستغرق أيامًا بدلاً من الساعات "فقط" التي تستغرقها الآن: https: //gist.github. com / joerg / b88bf1de0ce824894ffc38f597cfef5f # tarpigz
shibumi لقد أبلغتهم بهذه المشكلة

الضغط ليس خيارًا مناسبًا للتشفير. يسمح للمهاجمين بتخمين ما إذا كان المستودع المشفر يحتوي على ملف معين كقسم (جزء) من ملف يتم ضغطه بنفس الحجم بغض النظر عن مفتاح التشفير المستخدم. هذه ثغرة معروفة جيدًا لبروتوكولات التشفير ، ولهذا السبب تمت إزالة الضغط من TLS 1.3.

دعونا لا نخلق مشكلة معروفة حيث لا يوجد شيء ، أليس كذلك؟

(أعتقد أن هذه المشكلة قد تم ذكرها بالفعل ، ومن المحتمل ألا تكون مرة واحدة. لا تزال هذه المشكلة مفتوحة ، حيث أشعر أنه لهذا السبب الوحيد يجب إغلاقها مرة واحدة وإلى الأبد).

لماذا تقوم بإرسال رسائل غير مرغوب فيها إلى المشكلة؟ :( لقد تمت مناقشته مرات عديدة لدرجة أنه يكاد يكون خارج نطاق الموضوع. لن يتم إجبارك على تمكين الضغط !!

علاوة على ذلك ، أعتقد أن فكرة الهجوم الخاصة بك تتطلب أن يكون المهاجم قادرًا على التحكم في البيانات ليتم ضغطها وتشفيرها (لست متأكدًا من ذلك!). https://en.m.wikipedia.org/wiki/CRIME

ولكن على أي حال ، حتى لو كان ذلك مصدر قلق أمني ، فقد يرغب شخص ما في استخدام الضغط فقط على وحدة تخزين تحت سيطرته الخاصة لتوفير مساحة التخزين ببساطة.

حتى أن وجود ميزة اختيارية تضعف التشفير يدعو إلى شعور زائف بالأمان. يدعي Restic أنه برنامج نسخ احتياطي _secure_. ستؤدي إضافة ضغط اختياري إلى إبطال هذا الوعد حيث لا يمكنك أن تكون آمنًا في بعض الأحيان ، فقط بدوام كامل ، طوال الوقت. وستكون هناك تقارير عن مكافحة التطرف العنيف بالتأكيد. من يريد لبرامجهم هذا النوع من "الشعبية"؟

لكني أعتقد أن إضافة ضغط بطريقة لن يتم استخدامه مع التشفير هو خيار قابل للتطبيق.

FWIW في عام 2017 ، قمت بعمل عرض توضيحي حيث قمت بتجريد التشفير من Restic ، وأظهرت أن الضغط يمكن أن يكون فعالًا للغاية . مائة مرة فعالة. يمكن إضافة ضغط IIRC كنوع من الغلاف تمامًا مثل التشفير ، لكنني لم ألقي نظرة على الكود لفترة طويلة ، لذا قد تكون الأمور أصعب هذه الأيام ، أو أسهل.

في الواقع ، تحتاج CRIME إلى معرفة طول النص المشفر ، وهو أمر مستحيل أساسًا في restic.
كما لا يوجد برنامج نسخ احتياطي "آمن". إذا كانت ملفات النسخ الاحتياطي يمكن الوصول إليها من قبل أطراف ثالثة ، فهناك دائمًا احتمال أن يتمكن شخص ما من العبث أو ما هو أسوأ من ذلك ، اقرأ البيانات.
لذا فإن القول بأن الضغط يزيد الأمر سوءًا هو مجرد غباء.

في الواقع ، تحتاج CRIME إلى معرفة طول النص المشفر

تحتاج الجريمة ولكنك لا تحتاج. تخيل أنك صحفي استقصائي أعطيت لك مجموعة من الملفات السرية للغاية من قبل مصدرك. يمكنك نسخها احتياطيًا بالتشفير ولن يعرف أحد أن لديك هذه الملفات.

تخيل الآن أنك لم تكن ذكيًا بما يكفي لتمكين الضغط ، والآن سيعرف أي شخص آخر ، ممن لديهم أيضًا هذه الملفات ، بناءً على أحجام الأجزاء المضغوطة ثم المشفرة ، أن لديك هذه الملفات السرية للغاية في هذا الأرشيف بدون حتى في حاجة إلى معرفة مفتاح التشفير. هذا أبعد ما يكون عن الأمان. يمكن للناس أن يذهبوا إلى السجن بسبب هذه "الميزة" ، أو أن يتعرضوا للتعذيب ، أو أسوأ من ذلك.

لا يوجد برنامج نسخ احتياطي "آمن"

هذا يحتاج بعد ذلك إلى تحديث.

لاحظ أيضًا أنه آمن افتراضيًا.

مخازن restic معبأة قطع فقط ، وبالتالي فإن حجم القطع غير واضح
شخص ما ليس لديه المفاتيح.

في الجمعة ، 09 أغسطس ، 2019 الساعة 02:09:23 صباحًا -0700 ، كتب أليكسي كوبيتكو:

الضغط ليس خيارًا مناسبًا للتشفير. يسمح للمهاجمين بتخمين ما إذا كان المستودع المشفر يحتوي على ملف معين كقسم (جزء) من ملف يتم ضغطه بنفس الحجم بغض النظر عن مفتاح التشفير المستخدم. هذه ثغرة معروفة جيدًا لبروتوكولات التشفير ، ولهذا السبب تمت إزالة الضغط من TLS 1.3.

دعونا لا نخلق مشكلة معروفة حيث لا يوجد شيء ، أليس كذلك؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/restic/restic/issues/21#issuecomment -519844526

-
(Escriu-me xifrat si saps PGP / اكتب مشفرًا إذا كنت تعرف PGP)
مفتاح PGP 7CBD1DA5 - https://emailselfdefense.fsf.org/

لمن يريد معرفة المزيد عن هذه المخاوف الأمنية ، هناك ورقة لطيفة تصفها http://www.iacr.org/cryptodb/archive/2002/FSE/3091/3091.pdf
حسب فهمي ، قد يكون هناك عيب إذا تم تقسيم الملف ثم ضغطه وتشفيره. ولكن إذا تم ضغط الملف قبل تقسيمه ، فسيكون ملفًا ثنائيًا مثل أي ملف آخر ويصبح هجوم النص العادي عديم الفائدة.

ولكن إذا تم ضغط الملف قبل تقسيمه ، فسيكون ملفًا ثنائيًا مثل أي ملف آخر ويصبح هجوم النص العادي عديم الفائدة.

هذا صحيح. لكن هذا لن يساعد بالضبط في إزالة البيانات المكررة بشكل فعال إذا فهمت بشكل صحيح لأن خوارزمية الضغط قد تستخدم مفردات مختلفة لكل إصدار من الملف مما يؤدي إلى نتيجة ثنائية مختلفة تمامًا. الذي من الواضح أنه لن يزيل تكرار. خلاف ذلك ، من المنطقي فقط ضغط الأجزاء الناتجة.

يخزن restic قطع معبأة فقط ، وبالتالي فإن حجم القطع ليس واضحًا لشخص ليس لديه المفاتيح

هذا مريح.

وجهة نظري لا تزال قائمة: هناك العديد من الطرق التي يمكن للمرء أن يضيف بها نقطة ضعف خفية إلى البرنامج عندما ينفذ الضغط مع التشفير ، لذلك من الأفضل عدم إضافة نقطة على الإطلاق. حتى خبراء التشفير الذين يقررون 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 فقط إذا كان لديك عدة إصدارات مختلفة من الملفات المشفرة.
أي عمليات نسخ احتياطي متعددة (إلى مستودعات مختلفة ، حيث حصل المهاجم عليها جميعًا)
كما أنه يعمل فقط من خلال كمية صغيرة من البيانات.

تحتاج الجريمة ولكنك لا تحتاج. تخيل أنك صحفي استقصائي أعطيت لك مجموعة من الملفات السرية للغاية من قبل مصدرك. يمكنك نسخها احتياطيًا بالتشفير ولن يعرف أحد أن لديك هذه الملفات.

تخيل الآن أنك لم تكن ذكيًا بما يكفي لتمكين الضغط ، والآن سيعرف أي شخص آخر ، ممن لديهم أيضًا هذه الملفات ، بناءً على أحجام الأجزاء المضغوطة ثم المشفرة ، أن لديك هذه الملفات السرية للغاية في هذا الأرشيف بدون حتى في حاجة إلى معرفة مفتاح التشفير. هذا أبعد ما يكون عن الأمان. يمكن للناس أن يذهبوا إلى السجن بسبب هذه "الميزة" ، أو أن يتعرضوا للتعذيب ، أو أسوأ من ذلك.

هذا هراء. لأنه لا يعمل إلا مع حجم عينة صغير. لا يزال من الممكن أيضًا أن تذهب إلى السجن دون ضغط. خاصة في وقت ما ، عندما يحصل المهاجم على ملفات النسخ الاحتياطي الخاصة بك ، قد يكون قادرًا على فرضها بوحشية في المستقبل.
قد تكون هناك مشاكل أمنية أخرى تظهر في المستقبل ، إلخ ...
تحولت المناقشة للتو إلى إثارة خوف لا معنى لها.

sanmai ، لا أحصل على هذا المثال مع

تخيل أنك صحفي استقصائي ... تخيل الآن أنك لم تكن ذكيًا بما يكفي لتمكين الضغط ، والآن سيعرف أي شخص آخر ، ممن لديهم هذه الملفات أيضًا ، بناءً على أحجام الأجزاء المضغوطة ثم المشفرة ، ذلك لديك هذه الملفات شديدة السرية في هذا الأرشيف دون الحاجة إلى معرفة مفتاح التشفير.

ما هو المقصود؟ هل يمكن لأي شخص أن يخمن أن اللقطة المشفرة تحتوي على هذه الملفات بمجرد النظر إلى الحجم؟ يفترض هذا أن الملفات مضغوطة بمفردها أو مع ملفات أخرى معروفة. ولكن بعد ذلك يمكن إجراء نفس التخمين باستخدام صورة غير مشفرة.

في الواقع ، ماذا عن ملفات gzipping قبل النسخ الاحتياطي؟ هل هذا يفتح قابلية التحمل الأمنية أيضًا؟

أعتقد أن هذا المثال مجرد هراء: إذا ادعت أنه يمكنك تحديد ما إذا كانت اللقطة تحتوي على إصدارات مضغوطة من بعض الملفات (العشوائية) المعروفة لك ، فيمكنك أيضًا تحديد ما إذا كانت تحتوي على تلك الملفات غير المضغوطة.

لا أعتقد أن الضغط يمكن أن يجعل التشفير أقل أمانًا بشكل ملحوظ.

تتضمن معظم هجمات الضغط على القناة الجانبية عدة عوامل:
1) يمكن للمهاجم التحكم في المدخلات
2) يمكن للمهاجم مراقبة حجم المخرجات
3) تؤدي التغييرات الصغيرة في بيانات الإدخال إلى تغييرات قابلة للقياس في حجم المخرجات
4) يمكن للمهاجم تغيير الإدخال وإعادة المحاولة مئات الآلاف من المرات

على عكس الأنظمة القائمة على الويب ، نادرًا ما يتم الاحتفاظ بنسخ احتياطية في الغالبية العظمى (1) و (2) في نفس الوقت. علاوة على ذلك ، بالنسبة للضغط المستند إلى الكتلة (3) ليس مضمونًا حقًا ، وبالنسبة لمعظم أنظمة النسخ الاحتياطي (4) فهو بالتأكيد غير صحيح. نظرًا لأن تكرار النسخ الاحتياطي عادةً ما يكون مرة واحدة في اليوم أو نحو ذلك ، فقد يستغرق الأمر آلاف السنين لتكون قادرًا على معالجة البيانات ومراقبة حجم الإخراج المضغوط لملاحظة أي اختلافات كبيرة ، وهذا على افتراض أنه لا توجد بيانات أخرى تتغير ، والتي في معظم الحالات سيكون.

إذا كنت تقوم بعمل نسخ احتياطية حيث كان حجم الإخراج مرئيًا ، فقد ترغب في التفكير في تعطيل الضغط. خلاف ذلك ، لا توجد بالفعل هجمات عملية ضده ولن يجعل تمكينه أقل أمانًا.

يقوم restic بالفعل بإزالة الازدواجية مما يعرضه لنفس الهجمات النظرية مثل القنوات الجانبية للضغط على أي حال ، ولم يشتكي أحد من هذا على حد علمي.

الحقيقة هي أن هناك مئات أو آلاف المستخدمين الذين سيستفيدون من ميزة الضغط مع عدم وجود جوانب سفلية على الإطلاق. هل يمكننا ترك هذه المشكلة البالغة من العمر 5 سنوات للمطورين الذين يعملون عليها من فضلك؟

لأكون صادقًا ... أفضل مفهوم restic ... لكنني أجريت اختبارات في حالة استخدامي (الكثير من ملفات CSV وتفريغ SQL) واضطررت إلى التبديل إلى borg.

لقد اختبرت مع أربعة أجيال من النسخ الاحتياطي التزايدي وحصلت ملفاتي على ضغط بنسبة 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

ما هو المقصود؟ هل يمكن لأي شخص _Gess_ أن اللقطة المشفرة تحتوي على هذه الملفات بمجرد النظر إلى الحجم؟ يفترض هذا أن الملفات مضغوطة بمفردها أو مع ملفات أخرى معروفة. ولكن بعد ذلك يمكن إجراء نفس التخمين باستخدام صورة غير مشفرة.

بالضبط. قم بتقطيع ملف نص عادي إلى أجزاء متساوية ، ثم اضغط ثم قم بتشفيرها. قم بتقطيعها مرة أخرى ، ثم ضغطها وتشفيرها. نظرًا لأن أحجام الملفات المشفرة لا تتغير من حيث AES ، فسترى أنه في كلتا الحالتين لديك نطاق أحجام تتطابق مع بعضها البعض مثل بصمة الإصبع. إنهم (وأعني بهم بشكل أساسي إدارات الأنظمة القمعية مثل إيران أو روسيا) يمكنهم افتراض وجود هذه الملفات هنا ، مما يعطي سببًا ، على سبيل المثال ، لمواصلة تعذيب المشتبه به. لا أفهم لماذا تشعرون جميعًا بالإهانة من هذه الأفكار ، أليس من السهل فهمها؟ هذه ليست جريمة بحد ذاتها ، أليس كذلك؟

ولكن كما لوحظ من قبل من viric ، لا تتأثر Restic تقنيًا بنقاط الضعف هذه نظرًا لأن أحجام القطع لا تُرى بدون مفتاح تشفير. ومع ذلك ، إذا تمت إضافة الضغط في مرحلة ما ، فقد لا يزال Restic غير متأثر الآن ، ولكنه قد يتأثر لاحقًا.

هل تؤدي إضافة الضغط إلى تعريض Restic إلى أي ثغرة أمنية إضافية ، نظرًا لأنه يقوم بالفعل بإلغاء المكررة؟

إذا كان قلقك هو أحد المهاجمين الذين يخمنون أحجام الكتل المضغوطة لاستنتاج الحجم غير المضغوط ، حسنًا ، لكن هل الضغط يزيد الأمر سوءًا؟ ألن يمتلك المهاجم نفس المعلومات الأساسية؟

إذا تمكن المهاجم من رؤية الأحجام غير المضغوطة والمضغوطة لكل ملف ، فقد يصبح تحديد الهوية أكثر واقعية ، لكن هذا لن يكون ممكنًا في حالة عدم الاستقرار.

في نهاية المطاف ، يعرضك إلغاء الازدواجية بالفعل لكل هجوم نظري يمكنني رؤية تأثير الضغط عليه ، بالإضافة إلى أنه يمكن بالطبع تعطيل الضغط للحفاظ على الوضع الحالي إذا كان هذا يناسب وضعك بشكل أفضل.

أنا ببساطة لا أفهم سبب مناقشة مخاوف الأمان الافتراضية حول تخمين وجود ملف من خلال رؤية حجم مقطع مشفر .. ،،

أنتم يا رفاق يستخدمون ZIP أو GZ؟ عندها يجب أن تكون بخير.

هل تعتقد أن السلطات الإيرانية يمكنها تخمين المحتوى الخاص بي بالأحجام؟ ثم فقط لا تستخدم الضغط (!). هذا لا يعني ببساطة أن الضغط لا ينبغي أن يكون متاحًا.

أعتقد أننا غطينا جميع الزوايا ذات الصلة بإضافة الضغط إلى restic ، شكرًا جزيلاً لك على كل مدخلاتك.

أعتقد أنه يجب علينا إضافة الضغط وتمكينه افتراضيًا ، مع السماح للمستخدمين بتعطيل الضغط. يرجى التحلي بالصبر حتى يكون لدي المزيد من الوقت للعمل على ذلك.

أشعر أن هذه المناقشة تخرج عن نطاق السيطرة ، لذلك أقفل هذه المشكلة في الوقت الحالي. إذا كنت ترغب في مواصلة هذه المناقشة ، يرجى التوجه إلى المنتدى . شكرا!