У дадзеным артыкуле будуць разглядацца праграмныя сродкі для рэзервовага капіявання, якія шляхам разбіцця патоку даных на асобныя кампаненты (chunks), фарміруюць рэпазітар.
Кампаненты рэпазітара могуць дадаткова сціскацца і шыфравацца, а самае галоўнае - пры паўторных працэсах рэзервовага капіявання - перавыкарыстоўвацца паўторна.
Рэзервовая копія ў падобным рэпазітары - найменны ланцужок звязаных адзін з адным кампанентаў, напрыклад, на аснове розных hash-функцый.
Ёсць некалькі падобных рашэнняў, я спынюся на 3: zbackup, borgbackup і restic.
чаканыя вынікі
Паколькі ўсе прэтэндэнты так ці інакш патрабуюць стварэння рэпазітара, адным з найважнейшых фактараў будзе ацэнка памеру рэпазітара. У ідэальным выпадку яго памер павінен быць не больш за 13 гігабайт паводле прынятай методыцы, а то і менш – пры ўмове добрай аптымізацыі.
Таксама вельмі пажадана мець магчымасць ствараць рэзервовыя копіі файлаў напрамую, без ужывання архіватараў тыпу tar, а таксама працу з ssh/sftp без дадатковых сродкаў накшталт rsync і sshfs.
Паводзіны пры стварэнні рэзервовых копій:
- Памер рэпазітара будзе роўны памеру змен, ці менш.
- Чакаецца вялікая нагрузка на працэсар пры выкарыстанні сціску і/ці шыфраванні, а таксама верагодная досыць вялікая нагрузка на сетку і дыскавую падсістэму, калі працэс архівацыі і/ці шыфраванні будзе працаваць на серверы захоўвання рэзервовых дзід.
- Калі пашкодзіць рэпазітар - верагодная адкладзеная памылка як пры стварэнні новых рэзервовых копій, так і пры спробе аднаўлення. Трэба планаваць дадатковыя меры па забеспячэнні цэласнасці рэпазітара або выкарыстоўваць убудаваныя сродкі праверкі яго цэласнасці.
У якасці эталоннага значэння прынята праца з tar, як гэта было паказана ў адной з мінулых артыкулаў.
Тэставанне zbackup
Агульны механізм працы zbackup складаецца ў тым, што праграма знаходзіць у струмені дадзеных, які падаецца на ўваходзе, вобласці, утрымоўвальныя аднолькавыя дадзеныя, затым апцыянальна іх сціскае, шыфруе, захоўваючы кожную вобласць толькі 1 раз.
Для дэдуплікацыі выкарыстоўваецца 64-бітная кальцавая hash-функцыя са слізгальным акном для пабайтнай праверкі на супадзенне з ужо існуючымі блокамі дадзеных (падобнаму таму, як гэта рэалізавана ў rsync).
Для сціску ўжываецца lzma і lzo у шматструменным выкананні, а для шыфравання - aes. У апошніх версіях прысутнічае магчымасць у будучыні выдаляць старыя дадзеныя з рэпазітара.
Праграма напісана на C++ з мінімальнымі залежнасцямі. Аўтар па ўсёй бачнасці натхняўся unix-way, таму праграма прымае дадзеныя на stdin пры стварэнні рэзервовых дзід, выдаючы аналагічны струмень дадзеных у stdout пры аднаўленні. Такім чынам, zbackup можна выкарыстоўваць як вельмі нядрэнная «цаглінка» пры напісанні ўласных рашэнняў рэзервовага капіявання. Напрыклад, у аўтара артыкула гэтая праграма з'яўляецца асноўным сродкам рэзервовага капіравання для хатніх машын прыкладна з 2014 года.
У якасці струменя дадзеных будзе прымяняцца звычайны tar, калі не сказана інакш.
Паглядзім, якія будуць вынікі:
Праверка працы выконвалася ў 2 варыянтах:
- ствараецца рэпазітар і запускаецца zbackup на серверы з зыходнымі дадзенымі, потым змесціва рэпазітара перадаецца на сервер захоўвання рэзервовых копій.
- ствараецца рэпазітар на серверы захоўвання рэзервовых копій, запускаецца zbackup праз ssh на серверы захоўвання рэзервовых копій, яму праз pipe выдаюцца дадзеныя.
Вынікі першага варыянту былі такія: 43m11s - пры выкарыстанні нешыфраванага рэпазітара і кампрэсара lzma, 19m13s - пры замене кампрэсара на lzo.
Нагрузка на сэрвэры з зыходнымі дадзенымі была наступнай (паказаны прыклад з lzma, з lzo была прыкладна такая ж карцінка, але дзель rsync была прыкладна чвэрць ад часу):
Ясна відаць, што падобны працэс рэзервовага капіявання падыходзіць толькі пры адносна рэдкіх і невялікіх зменах. Таксама вельмі пажадана абмяжоўваць працу zbackup у 1 струмень, інакш будзе вельмі высокая загрузка па працэсары, т.к. праграма вельмі добра ўмее працаваць у некалькі плыняў. Нагрузка на дыск была невялікай, што ў цэлым пры сучаснай дыскавай падсістэме на аснове ssd будзе неўзаметку. Таксама выразна відаць запуск працэсу сінхранізацыі дадзеных рэпазітара на выдалены сервер, хуткасць працы параўнальная са звычайным rsync і ўпіраецца ў прадукцыйнасць дыскавай падсістэмы сервера захоўвання рэзервовых дзід. Мінусам падыходу з'яўляецца захоўванне лакальнага рэпазітара і, як следства, - дубліраванне дадзеных.
Больш цікавым і дастасавальным на практыцы з'яўляецца другі варыянт з запускам zbackup адразу на серверы захоўвання рэзервовых копій.
Для пачатку будзе праверана праца без выкарыстання шыфравання з кампрэсарам lzma:
Час працы кожнага тэставага запуску:
Запуск 1
Запуск 2
Запуск 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Калі актываваць шыфраванне з ужываннем aes, вынікі досыць блізкія:
Час працы на тых жа дадзеных, з шыфраваннем:
Запуск 1
Запуск 2
Запуск 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Калі шыфраванне сумясціць са сціскам на lzo, выходзіць так:
Час працы:
Запуск 1
Запуск 2
Запуск 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Памер выніковага рэпазітара быў адносна аднолькавы і складаў 13гб. Гэта значыць, што дэдуплікацыя працуе карэктна. Таксама на ўжо сціснутых дадзеных ужыванне lzo дае адчувальны эфект, па агульным часе працы zbackup ушчыльную набліжаецца да duplicity/duplicati, аднак адстаючы ад заснаваных на librsync у 2-5 раз.
Перавагі відавочныя - эканомія дыскавай прасторы на серверы захоўвання рэзервовых копій. Што тычыцца інструментаў праверкі рэпазітара - аўтарам zbackup яны не прадугледжаны, рэкамендуецца прымяняць адмоваўстойлівы дыскавы масіў або хмарны правайдэр.
У цэлым вельмі нядрэннае ўражанне, нягледзячы на тое, што праект прыкладна 3 гады стаіць на месцы (апошні feature request быў каля года таму, але без адказу).
Тэставанне borgbackup
Borgbackup з'яўляецца форкам attic, яшчэ адной, падобнай з zbackup сістэмы. Напісаны на python, мае падобны на zbackup спіс магчымасцяў, але дадаткова ўмее:
- Мантаваць рэзервовыя копіі праз fuse
- Правяраць змесціва рэпазітара
- Працаваць у рэжыме кліент-сервер
- Выкарыстоўваць розныя кампрэсары для дадзеных, а таксама эўрыстычнае вызначэнне тыпу файла пры яго кампрэсіі.
- 2 варыянты шыфравання, aes і blake
- Убудаваны сродак для
праверкі прадукцыйнасці
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Вынікі атрымаліся такія:
CZ-BIG 96.51 MB/s (10 100.00 MB all-zero files: 10.36s)
RZ-BIG 57.22 MB/s (10 100.00 MB all-zero files: 17.48s)
UZ-BIG 253.63 MB/s (10 100.00 MB all-zero files: 3.94s)
DZ-BIG 351.06 MB/s (10 100.00 MB all-zero files: 2.85s)
CR-BIG 34.30 MB/s (10 100.00 MB random files: 29.15s)
RR-BIG 60.69 MB/s (10 100.00 MB random files: 16.48s)
UR-BIG 311.06 MB/s (10 100.00 MB random files: 3.21s)
DR-BIG 72.63 MB/s (10 100.00 MB random files: 13.77s)
CZ-MEDIUM 108.59 MB/s (1000 1.00 MB all-zero files: 9.21s)
RZ-MEDIUM 76.16 MB/s (1000 1.00 MB all-zero files: 13.13s)
UZ-MEDIUM 331.27 MB/s (1000 1.00 MB all-zero files: 3.02s)
DZ-MEDIUM 387.36 MB/s (1000 1.00 MB all-zero files: 2.58s)
CR-MEDIUM 37.80 MB/s (1000 1.00 MB random files: 26.45s)
RR-MEDIUM 68.90 MB/s (1000 1.00 MB random files: 14.51s)
UR-MEDIUM 347.24 MB/s (1000 1.00 MB random files: 2.88s)
DR-MEDIUM 48.80 MB/s (1000 1.00 MB random files: 20.49s)
CZ-SMALL 11.72 MB/s (10000 10.00 kB all-zero files: 8.53s)
RZ-SMALL 32.57 MB/s (10000 10.00 kB all-zero files: 3.07s)
UZ-SMALL 19.37 MB/s (10000 10.00 kB all-zero files: 5.16s)
DZ-SMALL 33.71 MB/s (10000 10.00 kB all-zero files: 2.97s)
CR-SMALL 6.85 MB/s (10000 10.00 kB random files: 14.60s)
RR-SMALL 31.27 MB/s (10000 10.00 kB random files: 3.20s)
UR-SMALL 12.28 MB/s (10000 10.00 kB random files: 8.14s)
DR-SMALL 18.78 MB/s (10000 10.00 kB random files: 5.32s)
Пры тэставанні будзе выкарыстоўвацца эўрыстыка пры кампрэсіі з вызначэннем тыпу файла (compression auto), а вынікі будуць такія:
Для пачатку праверым працу без шыфравання:
Час працы:
Запуск 1
Запуск 2
Запуск 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Калі ўключыць аўтарызацыю рэпазітара (рэжым authenticated), вынікі атрымаюцца блізкімі:
Час працы:
Запуск 1
Запуск 2
Запуск 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Пры актывацыі шыфравання aes вынікі не моцна пагоршыліся:
Запуск 1
Запуск 2
Запуск 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
А калі памяняць aes на blake, сітуацыя зусім палепшыцца:
Час працы:
Запуск 1
Запуск 2
Запуск 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Як і ў выпадку з zbackup, памер рэпазітара склаў 13гб і нават крыху менш, што, у цэлым, чакана. Вельмі парадавала час працы, яно параўнальна з рашэннямі на аснове librsync, забяспечваючы значна шырэйшыя магчымасці. Таксама парадавала магчымасць задання розных параметраў праз зменныя асяроддзі, што дае вельмі сур'ёзная перавага пры выкарыстанні borgbackup у аўтаматычным рэжыме. Таксама парадавала нагрузка пры рэзервовым капіяванні: мяркуючы па загрузцы працэсара - borgbackup працуе ў 1 паток.
Адмысловых мінусаў пры выкарыстанні не выявілася.
Тэставанне restic
Нягледзячы на тое, што restic дастаткова новае рашэнне (першыя 2 кандыдаты былі вядомыя яшчэ з 2013 года і старэй), ён валодае дастаткова нядрэннымі характарыстыкамі. Напісаны на Go.
Калі параўноўваць з zbackup, дадаткова дае:
- Праверку цэласнасці рэпазітара (уключаючы праверку па частках).
- Велізарны спіс падтрымліваемых пратаколаў і правайдэраў для захоўвання рэзервовых копій, а таксама падтрымку rclone - rsync для "хмарных" рашэнняў.
- Параўнанне 2 рэзервовых копій паміж сабой.
- Манціраванне рэпазітара праз fuse.
У цэлым спіс магчымасцяў дастаткова блізкі да borgbackup, месцамі больш, месцамі менш. З асаблівасцяў - адсутнасць магчымасці адключэння шыфравання, а такім чынам, рэзервовыя копіі будуць зашыфраванымі заўсёды. Давайце паглядзім на практыцы, што можна выціснуць з гэтага ПЗ:
Вынікі атрымаліся наступныя:
Час працы:
Запуск 1
Запуск 2
Запуск 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Вынікі працы таксама параўнальныя з рашэннямі на аснове rsync і, у цэлым, вельмі блізкія да borgbackup, але нагрузка на працэсар больш высокая (працуе некалькі струменяў) і пилообразная.
Верагодней за ўсё, праграма ўпіраецца ў прадукцыйнасць дыскавай падсістэмы на серверы захоўвання дадзеных, як гэта ўжо было з rsync. Памер рэпазітара склаў 13гб, як і ў zbackup ці borgbackup, відавочных мінусаў пры выкарыстанні гэтага рашэння не выявілася.
Вынікі
Па факце ва ўсіх кандыдатаў атрымаліся блізкія паказчыкі, аднак розным коштам. Лепш за ўсіх паказаў сябе borgbackup, крыху павольней - restic, zbackup, верагодна, не варта пачынаць ужываць,
а калі ён ужо выкарыстоўваецца - спрабаваць мяняць на borgbackup або restic.
Высновы
Найбольш перспектыўным рашэннем выглядае restic, т.я. менавіта ён валодае найлепшымі суадносінамі магчымасцяў да хуткасці працы, але пакуль не будзем спяшацца з агульнымі высновамі.
Borgbackup у прынцыпе нічым не горш, а вось zbackup, верагодна, лепш замяніць. Праўда, для забеспячэння працы правілы 3-2-1 zbackup усё яшчэ можна задзейнічаць. Напрыклад, у дадатак да сродкаў рэзервовага капіявання на аснове (lib)rsync.
анонс
Рэзервовае капіраванне, частка 5: Тэставанне bacula і veeam backup for linux
Рэзервовае капіраванне, частка 6: Параўнанне сродкаў рэзервовага капіявання
Рэзервовае капіраванне, частка 7: Высновы
Аўтар публікацыі: Павел Дзямковіч
Крыніца: habr.com