Оваа белешка дискутира за алатките за резервна копија кои вршат резервни копии со создавање архиви на резервен сервер.
Меѓу оние кои ги исполнуваат барањата се двојството (кој има убав интерфејс во форма на дежа дуп) и дупликати.
Друга многу извонредна алатка за резервна копија е dar, но бидејќи има многу обемна листа на опции - методологијата за тестирање покрива едвај 10% од она за што е способна - не ја тестираме како дел од тековниот циклус.
Очекувани резултати
Бидејќи и двајцата кандидати создаваат архиви на еден или друг начин, обичниот катран може да се користи како водич.
Дополнително, ќе процениме колку добро е оптимизирано складирањето податоци на серверот за складирање со создавање резервни копии кои ја содржат само разликата помеѓу целосната копија и моменталната состојба на датотеките, или помеѓу претходната и тековната архива (инкрементална, намалена, итн.) .
Однесување при креирање резервни копии:
- Релативно мал број на датотеки на серверот за складирање резервни копии (споредлив со бројот на резервни копии или големината на податоците во GB), но нивната големина е прилично голема (десетици до стотици мегабајти).
- Големината на складиштето ќе вклучува само промени - нема да се складираат дупликати, така што големината на складиштето ќе биде помала отколку со софтверот базиран на 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 во цевка. За референца ќе има команда како оваа:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Резултатите излегоа вака:
Времето на извршување се покажа дека е 10 m30s, бидејќи 2 процеси работеа на страната на примачот - тесното грло е повторно компресор со една нишка, плус мала шифра за шифрирање.
UPD: На барање на bliznezz додавам тестови со пигз. Ако го користите само компресорот, ќе ви требаат 6m30s, ако додадете и шифрирање, тоа ќе биде околу 7m. Падот во долниот графикон е неисчистен кеш на дискот:
Двојно тестирање
Duplicity е python софтвер за резервна копија преку создавање шифрирани архиви во формат 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 GB), но јасно е можноста да се користи недоверлив сервер за резервна копија го опфаќа ова однесување.
Двојно тестирање
Овој софтвер е напишан во C# и работи со помош на збир на библиотеки од Mono. Постои GUI, како и верзија CLI.
Приближната листа на главните карактеристики е слична на двојството, вклучувајќи различни даватели на резервни копии, меѓутоа, за разлика од двојството, повеќето функции се достапни без алатки од трети страни. Дали ова е плус или минус зависи од конкретниот случај, но за почетниците, најверојатно е полесно да имаат список со сите функции одеднаш пред нив, наместо дополнително да инсталираат пакети за python, како што е случајот со дволичност.
Друга мала нијанса - програмата активно пишува локална база на податоци sqlite во име на корисникот кој ја започнува резервната копија, така што треба дополнително да се осигурате дека потребната база на податоци е правилно наведена секој пат кога процесот ќе започне со користење на клипот. Кога работите преку 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 откри преименување на директориумот и правилно се справи со оваа ситуација. Ова може да се види при извршување на вториот тест.
Севкупно, прилично позитивни впечатоци од програмата, вклучително и прилично пријателски однос кон почетниците.
Наоди
И двајцата кандидати работеа прилично бавно, но генерално, во споредба со обичниот катран, има напредок, барем со дупликати. Цената на таквиот напредок е исто така јасна - забележлив товар
процесор. Во принцип, нема посебни отстапувања во предвидувањето на резултатите.
Наоди
Ако не треба никаде да брзате, а исто така имате резервен процесор, секое од разгледаните решенија ќе направи, во секој случај, направена е доста работа што не треба да се повторува со пишување скрипти за обвивка над катран. . Присуството на шифрирање е многу неопходна особина доколку на серверот за складирање резервни копии не може целосно да му се верува.
Во споредба со решенија базирани - перформансите може да бидат неколку пати полоши, и покрај фактот што во својата чиста форма катранот работеше 20-30% побрзо од rsync.
Има заштеда на големината на складиштето, но само со дупликати.
Соопштение
Резервна копија Дел 3: Преглед и тестирање на двојноста, дупликати, деја дуп
Бекап Дел 4: Преглед и тестирање на zbackup, restic, borgbackup
Бекап Дел 5: Тестирање на бакула и бекап на veeam за Linux
Резервна копија Дел 6: Споредување на алатките за резервна копија
Бекап Дел 7: Заклучоци
Објавено од: Павел Демкович
Извор: www.habr.com