النسخ الاحتياطي ، الجزء 2: نظرة عامة واختبار أدوات النسخ الاحتياطي المستندة إلى rsync


يستمر هذا المقال


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

من بين تلك الأكثر ملاءمة لظروفنا ، سأدرس 3: rdiff-backup ، rsnapshot و burp.

مجموعات اختبار الملف


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

المجموعة الأولى : 10 غيغابايت من ملفات الوسائط ، وحوالي 50 ميغابايت - الكود المصدر للموقع في php ، أحجام الملفات من بضعة كيلوبايت من الكود المصدري ، إلى عشرات الميجابايت من ملفات الوسائط. الهدف هو محاكاة موقع مع احصائيات.

المجموعة الثانية : تم الحصول عليها من الأولى عند إعادة تسمية دليل فرعي بملفات وسائط بسعة 5 جيجابايت. الهدف هو دراسة سلوك نظام النسخ الاحتياطي عند إعادة تسمية الدليل.

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

الحصول على النتائج


يتم إجراء أي نسخ احتياطي على الأقل 3 مرات ويكون مصحوبًا بإعادة تعيين ذاكرة التخزين المؤقت لنظام الملفات باستخدام echo 3 > /proc/sys/vm/drop_caches sync و echo 3 > /proc/sys/vm/drop_caches على كل من خادم الاختبار وخادم تخزين النسخ الاحتياطي.

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

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

أيضا ، تغيرت الخوادم الخاصة بي ، والتي سوف تحقق أنظمة مختلفة للنسخ الاحتياطي.

الآن لديهم الخصائص التالية
معالج

 sysbench --threads=2 --time=30 --cpu-max-prime=20000 cpu run sysbench 1.0.17 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 2 Initializing random number generator from current time Prime numbers limit: 20000 Initializing worker threads... Threads started! CPU speed: events per second: 1081.62 General statistics: total time: 30.0013s total number of events: 32453 Latency (ms): min: 1.48 avg: 1.85 max: 9.84 95th percentile: 2.07 sum: 59973.40 Threads fairness: events (avg/stddev): 16226.5000/57.50 execution time (avg/stddev): 29.9867/0.00 

ذاكرة الوصول العشوائي ، والقراءة ...

 sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=read memory run sysbench 1.0.17 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 4 Initializing random number generator from current time Running memory speed test with the following options: block size: 1KiB total size: 102400MiB operation: read scope: global Initializing worker threads... Threads started! Total operations: 104857600 (5837637.63 per second) 102400.00 MiB transferred (5700.82 MiB/sec) General statistics: total time: 17.9540s total number of events: 104857600 Latency (ms): min: 0.00 avg: 0.00 max: 66.08 95th percentile: 0.00 sum: 18544.64 Threads fairness: events (avg/stddev): 26214400.0000/0.00 execution time (avg/stddev): 4.6362/0.12 

... والتسجيل

 sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=write memory run sysbench 1.0.17 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 4 Initializing random number generator from current time Running memory speed test with the following options: block size: 1KiB total size: 102400MiB operation: write scope: global Initializing worker threads... Threads started! Total operations: 91414596 (3046752.56 per second) 89272.07 MiB transferred (2975.34 MiB/sec) General statistics: total time: 30.0019s total number of events: 91414596 Latency (ms): min: 0.00 avg: 0.00 max: 1022.90 95th percentile: 0.00 sum: 66430.91 Threads fairness: events (avg/stddev): 22853649.0000/945488.53 execution time (avg/stddev): 16.6077/1.76 

القرص على خادم مصدر البيانات

 sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run sysbench 1.0.17 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 4 Initializing random number generator from current time Extra file open flags: (none) 128 files, 8MiB each 1GiB total file size Block size 4KiB Number of IO requests: 0 Read/Write ratio for combined random IO test: 1.50 Periodic FSYNC enabled, calling fsync() each 100 requests. Calling fsync() at the end of test, Enabled. Using synchronous I/O mode Doing random r/w test Initializing worker threads... Threads started! File operations: reads/s: 4587.95 writes/s: 3058.66 fsyncs/s: 9795.73 Throughput: read, MiB/s: 17.92 written, MiB/s: 11.95 General statistics: total time: 60.0241s total number of events: 1046492 Latency (ms): min: 0.00 avg: 0.23 max: 14.45 95th percentile: 0.94 sum: 238629.34 Threads fairness: events (avg/stddev): 261623.0000/1849.14 execution time (avg/stddev): 59.6573/0.00 

القرص على خادم تخزين النسخ الاحتياطي

 sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run sysbench 1.0.17 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 4 Initializing random number generator from current time Extra file open flags: (none) 128 files, 8MiB each 1GiB total file size Block size 4KiB Number of IO requests: 0 Read/Write ratio for combined random IO test: 1.50 Periodic FSYNC enabled, calling fsync() each 100 requests. Calling fsync() at the end of test, Enabled. Using synchronous I/O mode Doing random r/w test Initializing worker threads... Threads started! File operations: reads/s: 11.37 writes/s: 7.58 fsyncs/s: 29.99 Throughput: read, MiB/s: 0.04 written, MiB/s: 0.03 General statistics: total time: 73.8868s total number of events: 3104 Latency (ms): min: 0.00 avg: 78.57 max: 3840.90 95th percentile: 297.92 sum: 243886.02 Threads fairness: events (avg/stddev): 776.0000/133.26 execution time (avg/stddev): 60.9715/1.59 

سرعة الشبكة بين الخوادم

 iperf3 -c backup Connecting to host backup, port 5201 [ 4] local xxxx port 59402 connected to yyyy port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 419 MBytes 3.52 Gbits/sec 810 182 KBytes [ 4] 1.00-2.00 sec 393 MBytes 3.30 Gbits/sec 810 228 KBytes [ 4] 2.00-3.00 sec 378 MBytes 3.17 Gbits/sec 810 197 KBytes [ 4] 3.00-4.00 sec 380 MBytes 3.19 Gbits/sec 855 198 KBytes [ 4] 4.00-5.00 sec 375 MBytes 3.15 Gbits/sec 810 182 KBytes [ 4] 5.00-6.00 sec 379 MBytes 3.17 Gbits/sec 765 228 KBytes [ 4] 6.00-7.00 sec 376 MBytes 3.15 Gbits/sec 810 180 KBytes [ 4] 7.00-8.00 sec 379 MBytes 3.18 Gbits/sec 765 253 KBytes [ 4] 8.00-9.00 sec 380 MBytes 3.19 Gbits/sec 810 239 KBytes [ 4] 9.00-10.00 sec 411 MBytes 3.44 Gbits/sec 855 184 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec 8100 sender [ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec receiver 


منهجية الاختبار


  1. يتم إعداد نظام ملفات به مجموعة الاختبار الأولى على خادم الاختبار ، وتهيئة المستودع على خادم تخزين النسخ الاحتياطي إذا لزم الأمر.
    تبدأ عملية النسخ الاحتياطي ويتم قياس وقتها.
  2. يتم ترحيل الملفات إلى مجموعة الاختبار الثانية على خادم الاختبار. تبدأ عملية النسخ الاحتياطي ويتم قياس وقتها.
  3. ينتقل خادم الاختبار إلى مجموعة الاختبار الثالثة. تبدأ عملية النسخ الاحتياطي ويتم قياس وقتها.
  4. يتم قبول مجموعة الاختبار الثالثة الناتجة بواسطة الجديد الأول ؛ تتكرر النقاط 1-3 2 مرات.
  5. يتم إدخال البيانات في الجدول المحوري ، يتم إضافة الرسوم البيانية مع netdata.
  6. يتم إعداد تقرير باستخدام طريقة احتياطية منفصلة.

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


نظرًا لأن جميع المرشحين الثلاثة يعتمدون على نفس التكنولوجيا (rsync) ، فمن المتوقع أن تكون النتائج قريبة من rsync المعتاد ، بما في ذلك جميع مزاياها ، وهي:

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

سيتم استخدام التشغيل التجريبي لـ rsync العادي كمرجع ، ونتائجه

هذه هي


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

تم نسخ البيانات في 4 دقائق و 15 ثانية.


اختبار rdiff النسخ الاحتياطي


المرشح الأول هو rdiff-backup ، وهو سيناريو بيثون يقوم بعمل نسخة احتياطية من دليل لآخر. في الوقت نفسه ، يتم تخزين النسخة الاحتياطية الحالية "كما هي" ، ويتم تخزين النسخ الاحتياطية التي تم إنشاؤها سابقًا في دليل فرعي خاص بشكل تدريجي ، وبالتالي يتم حفظ المساحة.

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

لنرى
ما هو قادر في ظروفنا
.



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

الإطلاق الأولالاطلاق الثانيالاطلاق الثالث
المجموعة الأولى16m32s16m26s16m19s
المجموعة الثانية2h5m2h10m2h8m
المجموعة الثالثة2h9m2h10m2h10m


يتفاعل Rdiff-backup بشكل مؤلم مع أي تغيير كبير في البيانات ، كما أنه لا يستخدم الشبكة بالكامل.

اختبار rsnapshot


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

يتم عكس منطق عملية النسخ الاحتياطي أيضًا: يقوم الخادم "بالمشي" بنشاط على عملائه نفسه ويأخذ البيانات.

نتائج الاختبار

ما يلي


الإطلاق الأولالاطلاق الثانيالاطلاق الثالث
المجموعة الأولى4m22s4m19s4m16s
المجموعة الثانية2m6s2m10s2m6s
المجموعة الثالثة1m18s1m10s1m10s

كانت تعمل بسرعة كبيرة جدًا وأسرع بكثير من النسخ الاحتياطي لـ rdiff وقريبة جدًا من rsync النقي.

اختبار تجشؤ


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

دعنا ننظر في
إنتاجية
.



الإطلاق الأولالاطلاق الثانيالاطلاق الثالث
المجموعة الأولى11m21s11m10s10m56s
المجموعة الثانية5m37s5m40s5m35s
المجموعة الثالثة3m33s3m24s3m40s

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

النتائج


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

النتائج


كلما زاد تعقيد نظام النسخ الاحتياطي والمزيد من الميزات المختلفة ، كلما كان العمل أبطأ ، ولكن بالنسبة للمشاريع التي لا تتطلب الكثير من المتطلبات ، فإن أيًا منها لن يعمل ، باستثناء ، ربما ، rdiff-backup.

إعلان


تستمر هذه الملاحظة دورة النسخ الاحتياطي.

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

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

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


All Articles