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


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


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


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


النتائج المتوقعة


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


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


سلوك النسخ الاحتياطي:


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

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


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

كانت نتائج الإعدام كما يلي:



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


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


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

النتائج هي كما يلي:



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


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


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

اتضح مثل هذا:



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


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


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



اختبار الازدواجية


Duplicity هو برنامج نسخ احتياطي بيثون من خلال إنشاء محفوظات القطران المشفرة.


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


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


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


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

المفسد



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


إطلاق 1إطلاق 2إطلاق 3
16m33s17m20s16m30s
8m29s9m3s8m45s
5m21s6m04s5m53s

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



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


إطلاق 1إطلاق 2إطلاق 3
17m22s17m32s17m28s
8m52s9m13s9m3s
5m48s5m40s5m30s

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


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


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


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


اختبار مكررة


هو مكتوب هذا البرنامج في C # ، يتم إطلاقها باستخدام مجموعة من المكتبات من مونو. هناك واجهة المستخدم الرسومية وكذلك إصدار المبادرة القطرية.


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


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


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

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



وقت العمل:


إطلاق 1إطلاق 2إطلاق 3
20m43s20m13s20m28s
5m21s5m40s5m35s
7m36s7m54s7m49s

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



وقت العمل:


إطلاق 1إطلاق 2إطلاق 3
29m9s30m1s29m54s
5m29s6m2s5m54s
8m44s9m12s9m1s

وإذا كنت تستخدم برنامج gnupg الخارجي ، فستحصل على النتائج التالية:



إطلاق 1إطلاق 2إطلاق 3
26m6s26m35s26m17s
5m20s5m48s5m40s
8m12s8m42s8m15s

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


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


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


النتائج


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


النتائج


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


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


إعلان


النسخ الاحتياطي ، الجزء 1: لماذا تحتاج إلى نسخة احتياطية ، لمحة عامة عن الأساليب والتقنيات
النسخ الاحتياطي ، الجزء 2: نظرة عامة واختبار أدوات النسخ الاحتياطي المستندة إلى rsync
النسخ الاحتياطي ، الجزء 3: نظرة عامة واختبار التكرار ، duplicati ، deja dup
النسخ الاحتياطي ، الجزء 4: نظرة عامة واختبار zbackup ، restic ، borgbackup
النسخ الاحتياطي ، الجزء 5: اختبار Bacula و Veeam Backup لنظام التشغيل Linux
النسخ الاحتياطي: الجزء المطلوب من القراء: مراجعة أماندا ، UrBackup ، BackupPC
النسخ الاحتياطي ، الجزء 6: مقارنة أدوات النسخ الاحتياطي
النسخ الاحتياطي الجزء 7: الاستنتاجات


أرسلت بواسطة فينيكس

Source: https://habr.com/ru/post/ar454420/


All Articles