У дадзеным артыкуле будзе праведзена параўнанне сродкаў рэзервовага капіявання, але спачатку варта даведацца, як яны хутка і добра спраўляюцца з аднаўленнем даных з рэзервовых копій.
Для прастаты параўнання будзе разглядацца аднаўленне з поўнай рэзервовай копіі, тым больш што гэты рэжым працы падтрымліваюць усе кандыдаты. Для прастаты лічбы ўзяты ўжо асераднёнымі (сярэдняе арыфметычнае з некалькіх запускаў). Вынікі будуць зведзены ў табліцу, у якой таксама будзе інфармацыя і аб магчымасцях: наяўнасць вэб-інтэрфейсу, прастата ў наладзе і працы, здольнасць да аўтаматызацыі, наяўнасць розных дадатковых магчымасцяў (напрыклад, праверка цэласнасці дадзеных) і да т.п. Графікі будуць паказваць загрузку сервера, дзе дадзеныя і будуць прымяняцца (не сервера для захоўвання рэзервовых копій).
аднаўленне дадзеных
У якасці апорнай кропкі будуць выкарыстоўвацца rsync і tar, паколькі найпростыя скрыпты для зняцця рэзервовых копій.
Rsync справіўся з тэставым наборам дадзеных за 4 хвіліны і 28 секунд, паказаўшы
такую нагрузку
Працэс аднаўлення упёрся ў абмежаванне дыскавай падсістэмы сервера захоўвання рэзервовых копій (пілападобныя графікі). Таксама выразна відаць загрузку аднаго ядра без асаблівых праблем (нізкі iowait і softirq - няма праблем з дыскам і сеткай адпаведна). Паколькі дзве іншыя праграмы, а менавіта rdiff-backup і rsnapshot, заснаваныя на rsync, а таксама прапануюць у якасці сродку аднаўлення звычайны rsync, – у іх будзе прыкладна такі ж профіль нагрузкі і час аднаўлення рэзервовай копіі.
Смала справіўся крыху хутчэй, за
2 хвіліны і 43 секунды:
Поўная загрузка сістэмы была вышэй у сярэднім на 20% з-за ўзрослай softirq – узраслі накладныя выдаткі пры працы сеткавай падсістэмы.
Калі архіў дадаткова сціснуць, той час аднаўлення ўзрастае да 3 хвілін 19 секунд з
такой нагрузкай на асноўным серверы (распакоўка на баку асноўнага сервера):
Працэс распакавання займае абодва працэсарных ядра, паколькі працуе два працэсы. У цэлым - чаканы вынік. Таксама параўнальны вынік (3 хвіліны і 20 секунд) атрымаўся пры запуску gzip на боку сервера з рэзервовымі копіямі, профіль нагрузкі на асноўным серверы быў вельмі падобным на запуск tar без кампрэсара gzip (гл. папярэдні графік).
В rdiff-рэзервовае капіраванне можна сінхранізаваць апошнюю зробленую рэзервовую копію з дапамогай звычайнага rsync (вынікі будуць аналагічнымі), але больш старыя рэзервовыя копіі ўсё роўна трэба аднаўляць з дапамогай праграмы rdiff-backup, якая зладзілася з аднаўленнем за 17 мінуць і 17 секунд, паказаўшы
такую нагрузку:
Магчыма так і было задумана, ва ўсякім разе для абмежавання хуткасці аўтары . Сам працэс аднаўленне рэзервовай копіі займае крыху менш за палову аднаго ядра, з прапарцыйна параўнальнай прадукцыйнасцю (г.зн. у 2-5 разоў павольней) па дыску і сеткі з rsync.
Rsnapshot для аднаўлення прапануе выкарыстоўваць звычайны rsync, таму яго вынікі будуць аналагічнымі. У цэлым так яно і атрымалася.
Адрыжка з задачай аднаўлення рэзервовай копіі справіўся за 7 хвілін і 2 секунды з
такой нагрузкай:
Адпрацаваў досыць хутка, і, прынамсі, значна зручней чыстага rsync: не трэба памятаць якія-небудзь сцягі, просты і інтуітыўны cli-інтэрфейс, убудаваная падтрымка некалькіх дзід, праўда разу ў два павольней. Калі дадзеныя трэба аднаўляць з апошняй зробленай рэзервовай копіі - можна скарыстацца rsync, з невялікімі агаворкамі.
Прыкладна такую ж хуткасць і нагрузку паказала праграма Рэзервовы ПК пры ўключэнні рэжыму перадачы rsync, разгарнуўшы рэзервовую копію за
7 хвілін і 42 секунды:
А вось у рэжыме перадачы дадзеных з tar BackupPC зладзіўся павольней: за 12 хвілін і 15 секунд, нагрузка па працэсары пры гэтым была ў цэлым ніжэй
у паўтара раза:
Двудушнасць без шыфравання паказаў крыху лепшыя вынікі, справіўшыся з аднаўленнем рэзервовай копіі за 10 хвілін і 58 секунд. Калі актываваць шыфраванне з дапамогай gpg - час аднаўлення ўзрастае да 15 хвілін і 3 секунд. Таксама пры стварэнні рэпазітара для захоўвання дзід можна паказаць памер архіва, які будзе выкарыстаны пры разбіцці струменя ўваходных дадзеных. У цэлым, на звычайных цвёрдых дысках, гэтак жа ў сувязі з аднаструменным рэжымам працы, асаблівай розніцы няма. Яна, магчыма, з'явіцца пры розных памерах блокаў, калі выкарыстоўваюцца гібрыдныя сховішчы. Нагрузка на асноўным серверы пры аднаўленні была такой:
без шыфравання
з шыфраваннем
Дублікат паказаў параўнальную хуткасць аднаўлення, справіўшыся за 13 хвілін і 45 секунд. Яшчэ каля 5 хвілін заняла праверка карэктнасці адноўленых дадзеных (сумарна каля 19 хвілін). Нагрузка пры гэтым была
дастаткова высокай:
Калі шыфраванне aes актывавалася ўнутранымі сродкамі, час аднаўлення склала 21 хвіліну 40 секунд, прычым загрузка па працэсары была максімальнай (абодва ядра!) падчас аднаўлення; пры праверцы дадзеных быў актыўны толькі адзін струмень, які займае адно працэсарнае ядро. Праверка дадзеных пасля аднаўлення заняла тыя ж 5 хвілін (сумарна амаль 27 хвілін).
Вынік
Крыху хутчэй duplicati справіўся з аднаўленнем пры выкарыстанні для шыфравання знешняй праграмы gpg, але ў цэлым адрозненні ад папярэдняга рэжыму мінімальныя. Час працы склаў 16 хвілін 30 секунд, з праверкай дадзеных у 6 хвілін. Нагрузка была
такі:
AMANDA, якая выкарыстоўвае tar, зладзілася за 2 хвіліны 49 секунд, што, у прынцыпе, вельмі блізка да звычайнага tar. Нагрузка на сістэму ў прынцыпе
такая ж:
Пры аднаўленні рэзервовай копіі сродкамі zbackup атрымаліся наступныя вынікі:
шыфраванне, сціск lzma
Час працы 11 хвілін і 8 секунд
шыфраванне aes, сціск lzma
Час працы 14 хвілін
шыфраванне aes, сціск lzo
Час працы 6 хвілін, 19 секунд
У цэлым, нядрэнна. Усё ўпіраецца ў хуткасць працэсара на серверы рэзервовага капіявання, што дастаткова выразна відаць па часе працы праграмы з рознымі кампрэсарамі. З боку сервера рэзервовага капіявання запускаўся звычайны tar, так што калі параўнаць з ім - аднаўленне працуе ў 3 разы павольней. Магчыма, варта праверыць працу ў шматструменным рэжыме, з лікам патокаў больш за два.
BorgBackup у рэжыме без шыфравання зладзіўся ледзь павольней tar, за 2 хвіліны 45 секунд, аднак, у адрозненне ад таго ж tar, з'явілася магчымасць дэдуплікацыі рэпазітара. Нагрузка пры гэтым атрымалася
наступнай:
Калі актываваць шыфраванне на аснове blake, то хуткасць узнаўлення рэзервовай копіі ледзь запавольваецца. Час аднаўлення ў гэтым рэжыме 3 хвіліны 19 секунд, а нагрузка выйшла
такая:
Шыфраванне aes працуе крыху павольней, час аднаўлення 3 хвіліны 23 секунды, нагрузка асоба
не памянялася:
Паколькі Borg можа працаваць у шматструменным рэжыме – загрузка працэсара максімальная, пры гэтым пры актывацыі дадатковых функцый проста расце час працы. Па ўсёй бачнасці, варта даследаваць шматструменнасць працы аналагічна zbackup.
Рэстык справіўся з аднаўленнем крыху павольней, час працы склаў 4 хвіліны 28 секунд. Нагрузка пры гэтым выглядала
так:
Па ўсёй бачнасці працэс аднаўлення працуе ў некалькі патокаў, але эфектыўнасць не такая высокая, як у BorgBackup, але параўнальна па часе са звычайным rsync.
З дапамогай urBackup атрымалася аднавіць дадзеныя за 8 хвілін і 19 секунд, нагрузка пры гэтым была
такі:
Усё гэтак жа бачна не моцна высокую нагрузку, нават ніжэй, чым у tar. Месцамі воплескі, але не больш за загрузкі аднаго ядра.
Выбар і абгрунтаванне крытэрыяў для параўнання
Як было сказана ў адной з папярэдніх артыкулаў, сістэма рэзервовага капіявання павінна адпавядаць наступным крытэрам:
- Прастата ў працы
- Універсальнасць
- стабільнасць
- шпаркасць
Варта разгледзець кожны пункт асобна больш дэталёва.
Прастата працы
Лепш за ўсё, калі ёсць адна кнопка "Зрабіць усё добра", але калі вярнуцца да рэальных праграм - зручней за ўсё будзе некаторы звыклы і стандартны прынцып працы.
Большасці карыстачоў, верагодней за ўсё, будзе лепш, калі не трэба запамінаць кучу ключоў для cli, наладжваць кучу розных, часцяком малазразумелых опцый праз web ці tui, наладжваць абвесткі аб няўдалай працы. Сюды ж адносіцца магчымасць лёгка "ўпісаць" рашэнне для рэзервовага капіявання ў існуючую інфраструктуру, а таксама аўтаматызацыя працэсу рэзервовага капіявання. Тут жа магчымасць усталёўкі пакетным мэнэджарам, ці ў адну–дзве каманды выгляду «спампаваць і распакаваць». curl ссылка | sudo bash - Складаны метад, паколькі трэба праверыць, што прылятае па спасылцы.
Напрыклад, з разгледжаных кандыдатаў простым рашэннем з'яўляецца burp, rdiff-backup і restic, якія маюць мнеманічна запамінальныя ключы для розных рэжымаў працы. Крыху больш складаным - borg і duplicity. Самым складаным была AMANDA. Астатнія па прастаце выкарыстання недзе пасярэдзіне. У любым выпадку, калі трэба больш за 30 секунд на чытанне кіраўніцтва карыстача, ці трэба схадзіць у Google ці іншы пошукавік, а таксама прагартаць доўгую прасціну help — рашэнне складанае, так ці інакш.
Частка разгледжаных кандыдатаў умеюць аўтаматычна адправіць паведамленне па e-mailjabber, іншыя ж належаць на настроеныя абвесткі ў сістэме. Пры гэтым часцей за ўсё складаныя рашэнні маюць не зусім відавочныя налады абвестак. У любым выпадку, калі праграма зняцця рэзервовай копіі выдасць ненулявы код вяртання, які будзе правільна зразуметы сістэмным сэрвісам перыядычных задач (паляціць паведамленне сістэмнаму адміністратару або адразу ў маніторынг) - сітуацыя простая. А вось калі сістэма рэзервовага капіявання, якая працуе не на серверы рэзервовых копій, не можа без наладкі, відавочным спосабам сказаць аб праблеме – складанасць ужо залішняя. У любым выпадку выдача папярэджанняў і іншых паведамленняў толькі ў вэб-інтэрфейс або ў часопіс - дрэнная практыка, паколькі часцей за ўсё яны будуць праігнараваныя.
Што ж тычыцца аўтаматызацыі – простая праграма ўмее чытаць зменныя асяроддзі, якія задаюць яе рэжым працы, альбо мае развіты cli, здольны цалкам дубляваць паводзіны пры працы праз вэб-інтэрфейс, напрыклад. Сюды ж адносіцца магчымасць струменевай працы, наяўнасць магчымасцяў для пашырэння і да т.п.
Універсальнасць
Часткова пераклікаецца з папярэднім падраздзелам у частцы аўтаматызацыі, не павінна быць асаблівай праблемай "упісаць" працэс рэзервовага капіявання ў існуючую інфраструктуру.
Варта адзначыць, што выкарыстанне нестандартных партоў (ну акрамя вэб-інтэрфейсу) для працы, рэалізацыя шыфравання нестандартным спосабам, абмен дадзенымі нестандартным пратаколам – прыкметы неўніверсальнага рашэння. Па большай частцы ўсе кандыдаты так ці інакш іх маюць з відавочнай прычыны: прастата і ўніверсальнасць звычайна не сумяшчальныя. У якасці выключэння - burp, ёсць і іншыя.
У якасці прыкметы - магчымасць працы выкарыстоўваючы звычайны ssh.
хуткасць працы
Самы супярэчлівы і спрэчны пункт. З аднаго боку - запусцілі працэс, ён адпрацаваў максімальна хутка і не перашкаджае асноўным задачам. З іншага - усплёск трафіку і нагрузкі на працэсар на час рэзервовага капіявання. Яшчэ варта адзначыць, што самыя хуткія праграмы для зняцця копій звычайна самыя бедныя па функцый, важным для карыстальнікаў. Ізноў жа: калі для таго, каб дастаць адзін няшчасны тэкставы файлік памерам некалькі дзясяткаў байт з паролем, а з-за яго варта ўвесь сэрвіс (так-так, я разумею, што тут працэс рэзервовага капіявання часцей за ўсё не вінаваты), і трэба перачытаць паслядоўна ўсе файлы ў рэпазітары ці разгарнуць цэлы архіў - сістэма рэзервовага капіявання ні разу не хуткая. Яшчэ адзін пункт, які часта становіцца каменем спатыкнення - хуткасць разгортвання рэзервовай копіі з архіва. Тут відавочная перавага ў тых, хто можа проста скапіяваць ці перамясціць файлы ў патрэбнае месца без адмысловых маніпуляцый (rsync да прыкладу), але часцей за ўсё праблему трэба вырашаць арганізацыйным спосабам, эмпірычным шляхам: вымяраць час узнаўлення рэзервовай копіі і адчынена пра гэта паведамляць карыстачам.
стабільнасць
Варта разумець так: з аднаго боку, павінна быць магчымасць разгарнуць зваротна рэзервовую копію па-любому, з іншай — устойлівасць да розных праблем: абрыў сеткі, адмова дыска, выдаленне часткі рэпазітара.
Параўнанне сродкаў рэзервовага капіявання
Час стварэння копіі
Час аднаўлення копіі
простая ўстаноўка
Простая настройка
простае выкарыстанне
Простая аўтаматызацыя
Ці патрэбен кліентсервер?
Праверка цэласнасці рэпазітара
Рознасныя копіі
Праца праз pipe
Універсальнасць
Самастойнасць
Празрыстасць рэпазітара
шыфраванне
сціск
Дэдуплікацыя
Web-інтэрфейс
Заліванне ў воблака
Падтрымка Windows
бал
Rsync
4m15s
4m28s
ды
няма
няма
няма
ды
няма
няма
ды
няма
ды
ды
няма
няма
няма
няма
няма
ды
6
Смала
чысты
3m12s
2m43s
ды
няма
няма
няма
няма
няма
ды
ды
няма
ды
няма
няма
няма
няма
няма
няма
ды
8,5
GZIP
9m37s
3m19s
ды
Rdiff-backup
16m26s
17m17s
ды
ды
ды
ды
ды
няма
ды
няма
ды
няма
ды
няма
ды
ды
ды
няма
ды
11
Rsnapshot
4m19s
4m28s
ды
ды
ды
ды
няма
няма
ды
няма
ды
няма
ды
няма
няма
ды
ды
няма
ды
12,5
Адрыжка
11m9s
7m2s
ды
няма
ды
ды
ды
ды
ды
няма
ды
ды
няма
няма
ды
няма
ды
няма
ды
10,5
Двудушнасць
няма шыфравання
16m48s
10m58s
ды
ды
няма
ды
няма
ды
ды
няма
няма
ды
няма
ды
ды
няма
ды
няма
ды
11
GPG
17m27s
15m3s
Дублікат
няма шыфравання
20m28s
13m45s
няма
ды
няма
няма
няма
ды
ды
няма
няма
ды
няма
ды
ды
ды
ды
ды
ды
11
АЕС
29m41s
21m40s
GPG
26m19s
16m30s
zbackup
няма шыфравання
40m3s
11m8s
ды
ды
няма
няма
няма
ды
ды
ды
няма
ды
няма
ды
ды
ды
няма
няма
няма
10
АЕС
42m0s
14m1s
aes+lzo
18m9s
6m19s
BorgBackup
няма шыфравання
4m7s
2m45s
ды
ды
ды
ды
ды
ды
ды
ды
ды
ды
няма
ды
ды
ды
ды
няма
ды
16
АЕС
4m58s
3m23s
Блэйк2
4m39s
3m19s
Рэстык
5m38s
4m28s
ды
ды
ды
ды
няма
ды
ды
ды
ды
ды
няма
ды
няма
ды
няма
ды
ды
15,5
urBackup
8m21s
8m19s
ды
ды
ды
няма
ды
няма
ды
няма
ды
ды
няма
ды
ды
ды
ды
няма
ды
12
Аманда
9m3s
2m49s
ды
няма
няма
ды
ды
ды
ды
няма
ды
ды
ды
ды
ды
няма
ды
ды
ды
13
Рэзервовы ПК
Rsync
12m22s
7m42s
ды
няма
ды
ды
ды
ды
ды
няма
ды
няма
няма
ды
ды
няма
ды
няма
ды
10,5
дзёгаць
12m34s
12m15s
Легенда табліцы:
- Зялёны, час працы менш за пяць хвілін, ці адказ «Так» (акрамя слупка «Патрэбен кліентсервер?»), 1 бал
- Жоўты, час працы пяць-дзесяць хвілін, 0.5 бала
- Чырвоны, час працы больш за дзесяць хвілін, ці адказ «Не» (акрамя слупка «Патрэбен кліентсервер?»), 0 балаў
Згодна з вышэйпрыведзенай табліцы найбольш простым, хуткім, а разам з тым зручнай і магутнай прыладай для рэзервовага капіявання з'яўляецца BorgBackup. Другое месца заняў Restic, астатнія разгледжаныя кандыдаты размясціліся прыкладна аднолькава з роскідам у адзін-два балы ў канцы.
Дзякую ўсім, хто дачыталі цыкл да канца, прапаную абмеркаваць варыянты, прапанаваць свае, калі ёсць. Па меры абмеркавання табліца можа быць дапоўнена.
Вынікам цыклу стане заключны артыкул, у якім будзе спроба вывесці ідэальны, хуткі і кіраваны сродак для рэзервовага капіявання, якое дазваляе ў найкароткія тэрміны разгарнуць зваротна копію і разам з тым - мець выгоду і прастату ў наладзе і суправаджэнні.
анонс
Рэзервовае капіраванне, частка 6: Параўнанне сродкаў рэзервовага капіявання
Рэзервовае капіраванне, частка 7: Высновы
Крыніца: habr.com