جزء النسخ الاحتياطي 3: مراجعة واختبار الازدواجية والنسخ

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

من بين تلك التي تستوفي المتطلبات هي الازدواجية (التي لها واجهة جميلة على شكل deja dup) والتكرارات.

أداة أخرى رائعة جدًا للنسخ الاحتياطي هي dar، ولكن بما أنها تحتوي على قائمة واسعة جدًا من الخيارات - لا تغطي منهجية الاختبار سوى 10% مما هي قادرة عليه - فنحن لا نختبرها كجزء من الدورة الحالية.

نتائج متوقعة

نظرًا لأن كلا المرشحين يقومان بإنشاء أرشيفات بطريقة أو بأخرى، فيمكن استخدام القطران العادي كدليل.

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

السلوك عند إنشاء نسخ احتياطية:

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

لنقم بتشغيل الأمر التالي كقيمة مرجعية:

cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"

وكانت نتائج التنفيذ على النحو التالي:

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

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

cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"

النتائج هي:

وقت التنفيذ 10 د 11 ث. على الأرجح أن عنق الزجاجة هو الضاغط أحادي التدفق الموجود على الطرف المتلقي.

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

cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"

اتضح مثل هذا:

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

لتقييم التشفير، يمكنك استخدام opensl أو gpg عن طريق توصيل أمر إضافي openssl أو gpg في الأنابيب. كمرجع سيكون هناك أمر مثل هذا:

cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"

وخرجت النتائج كالآتي:

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

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

اختبار مكرر

Duplicity هو برنامج python للنسخ الاحتياطي عن طريق إنشاء أرشيفات مشفرة بتنسيق tar.

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

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

دعونا نرى ما ستكون النتائج:

هذه هي النتائج التي حصلنا عليها عند التشغيل بدون تشفير

المفسد

وقت تشغيل كل تشغيل اختباري:

تشغيل 1
تشغيل 2
تشغيل 3

16m33s
17m20s
16m30s

8m29s
9m3s
8m45s

5m21s
6m04s
5m53s

وإليك النتائج عند تمكين تشفير gnupg، بحجم مفتاح 2048 بت:

وقت التشغيل على نفس البيانات مع التشفير:

تشغيل 1
تشغيل 2
تشغيل 3

17m22s
17m32s
17m28s

8m52s
9m13s
9m3s

5m48s
5m40s
5m30s

تمت الإشارة إلى حجم الكتلة - 512 ميغابايت، وهو ما يظهر بوضوح في الرسوم البيانية؛ وبقي حمل المعالج فعليًا عند 50%، مما يعني أن البرنامج لا يستخدم أكثر من نواة معالج واحدة.

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

لم يؤدي تمكين التشفير إلى زيادة وقت تشغيل البرنامج بشكل كبير، ولكنه زاد من حمل المعالج بحوالي 10%، وهو ما يمكن أن يكون بمثابة مكافأة رائعة.

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

اختبار مكرر

هذا البرنامج مكتوب بلغة C# ويتم تشغيله باستخدام مجموعة من المكتبات من Mono. هناك واجهة المستخدم الرسومية بالإضافة إلى إصدار CLI.

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

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

دعونا نرى المؤشرات التي يمكن أن ينتجها هذا الحل:

إذا قمت بإيقاف تشغيل التشفير (ولا ينصح WEBGUI بالقيام بذلك)، فستكون النتائج كما يلي:

ساعات العمل:

تشغيل 1
تشغيل 2
تشغيل 3

20m43s
20m13s
20m28s

5m21s
5m40s
5m35s

7m36s
7m54s
7m49s

مع تمكين التشفير، باستخدام AES، يبدو الأمر كما يلي:

ساعات العمل:

تشغيل 1
تشغيل 2
تشغيل 3

29m9s
30m1s
29m54s

5m29s
6m2s
5m54s

8m44s
9m12s
9m1s

وفي حالة استخدام البرنامج الخارجي gnupg تظهر النتائج التالية:

تشغيل 1
تشغيل 2
تشغيل 3

26m6s
26m35s
26m17s

5m20s
5m48s
5m40s

8m12s
8m42s
8m15s

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

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

بشكل عام، انطباعات إيجابية إلى حد ما عن البرنامج، بما في ذلك كونه ودودًا إلى حد ما مع المبتدئين.

النتائج

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

النتائج

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

بالمقارنة مع الحلول القائمة رسينك - يمكن أن يكون الأداء أسوأ عدة مرات، على الرغم من حقيقة أن القطران في شكله النقي يعمل بنسبة 20-30٪ أسرع من rsync.
هناك وفورات في حجم المستودع، ولكن فقط مع النسخ المكررة.

إعلان

النسخ الاحتياطي ، الجزء 1: سبب الحاجة إلى النسخ الاحتياطي ، نظرة عامة على الأساليب والتقنيات
الجزء الثاني من النسخ الاحتياطي: مراجعة واختبار أدوات النسخ الاحتياطي المستندة إلى rsync
الجزء الاحتياطي 3: مراجعة واختبار الازدواجية والنسخ المكررة
النسخ الاحتياطي الجزء 4: مراجعة واختبار zbackup ، restic ، borgbackup
الجزء الخامس من النسخ الاحتياطي: اختبار باكولا وفايم النسخ الاحتياطي لنظام لينكس
جزء النسخ الاحتياطي 6: مقارنة أدوات النسخ الاحتياطي
جزء النسخ الاحتياطي 7: الاستنتاجات

كاتب المشاركة: بافل ديمكوفيتش

المصدر: www.habr.com