پشتیبان گیری قسمت 3: بررسی و تست duplicity، duplicati

این یادداشت درباره ابزارهای پشتیبان‌گیری بحث می‌کند که با ایجاد آرشیو روی سرور پشتیبان، پشتیبان‌گیری را انجام می‌دهند.

از جمله مواردی که الزامات را برآورده می کنند، duplicity (که رابط کاربری خوبی به شکل deja dup دارد) و duplicati هستند.

یکی دیگر از ابزارهای پشتیبان گیری بسیار قابل توجه، dar است، اما از آنجایی که فهرست بسیار گسترده ای از گزینه ها دارد - روش تست به سختی 10٪ از آنچه را که می تواند پوشش می دهد - ما آن را به عنوان بخشی از چرخه فعلی آزمایش نمی کنیم.

نتایج مورد انتظار

از آنجایی که هر دو نامزد به یک روش آرشیو ایجاد می کنند، تار معمولی می تواند به عنوان راهنما استفاده شود.

علاوه بر این، با ایجاد نسخه‌های پشتیبان که فقط تفاوت بین یک کپی کامل و وضعیت فعلی فایل‌ها، یا بین آرشیو قبلی و فعلی (افزاینده، کاهشی و غیره) را در بر می‌گیرد، میزان بهینه‌سازی ذخیره‌سازی داده در سرور ذخیره‌سازی را ارزیابی خواهیم کرد. .

رفتار هنگام ایجاد پشتیبان:

1. تعداد نسبتا کمی فایل در سرور ذخیره سازی پشتیبان (قابل مقایسه با تعداد نسخه های پشتیبان یا حجم داده ها در گیگابایت)، اما اندازه آنها بسیار بزرگ است (ده ها تا صدها مگابایت).
2. اندازه مخزن فقط شامل تغییرات می شود - هیچ مورد تکراری ذخیره نمی شود، بنابراین اندازه مخزن کوچکتر از نرم افزار مبتنی بر rsync خواهد بود.
3. هنگام استفاده از فشرده‌سازی و/یا رمزگذاری، انتظار بار سنگین CPU را داشته باشید، و اگر فرآیند بایگانی و/یا رمزگذاری روی سرور ذخیره‌سازی پشتیبان اجرا می‌شود، احتمالاً بار شبکه و دیسک بسیار زیاد است.

بیایید دستور زیر را به عنوان یک مقدار مرجع اجرا کنیم:

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 ثانیه بود، زیرا 2 فرآیند در سمت دریافت کننده در حال اجرا بودند - گلوگاه دوباره یک کمپرسور تک رشته ای است، به علاوه سربار رمزگذاری کوچک.

UPD: به درخواست bliznezz تست هایی با pigz اضافه می کنم. اگر فقط از کمپرسور استفاده کنید، 6 متر 30 ثانیه طول می کشد، اگر رمزگذاری نیز اضافه کنید، حدود 7 متر خواهد بود. شیب در نمودار پایین یک حافظه پنهان دیسک تمیز نشده است:

تست تکراری

Duplicity یک نرم افزار پایتون برای پشتیبان گیری با ایجاد آرشیوهای رمزگذاری شده با فرمت tar است.

برای بایگانی های افزایشی، از librsync استفاده می شود، بنابراین می توانید رفتاری را که در آن توضیح داده شده است، انتظار داشته باشید پست قبلی سریال.

پشتیبان‌گیری‌ها را می‌توان با استفاده از gnupg رمزگذاری و امضا کرد، که هنگام استفاده از ارائه‌دهنده‌های مختلف برای ذخیره‌سازی نسخه‌های پشتیبان (s3، backblaze، gdrive و غیره) مهم است.

بیایید ببینیم نتایج چیست:

اینها نتایجی است که هنگام اجرای بدون رمزگذاری به دست آوردیم

خراب کننده

زمان اجرای هر آزمایش:

راه اندازی 1
راه اندازی 2
راه اندازی 3

16 متر 33 ثانیه
17 متر 20 ثانیه
16 متر 30 ثانیه

8 متر 29 ثانیه
9 متر 3 ثانیه
8 متر 45 ثانیه

5 متر 21 ثانیه
6 متر 04 ثانیه
5 متر 53 ثانیه

و در اینجا نتایج زمانی که رمزگذاری gnupg فعال است، با اندازه کلید 2048 بیت است:

زمان کار بر روی همان داده ها، با رمزگذاری:

راه اندازی 1
راه اندازی 2
راه اندازی 3

17 متر 22 ثانیه
17 متر 32 ثانیه
17 متر 28 ثانیه

8 متر 52 ثانیه
9 متر 13 ثانیه
9 متر 3 ثانیه

5 متر 48 ثانیه
5 متر 40 ثانیه
5 متر 30 ثانیه

اندازه بلوک نشان داده شد - 512 مگابایت، که به وضوح در نمودارها قابل مشاهده است. بار پردازنده در واقع 50٪ باقی مانده است، به این معنی که برنامه از بیش از یک هسته پردازنده استفاده نمی کند.

اصل عملکرد برنامه نیز کاملاً به وضوح قابل مشاهده است: آنها یک قطعه داده را گرفتند، آن را فشرده کردند و به یک سرور ذخیره سازی پشتیبان فرستادند که می تواند بسیار کند باشد.
ویژگی دیگر زمان اجرای قابل پیش بینی برنامه است که فقط به اندازه داده های تغییر یافته بستگی دارد.

فعال کردن رمزگذاری زمان اجرای برنامه را به میزان قابل توجهی افزایش نداد، اما بار پردازنده را تا حدود 10 درصد افزایش داد که می تواند امتیاز خوبی باشد.

متأسفانه، این برنامه نتوانست وضعیت تغییر نام دایرکتوری را به درستی تشخیص دهد و اندازه مخزن حاصل برابر با اندازه تغییرات (یعنی همه 18 گیگابایت) است، اما توانایی استفاده از یک سرور نامعتبر برای پشتیبان‌گیری به وضوح وجود دارد. این رفتار را پوشش می دهد.

تست تکراری

این نرم افزار به زبان سی شارپ نوشته شده و با استفاده از مجموعه ای از کتابخانه های Mono اجرا می شود. یک GUI و همچنین یک نسخه CLI وجود دارد.

فهرست تقریبی ویژگی‌های اصلی مشابه دوگانگی است، از جمله ارائه‌دهندگان مختلف ذخیره‌سازی پشتیبان، با این حال، برخلاف duplicity، بیشتر ویژگی‌ها بدون ابزار شخص ثالث در دسترس هستند. مثبت یا منفی بودن این موضوع بستگی به مورد خاص دارد، اما برای مبتدیان، به احتمال زیاد آسان‌تر است که فهرستی از همه ویژگی‌ها را در یک زمان در مقابل خود داشته باشند، به جای نصب بسته‌های اضافی برای پایتون. مورد با دوگانگی

نکته کوچک دیگر - این برنامه به طور فعال یک پایگاه داده محلی sqlite را از طرف کاربری که پشتیبان گیری را شروع می کند می نویسد، بنابراین باید اطمینان حاصل کنید که هر بار که فرآیند با استفاده از cli شروع می شود، پایگاه داده مورد نیاز به درستی مشخص شده است. هنگام کار از طریق GUI یا WEBGUI، جزئیات از کاربر پنهان می شود.

بیایید ببینیم این راه حل چه شاخص هایی می تواند ایجاد کند:

اگر رمزگذاری را خاموش کنید (و WEBGUI انجام این کار را توصیه نمی کند)، نتایج به شرح زیر است:

ساعت:

راه اندازی 1
راه اندازی 2
راه اندازی 3

20 متر 43 ثانیه
20 متر 13 ثانیه
20 متر 28 ثانیه

5 متر 21 ثانیه
5 متر 40 ثانیه
5 متر 35 ثانیه

7 متر 36 ثانیه
7 متر 54 ثانیه
7 متر 49 ثانیه

با فعال بودن رمزگذاری، با استفاده از aes، به نظر می رسد:

ساعت:

راه اندازی 1
راه اندازی 2
راه اندازی 3

29 متر 9 ثانیه
30 متر 1 ثانیه
29 متر 54 ثانیه

5 متر 29 ثانیه
6 متر 2 ثانیه
5 متر 54 ثانیه

8 متر 44 ثانیه
9 متر 12 ثانیه
9 متر 1 ثانیه

و اگر از برنامه خارجی gnupg استفاده کنید، نتایج زیر به دست می آید:

راه اندازی 1
راه اندازی 2
راه اندازی 3

26 متر 6 ثانیه
26 متر 35 ثانیه
26 متر 17 ثانیه

5 متر 20 ثانیه
5 متر 48 ثانیه
5 متر 40 ثانیه

8 متر 12 ثانیه
8 متر 42 ثانیه
8 متر 15 ثانیه

همانطور که می بینید، این برنامه می تواند در چندین رشته کار کند، اما این باعث نمی شود که راه حل موثرتری باشد، و اگر کار رمزگذاری را مقایسه کنید، یک برنامه خارجی راه اندازی می کند.
معلوم شد که سریعتر از استفاده از کتابخانه از مجموعه مونو است. این ممکن است به این دلیل باشد که برنامه خارجی بهینه تر است.

چیز خوب دیگر این واقعیت بود که اندازه مخزن دقیقاً به اندازه داده های واقعی تغییر یافته است. duplicati یک تغییر نام دایرکتوری را شناسایی کرد و این وضعیت را به درستی مدیریت کرد. این را می توان هنگام اجرای تست دوم مشاهده کرد.

به طور کلی، برداشت های نسبتاً مثبتی از برنامه، از جمله رفتار نسبتاً دوستانه با تازه کارها.

یافته ها

هر دو نامزد نسبتاً کند کار کردند، اما به طور کلی، در مقایسه با تار معمولی، حداقل در مورد تکراری پیشرفت وجود دارد. قیمت چنین پیشرفتی نیز روشن است - بار قابل توجهی
پردازنده به طور کلی، انحراف خاصی در پیش بینی نتایج وجود ندارد.

یافته ها

اگر نیازی به عجله به جایی ندارید و همچنین یک پردازنده یدکی دارید، هر یک از راه حل های در نظر گرفته شده انجام می شود، در هر صورت، کارهای بسیار زیادی انجام شده است که نباید با نوشتن اسکریپت های لفاف بر روی تار تکرار شوند. . وجود رمزگذاری یک ویژگی بسیار ضروری است اگر سرور برای ذخیره نسخه های پشتیبان قابل اعتماد نباشد.

در مقایسه با راه حل های مبتنی بر rsync - عملکرد می تواند چندین برابر بدتر باشد، علیرغم این واقعیت که تار در شکل خالص آن 20-30٪ سریعتر از rsync کار می کند.
صرفه جویی در اندازه مخزن وجود دارد، اما فقط با تکراری.

اطلاعیه

پشتیبان گیری، قسمت 1: چرا پشتیبان گیری مورد نیاز است، مروری بر روش ها، فناوری ها
پشتیبان گیری، قسمت 2: بررسی و آزمایش ابزارهای پشتیبان گیری مبتنی بر rsync
پشتیبان گیری قسمت 3: بررسی و آزمایش duplicity، duplicati، deja dup
پشتیبان گیری قسمت 4: بررسی و آزمایش zbackup، restic، borgbackup
پشتیبان گیری، قسمت 5: تست بکاپ باکولا و veeam برای لینوکس
پشتیبان گیری قسمت 6: مقایسه ابزارهای پشتیبان گیری
پشتیبان گیری قسمت 7: نتیجه گیری

ارسال شده توسط: پاول دمکوویچ

منبع: www.habr.com