У дадзенай нататцы разгледжаны сродкі рэзервовага капіявання, якія выконваюць рэзервовае капіраванне шляхам стварэння архіваў на рэзервовым серверы.
З тых, якія задавальняюць патрабаванням - duplicity (да якога ёсць прыемны інтэрфейс у выглядзе deja dup) і duplicati.
Яшчэ адзін вельмі характэрны сродак рэзервовага капіявання – dar, але паколькі ў яго маецца вельмі шырокі спіс опцый – методыка тэставання пакрывае ці ледзь 10% ад таго, на што ён здольны, – яго ў рамках бягучага цыклу не тэстуем.
чаканыя вынікі
Паколькі абодва кандыдаты так ці інакш ствараюць архівы, то ў якасці арыенціра можна выкарыстоўваць звычайны tar.
Дадаткова ацэнім, наколькі добра аптымізуецца захоўванне дадзеных на серверы захоўвання шляхам стварэння рэзервовых дзід, утрымоўвальных толькі розніцу паміж поўнай копіяй і бягучым станам файлаў, ці паміж мінулым і бягучым архівамі (інкрыментальныя, дэкрэментальныя і да т.п.).
Паводзіны пры стварэнні рэзервовых копій:
- Параўнальна невялікі лік файлаў на серверы захоўвання рэзервовых дзід (параўнальна з лікам рэзервовых дзід ці памерам дадзеных у гігабайт), але досыць вялікі іх памер (дзясяткі-сотні мегабайт).
- Памер рэпазітара будзе ўключаць толькі змены - дублікаты не будуць захоўвацца, такім чынам памер рэпазітара будзе менш, чым пры працы ПА на аснове rsync.
- Чакаецца вялікая нагрузка на працэсар пры выкарыстанні сціску і/ці шыфраванні, а таксама, верагодна, досыць вялікая нагрузка на сетку і дыскавую падсістэму, калі працэс архівацыі і/ці шыфраванні будзе працаваць на серверы захоўвання рэзервовых дзід.
У якасці эталоннага значэння запусцім наступную каманду:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Вынікі выканання атрымаліся такія:
Час выканання 3m12s. Відаць, што хуткасць уперлася ў дыскавую падсістэму сервера захоўвання рэзервовых копій, як і ў прыкладзе з . Толькі крыху хутчэй, т.к. запіс ідзе ў адзін файл.
Таксама для адзнакі сціску запусцім той жа варыянт, але ўлучым сціск на боку сервера рэзервовага капіявання:
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 у pipe. Для арыенціра будзе такая каманда:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Вынікі атрымаліся такія:
Час выканання атрымалася 10m30s, паколькі запушчана 2 працэсы на які прымае боку - вузкае месца зноў однопоточный кампрэсар, плюс невялікія накладныя выдаткі на шыфраванне.
UPD: Па просьбе bliznezz дадаю тэсты з pigz. Калі выкарыстоўваць толькі кампрэсар - атрымалася за 6m30s, калі яшчэ дадаць і шыфраванне - прыкладна 7m. Правал на ніжнім графіку - няскінуты дыскавы кэш:
Тэставанне duplicity
Duplicity - праграмнае забеспячэнне на python для рэзервовага капіявання шляхам стварэння шыфраваных архіваў у фармаце tar.
Для інкрыментальных архіваў прымяняецца librsync, такім чынам, можна чакаць паводзін, апісанага ў .
Рэзервовыя копіі могуць шыфравацца і падпісвацца з дапамогай gnupg, што немалаважна пры выкарыстанні розных правайдэраў для захоўвання рэзервовых копій (s3, backblaze, gdrive і да т.п.)
Паглядзім, якія будуць вынікі:
Вось такія вынікі атрымаліся пры запуску без шыфравання.
спойлер
Час працы кожнага тэставага запуску:
Запуск 1
Запуск 2
Запуск 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
А вось вынікі пры ўключэнні шыфравання gnupg, з памерам ключа 2048 біт:
Час працы на тых жа дадзеных, з шыфраваннем:
Запуск 1
Запуск 2
Запуск 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Быў паказаны памер блока – 512 мегабайт, што выразна відаць на графіках; загрузка працэсара фактычна трымалася на ўзроўні 50%, значыць, праграма ўтылізуе не больш за аднаго працэсарнага ядра.
Таксама дастаткова добра відаць прынцып працы праграмы: узялі кавалачак дадзеных, паціснулі яго, адправілі на сервер захоўвання рэзервовых копій, які можа быць дастаткова павольным.
Яшчэ адна асаблівасць - прадказальны час працы праграмы, якое залежыць толькі ад памеру змененых дадзеных.
Уключэнне шыфравання не асабліва павялічыла час працы праграмы, але падвысіла загрузку працэсара прыкладна на 10%, што можа быць вельмі нядрэнным прыемным бонусам.
Нажаль, дадзеная праграма не змагла карэктна выявіць сітуацыю з перайменаваннем каталога, і выніковы памер рэпазітара апынуўся роўны памеру змен (г.зн. усё 18гб), але магчымасць выкарыстаць недавераны сервер для рэзервовага капіявання адназначна перакрывае такія паводзіны.
Тэставанне duplicati
Дадзенае праграмнае забеспячэнне напісана на C#, запускаецца, выкарыстоўваючы набор бібліятэк ад Mono. Ёсць GUI, а таксама cli версія.
Прыкладны спіс асноўных магчымасцяў блізкі да duplicity, у тым ліку розных правайдэраў для захоўвання рэзервовых копій, аднак, у адрозненне ад duplicity, большасць магчымасцяў даступна без іншых сродкаў. Плюс гэта ці мінус - залежыць ад пэўнага выпадку, аднак для пачаткоўцаў, верагодней за ўсё, прасцей мець перад вачыма спіс адразу ўсіх магчымасцяў, чым даўсталёўваць пакеты для python, як у выпадку з duplicity.
Яшчэ адзін невялікі нюанс - праграма актыўна піша лакальную базу sqlite ад імя таго карыстача, які запускае рэзервовае капіяванне, таму трэба дадаткова сачыць за карэктным указаннем патрэбнай базы пры кожным запуску працэсу выкарыстаючы cli. Пры працы праз GUI ці WEBGUI дэталі будуць утоеныя ад карыстача.
Давайце паглядзім, якія паказчыкі можа выдаць дадзенае рашэнне:
Калі выключыць шыфраванне (прычым WEBGUI рабіць гэтага не рэкамендуе), вынікі такія:
Час працы:
Запуск 1
Запуск 2
Запуск 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
З уключаным шыфраваннем, выкарыстоўваючы aes, атрымліваецца так:
Час працы:
Запуск 1
Запуск 2
Запуск 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
А калі выкарыстоўваць знешнюю праграму gnupg, выходзяць такія вынікі:
Запуск 1
Запуск 2
Запуск 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Як відаць - праграма ўмее працаваць у некалькі патокаў, але ад гэтага не з'яўляецца больш прадукцыйным рашэннем, а калі параўноўваць працу шыфравання - запуск знешняй праграмы
атрымаўся хутчэйшым, чым ужыванне бібліятэкі з набору Mono. Магчыма, гэта звязана з тым, што знешняя праграма больш аптымізавана.
Прыемным момантам таксама стаў той факт, што памер рэпазітара займае роўна столькі, колькі рэальна было змененых дадзеных, г.зн. duplicati выявіў перайменаванне каталога і карэктна апрацаваў дадзеную сітуацыю. Гэта можна ўбачыць пры прагоне другога цеста.
У цэлым, дастаткова станоўчыя ўражанні ад праграмы, уключаючы дастатковую прыязнасць да пачаткоўцаў.
Вынікі
Абодва кандыдаты дастаткова павольна адпрацавалі, але ў цэлым, у параўнанні са звычайным tar, ёсць прагрэс, як мінімум у duplicati. Кошт такога прагрэсу таксама зразумелая - прыкметная нагрузка
працэсара. У цэлым, ніякіх асаблівых адхіленняў пры прагназаванні вынікаў няма.
Высновы
Калі нікуды спяшацца не трэба, а таксама ёсць запас па працэсары - падыдзе любое з разгледжаных рашэнняў, ва ўсякім разе праведзена досыць вялікая праца, якую не варта паўтараць шляхам напісання скрыптоў-акрутак па-над tar. Наяўнасць шыфравання вельмі патрэбная ўласцівасць, калі сервер для захоўвання рэзервовых дзід не можа быць цалкам давераным.
Калі параўноўваць з рашэннямі на аснове - Прадукцыйнасць можа быць горш у некалькі разоў, нягледзячы на тое, што ў чыстым выглядзе tar адпрацаваў хутчэй rsync на 20-30%.
Эканомія на памеры рэпазітара ёсць, але толькі ў duplicati.
анонс
Рэзервовае капіраванне, частка 3: Агляд і тэсціраванне duplicity, duplicati, deja dup
Рэзервовае капіраванне, частка 4: Агляд і тэсціраванне zbackup, restic, borgbackup
Рэзервовае капіраванне, частка 5: Тэставанне bacula і veeam backup for linux
Рэзервовае капіраванне, частка 6: Параўнанне сродкаў рэзервовага капіявання
Рэзервовае капіраванне, частка 7: Высновы
Аўтар публікацыі: Павел Дзямковіч
Крыніца: habr.com