این مقاله نرم‌افزار پشتیبان‌گیری را بررسی می‌کند که با شکستن جریان داده به اجزای جداگانه (تکه‌ها)، یک مخزن را تشکیل می‌دهد.
اجزای مخزن را می توان بیشتر فشرده و رمزگذاری کرد و مهمتر از همه - در طی فرآیندهای پشتیبان گیری مکرر - دوباره استفاده کرد.
یک نسخه پشتیبان در چنین مخزنی زنجیره ای نامگذاری شده از اجزای متصل به یکدیگر است، به عنوان مثال، بر اساس توابع هش مختلف.
چندین راه حل مشابه وجود دارد، من روی 3 تمرکز می کنم: zbackup، borgbackup و restic.
نتایج مورد انتظار
از آنجایی که همه متقاضیان به هر طریقی نیاز به ایجاد یک مخزن دارند، یکی از مهم ترین عوامل تخمین اندازه مخزن خواهد بود. در حالت ایده آل، اندازه آن طبق روش پذیرفته شده نباید بیش از 13 گیگابایت یا حتی کمتر باشد - مشروط به بهینه سازی خوب.
همچنین بسیار مطلوب است که بتوانید نسخه‌های پشتیبان از فایل‌ها را مستقیماً، بدون استفاده از بایگانی‌هایی مانند tar، و همچنین کار با ssh/sftp بدون ابزارهای اضافی مانند rsync و sshfs ایجاد کنید.
رفتار هنگام ایجاد پشتیبان:
- اندازه مخزن برابر با اندازه تغییرات یا کمتر خواهد بود.
- هنگام استفاده از فشرده‌سازی و/یا رمزگذاری، بار سنگین CPU پیش‌بینی می‌شود، و اگر فرآیند بایگانی و/یا رمزگذاری روی یک سرور ذخیره‌سازی پشتیبان اجرا شود، بار شبکه و دیسک بسیار زیاد است.
- اگر مخزن آسیب دیده باشد، خطای تاخیری هم هنگام ایجاد پشتیبان‌گیری جدید و هم هنگام تلاش برای بازیابی احتمال دارد. لازم است اقدامات اضافی برای اطمینان از یکپارچگی مخزن برنامه ریزی شود یا از ابزارهای داخلی برای بررسی یکپارچگی آن استفاده شود.
همانطور که در یکی از مقالات قبلی نشان داده شد، کار با تار به عنوان یک مقدار مرجع در نظر گرفته می شود.
تست zbackup
مکانیسم کلی zbackup به این صورت است که برنامه در جریان داده های ورودی نواحی حاوی همان داده ها را پیدا می کند، سپس به صورت اختیاری آنها را فشرده و رمزگذاری می کند و هر ناحیه را فقط یک بار ذخیره می کند.
Deduplication از یک تابع هش حلقه 64 بیتی با یک پنجره کشویی برای بررسی مطابقت بایت به بایت با بلوک های داده موجود استفاده می کند (شبیه به نحوه پیاده سازی rsync).
lzma و lzo چند رشته ای برای فشرده سازی و aes برای رمزگذاری استفاده می شود. آخرین نسخه ها این قابلیت را دارند که در آینده اطلاعات قدیمی را از مخزن حذف کنند.
این برنامه به زبان C++ با حداقل وابستگی نوشته شده است. ظاهراً نویسنده از unix-way الهام گرفته است، بنابراین برنامه هنگام ایجاد پشتیبان، داده‌های stdin را می‌پذیرد و هنگام بازیابی، جریان داده مشابهی را در stdout تولید می‌کند. بنابراین، zbackup می تواند به عنوان یک "بلوک سازنده" بسیار خوب هنگام نوشتن راه حل های پشتیبان خود استفاده شود. به عنوان مثال، نویسنده مقاله تقریباً از سال 2014 از این برنامه به عنوان ابزار اصلی پشتیبان گیری برای ماشین های خانگی استفاده کرده است.
جریان داده یک تار معمولی خواهد بود مگر اینکه خلاف آن ذکر شده باشد.
بیایید ببینیم نتایج چیست:
کار در 2 گزینه بررسی شد:
- یک مخزن ایجاد می شود و zbackup با داده های منبع روی سرور راه اندازی می شود، سپس محتویات مخزن به سرور ذخیره سازی پشتیبان منتقل می شود.
- یک مخزن در سرور ذخیره سازی پشتیبان ایجاد می شود، zbackup از طریق ssh در سرور ذخیره سازی پشتیبان راه اندازی می شود و داده ها از طریق لوله به آن ارسال می شود.
نتایج اولین گزینه به شرح زیر بود: 43m11s - هنگام استفاده از یک مخزن رمزگذاری نشده و کمپرسور lzma، 19m13s - هنگام جایگزینی کمپرسور با lzo.
بارگذاری روی سرور با داده های اصلی به شرح زیر بود (نمونه ای با lzma نشان داده شده است؛ با lzo تقریباً همان تصویر وجود داشت، اما سهم rsync تقریباً یک چهارم موارد بود):
واضح است که چنین فرآیند پشتیبان گیری فقط برای تغییرات نسبتا نادر و کوچک مناسب است. همچنین توصیه می شود zbackup را به 1 رشته محدود کنید، در غیر این صورت بار CPU بسیار بالا خواهد بود، زیرا این برنامه در کار در چندین رشته بسیار خوب است. بار روی دیسک کم بود، که به طور کلی با یک زیرسیستم دیسک مبتنی بر ssd مدرن قابل توجه نیست. همچنین می توانید به وضوح شروع فرآیند همگام سازی داده های مخزن را با یک سرور راه دور مشاهده کنید؛ سرعت عملکرد قابل مقایسه با rsync معمولی است و به عملکرد زیرسیستم دیسک سرور ذخیره سازی پشتیبان بستگی دارد. نقطه ضعف این روش ذخیره سازی یک مخزن محلی و در نتیجه تکراری شدن داده ها است.
جالب تر و قابل اجراتر در عمل گزینه دوم است، اجرای zbackup به طور مستقیم بر روی سرور ذخیره سازی پشتیبان.
ابتدا عملیات را بدون استفاده از رمزگذاری با کمپرسور lzma آزمایش می کنیم:
زمان اجرای هر آزمایش:
راه اندازی 1
راه اندازی 2
راه اندازی 3
39 متر 45 ثانیه
40 متر 20 ثانیه
40 متر 3 ثانیه
7 متر 36 ثانیه
8 متر 3 ثانیه
7 متر 48 ثانیه
15 متر 35 ثانیه
15 متر 48 ثانیه
15 متر 38 ثانیه
اگر رمزگذاری را با استفاده از aes فعال کنید، نتایج کاملاً نزدیک هستند:
زمان کار بر روی همان داده ها، با رمزگذاری:
راه اندازی 1
راه اندازی 2
راه اندازی 3
43 متر 40 ثانیه
44 متر 12 ثانیه
44 متر 3 ثانیه
8 متر 3 ثانیه
8 متر 15 ثانیه
8 متر 12 ثانیه
15 متر 0 ثانیه
15 متر 40 ثانیه
15 متر 25 ثانیه
اگر رمزگذاری با فشرده سازی با استفاده از lzo ترکیب شود، به نظر می رسد:
ساعت:
راه اندازی 1
راه اندازی 2
راه اندازی 3
18 متر 2 ثانیه
18 متر 15 ثانیه
18 متر 12 ثانیه
5 متر 13 ثانیه
5 متر 24 ثانیه
5 متر 20 ثانیه
8 متر 48 ثانیه
9 متر 3 ثانیه
8 متر 51 ثانیه
اندازه مخزن به دست آمده نسبتاً یکسان بود و 13 گیگابایت بود. این بدان معنی است که deduplication به درستی کار می کند. همچنین، در داده‌هایی که قبلاً فشرده شده‌اند، استفاده از lzo تأثیر قابل‌توجهی می‌دهد؛ از نظر کل زمان عملیاتی، zbackup نزدیک به duplicity/dulicati است، اما 2-5 برابر از داده‌های مبتنی بر librsync عقب‌تر است.
مزایا واضح است - صرفه جویی در فضای دیسک در سرور ذخیره سازی پشتیبان. در مورد ابزارهای بررسی مخزن، نویسنده zbackup آنها را ارائه نمی دهد؛ توصیه می شود از یک آرایه دیسک تحمل پذیر یا ارائه دهنده ابر استفاده کنید.
به طور کلی، با وجود این واقعیت که پروژه حدود 3 سال است که ثابت مانده است، برداشت بسیار خوبی است (آخرین درخواست ویژگی حدود یک سال پیش بود، اما بدون پاسخ).
تست borgbackup
Borgbackup یک فورک از اتاق زیر شیروانی است، سیستم دیگری شبیه به zbackup. نوشته شده در پایتون، فهرستی از قابلیت‌های مشابه zbackup دارد، اما علاوه بر این می‌تواند:
- پشتیبان گیری را از طریق فیوز نصب کنید
- محتویات مخزن را بررسی کنید
- در حالت مشتری-سرور کار کنید
- از کمپرسورهای مختلف برای داده ها و همچنین تعیین اکتشافی نوع فایل هنگام فشرده سازی آن استفاده کنید.
- 2 گزینه رمزگذاری، aes و blake
- ابزار داخلی برای
بررسی های عملکرد
بنچمارک borgbackup crud ssh://backup_server/repo/path local_dir
نتایج به شرح زیر بود:
C-Z-BIG 96.51 مگابایت بر ثانیه (10 100.00 مگابایت فایل تمام صفر: 10.36 ثانیه)
R-Z-BIG 57.22 مگابایت بر ثانیه (10 100.00 مگابایت فایل تمام صفر: 17.48 ثانیه)
U-Z-BIG 253.63 مگابایت بر ثانیه (10 100.00 مگابایت فایل تمام صفر: 3.94 ثانیه)
D-Z-BIG 351.06 مگابایت بر ثانیه (10 100.00 مگابایت فایل تمام صفر: 2.85 ثانیه)
C-R-BIG 34.30 مگابایت بر ثانیه (10 100.00 مگابایت فایل های تصادفی: 29.15 ثانیه)
R-R-BIG 60.69 مگابایت بر ثانیه (10 100.00 مگابایت فایل های تصادفی: 16.48 ثانیه)
U-R-BIG 311.06 مگابایت بر ثانیه (10 100.00 مگابایت فایل های تصادفی: 3.21 ثانیه)
D-R-BIG 72.63 مگابایت بر ثانیه (10 100.00 مگابایت فایل های تصادفی: 13.77 ثانیه)
C-Z-MEDIUM 108.59 مگابایت بر ثانیه (1000 1.00 مگابایت فایل تمام صفر: 9.21 ثانیه)
R-Z-MEDIUM 76.16 مگابایت بر ثانیه (1000 1.00 مگابایت فایل تمام صفر: 13.13 ثانیه)
U-Z-MEDIUM 331.27 مگابایت بر ثانیه (1000 1.00 مگابایت فایل تمام صفر: 3.02 ثانیه)
D-Z-MEDIUM 387.36 مگابایت بر ثانیه (1000 1.00 مگابایت فایل تمام صفر: 2.58 ثانیه)
C-R-MEDIUM 37.80 مگابایت بر ثانیه (1000 1.00 مگابایت فایل های تصادفی: 26.45 ثانیه)
R-R-MEDIUM 68.90 مگابایت بر ثانیه (1000 1.00 مگابایت فایل های تصادفی: 14.51 ثانیه)
U-R-MEDIUM 347.24 مگابایت بر ثانیه (1000 1.00 مگابایت فایل های تصادفی: 2.88 ثانیه)
D-R-MEDIUM 48.80 مگابایت بر ثانیه (1000 1.00 مگابایت فایل های تصادفی: 20.49 ثانیه)
C-Z-SMALL 11.72 مگابایت بر ثانیه (10000 فایل های 10.00 کیلوبایتی تمام صفر: 8.53 ثانیه)
R-Z-SMALL 32.57 مگابایت بر ثانیه (10000 فایل های 10.00 کیلوبایتی تمام صفر: 3.07 ثانیه)
U-Z-SMALL 19.37 مگابایت بر ثانیه (10000 فایل های 10.00 کیلوبایتی تمام صفر: 5.16 ثانیه)
D-Z-SMALL 33.71 مگابایت بر ثانیه (10000 فایل های 10.00 کیلوبایتی تمام صفر: 2.97 ثانیه)
C-R-SMALL 6.85 مگابایت بر ثانیه (10000 فایل های تصادفی 10.00 کیلوبایت: 14.60 ثانیه)
R-R-SMALL 31.27 مگابایت بر ثانیه (10000 فایل های تصادفی 10.00 کیلوبایت: 3.20 ثانیه)
U-R-SMALL 12.28 مگابایت بر ثانیه (10000 فایل های تصادفی 10.00 کیلوبایت: 8.14 ثانیه)
D-R-SMALL 18.78 مگابایت بر ثانیه (10000 فایل های تصادفی 10.00 کیلوبایت: 5.32 ثانیه)
هنگام تست، اکتشافی فشرده سازی برای تعیین نوع فایل (فشرده سازی خودکار) استفاده می شود و نتایج به شرح زیر خواهد بود:
ابتدا، بیایید بررسی کنیم که چگونه بدون رمزگذاری کار می کند:
ساعت:
راه اندازی 1
راه اندازی 2
راه اندازی 3
4 متر 6 ثانیه
4 متر 10 ثانیه
4 متر 5 ثانیه
56s
58s
54s
1 متر 26 ثانیه
1 متر 34 ثانیه
1 متر 30 ثانیه
اگر مجوز مخزن (حالت احراز هویت) را فعال کنید، نتایج نزدیک خواهند بود:
ساعت:
راه اندازی 1
راه اندازی 2
راه اندازی 3
4 متر 11 ثانیه
4 متر 20 ثانیه
4 متر 12 ثانیه
1 متر 0 ثانیه
1 متر 3 ثانیه
1 متر 2 ثانیه
1 متر 30 ثانیه
1 متر 34 ثانیه
1 متر 31 ثانیه
وقتی رمزگذاری aes فعال شد، نتایج چندان بدتر نشد:
راه اندازی 1
راه اندازی 2
راه اندازی 3
4 متر 55 ثانیه
5 متر 2 ثانیه
4 متر 58 ثانیه
1 متر 0 ثانیه
1 متر 2 ثانیه
1 متر 0 ثانیه
1 متر 49 ثانیه
1 متر 50 ثانیه
1 متر 50 ثانیه
و اگر aes را به blake تغییر دهید، وضعیت به طور کامل بهبود می یابد:
ساعت:
راه اندازی 1
راه اندازی 2
راه اندازی 3
4 متر 33 ثانیه
4 متر 43 ثانیه
4 متر 40 ثانیه
59s
1 متر 0 ثانیه
1 متر 0 ثانیه
1 متر 38 ثانیه
1 متر 43 ثانیه
1 متر 40 ثانیه
همانطور که در مورد zbackup، اندازه مخزن 13 گیگابایت و حتی کمی کمتر بود، که به طور کلی انتظار می رود. من از زمان اجرا بسیار راضی بودم؛ این زمان قابل مقایسه با راه حل های مبتنی بر librsync است و قابلیت های بسیار گسترده تری را ارائه می دهد. من همچنین از توانایی تنظیم پارامترهای مختلف از طریق متغیرهای محیطی خوشحال شدم، که مزیت بسیار جدی در هنگام استفاده از borgbackup در حالت خودکار می دهد. من همچنین از بارگیری در حین تهیه نسخه پشتیبان راضی بودم: با قضاوت بر اساس بار پردازنده، borgbackup در 1 رشته کار می کند.
هنگام استفاده از آن هیچ عیب خاصی وجود نداشت.
تست رستیک
علیرغم این واقعیت که restic یک راه حل نسبتاً جدید است (2 نامزد اول در سال 2013 و بالاتر شناخته شده بودند)، ویژگی های بسیار خوبی دارد. نوشته شده در Go.
هنگامی که با zbackup مقایسه می شود، علاوه بر این نشان می دهد:
- بررسی یکپارچگی مخزن (از جمله بررسی در قطعات).
- لیست عظیمی از پروتکل ها و ارائه دهندگان پشتیبانی شده برای ذخیره پشتیبان، و همچنین پشتیبانی از rclone - rsync برای راه حل های ابری.
- مقایسه 2 نسخه پشتیبان با یکدیگر.
- نصب مخزن از طریق فیوز.
به طور کلی، لیست ویژگی ها کاملاً به borgbackup نزدیک است، در برخی جاها بیشتر و در برخی دیگر کمتر. یکی از ویژگی ها این است که هیچ راهی برای غیرفعال کردن رمزگذاری وجود ندارد و بنابراین نسخه های پشتیبان همیشه رمزگذاری خواهند شد. بیایید در عمل ببینیم چه چیزی را می توان از این نرم افزار فشرده کرد:
نتایج به شرح زیر بود:
ساعت:
راه اندازی 1
راه اندازی 2
راه اندازی 3
5 متر 25 ثانیه
5 متر 50 ثانیه
5 متر 38 ثانیه
35s
38s
36s
1 متر 54 ثانیه
2 متر 2 ثانیه
1 متر 58 ثانیه
نتایج عملکرد نیز قابل مقایسه با راه حل های مبتنی بر rsync و به طور کلی، بسیار نزدیک به borgbackup است، اما بار CPU بیشتر است (چند رشته در حال اجرا) و دندان اره است.
به احتمال زیاد، این برنامه توسط عملکرد زیرسیستم دیسک در سرور ذخیره سازی داده محدود شده است، همانطور که قبلاً در مورد rsync وجود داشت. اندازه مخزن 13 گیگابایت بود، درست مانند zbackup یا borgbackup، هیچ معایب آشکاری هنگام استفاده از این راه حل وجود نداشت.
یافته ها
در واقع، همه نامزدها به نتایج مشابه، اما با قیمت های متفاوت دست یافتند. Borgbackup بهترین عملکرد را داشت، Restic کمی کندتر بود، zbackup احتمالاً ارزش شروع استفاده را ندارد.
و اگر از قبل در حال استفاده است، سعی کنید آن را به borgbackup یا restic تغییر دهید.
یافته ها
به نظر می رسد امیدوارکننده ترین راه حل، باقی بماند، زیرا ... این اوست که بهترین نسبت قابلیت ها را به سرعت عملیاتی دارد، اما فعلاً برای نتیجه گیری کلی عجله نکنیم.
Borgbackup اساسا بدتر نیست، اما zbackup احتمالا بهتر است جایگزین شود. درست است، zbackup همچنان می تواند برای اطمینان از کارکرد قانون 3-2-1 استفاده شود. به عنوان مثال، علاوه بر امکانات پشتیبان گیری مبتنی بر (lib)rsync.
اطلاعیه
پشتیبان گیری، قسمت 5: تست بکاپ باکولا و veeam برای لینوکس
پشتیبان گیری قسمت 6: مقایسه ابزارهای پشتیبان گیری
پشتیبان گیری قسمت 7: نتیجه گیری
ارسال شده توسط: پاول دمکوویچ
منبع: www.habr.com