Оваа статија ќе ги спореди алатките за резервна копија, но прво треба да откриете колку брзо и добро се справуваат со обновувањето на податоците од резервните копии.
За полесно споредба, ќе размислиме за враќање од целосна резервна копија, особено затоа што сите кандидати го поддржуваат овој начин на работа. За едноставност, бројките се веќе просечни (аритметичка средина на неколку вртења). Резултатите ќе бидат сумирани во табела, која исто така ќе содржи информации за можностите: присуство на веб-интерфејс, леснотија на поставување и работа, можност за автоматизирање, присуство на разни дополнителни функции (на пример, проверка на интегритетот на податоците) , итн. Графиконите ќе го покажат оптоварувањето на серверот каде што ќе се користат податоците (не серверот за складирање резервни копии).
Враќање на податоци
rsync и tar ќе се користат како референтна точка бидејќи едноставни скрипти за правење резервни копии.
Rsync се справи со тест-податоците за 4 минути и 28 секунди, покажувајќи
таков товар
Процесот на обновување наиде на ограничување на потсистемот на дискот на серверот за складирање резервни копии (графики со пила). Можете исто така јасно да го видите вчитувањето на едно кернел без никакви проблеми (низок iowait и softirq - нема проблеми со дискот и мрежата, соодветно). Бидејќи другите две програми, имено rdiff-backup и rsnapshot, се засноваат на rsync и исто така нудат редовно rsync како алатка за обновување, тие ќе имаат приближно ист профил на оптоварување и време за враќање на резервната копија.
Tar го направи тоа малку побрзо
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 секунди:
Но, во режимот за пренос на податоци, BackupPC се справуваше со катран побавно: за 12 минути и 15 секунди, оптоварувањето на процесорот беше генерално помало
еден и пол пати:
Двојност без шифрирање покажа малку подобри резултати, враќајќи резервна копија за 10 минути и 58 секунди. Ако активирате шифрирање користејќи gpg, времето за обновување се зголемува на 15 минути и 3 секунди. Исто така, кога креирате складиште за складирање копии, можете да ја одредите големината на архивата што ќе се користи при разделување на дојдовниот поток на податоци. Во принцип, на конвенционалните хард дискови, исто така поради режимот на работа со една нишка, нема многу разлика. Може да се појави во различни големини на блокови кога се користи хибридно складирање. Оптоварувањето на главниот сервер за време на обновувањето беше како што следува:
без шифрирање
со шифрирање
Дупликат покажа споредлива стапка на закрепнување, завршувајќи ја за 13 минути и 45 секунди. Беа потребни околу уште 5 минути за да се провери точноста на обновените податоци (вкупно околу 19 минути). Товарот беше
доста високо:
Кога шифрирањето aes беше овозможено внатрешно, времето за обновување беше 21 минута 40 секунди, со максимално искористување на процесорот (и двете јадра!) за време на обновувањето; При проверка на податоците, само една нишка беше активна, која зафаќаше едно процесорско јадро. Проверката на податоците по обновувањето траеше истите 5 минути (вкупно скоро 27 минути).
Резултира
duplicati беше малку побрз со обновувањето при користење на надворешната gpg програма за шифрирање, но генерално разликите од претходниот режим се минимални. Времето на работа беше 16 минути 30 секунди, со проверка на податоците за 6 минути. Товарот беше
такви:
AMANDA, користејќи катран, го заврши за 2 минути 49 секунди, што, во принцип, е многу блиску до обичниот катран. Оптоварување на системот во принцип
исто:
Кога обновувате резервна копија користејќи zbackup добиени се следните резултати:
шифрирање, lzma компресија
Времетраење 11 минути и 8 секунди
AES шифрирање, lzma компресија
Работно време 14 минути
AES шифрирање, lzo компресија
Времетраење 6 минути, 19 секунди
Генерално, не е лошо. Сè зависи од брзината на процесорот на резервниот сервер, што може јасно да се види од времето на работа на програмата со различни компресори. На страната на резервниот сервер беше лансиран обичен катран, па ако го споредите со него, обновувањето е 3 пати побавно. Можеби вреди да се провери операцијата во режим со повеќе нишки, со повеќе од две нишки.
BorgBackup во нешифриран режим беше малку побавно од катран, за 2 минути 45 секунди, сепак, за разлика од катран, стана возможно да се дедупликира складиштето. Товарот се покажа дека е
следното:
Ако овозможите шифрирање базирано на blake, брзината на враќање на резервната копија е малку побавна. Времето за обновување во овој режим е 3 минути 19 секунди, а товарот исчезна
како ова:
Шифрирањето AES е малку побавно, времето за обновување е 3 минути 23 секунди, оптоварувањето е особено
не е променето:
Бидејќи Borg може да работи во режим со повеќе нишки, оптоварувањето на процесорот е максимално, а кога се активираат дополнителни функции, времето на работа едноставно се зголемува. Очигледно, вреди да се истражува повеќенишките на сличен начин како zbackup.
Рестик се справи со обновувањето малку побавно, времето на работа беше 4 минути 28 секунди. Товарот изгледаше како
така:
Очигледно, процесот на обновување работи во неколку нишки, но ефикасноста не е толку висока како онаа на BorgBackup, но споредлива во време со редовното rsync.
Со urBackup Беше можно да се вратат податоците за 8 минути и 19 секунди, оптоварувањето беше
такви:
Товарот сè уште не е многу висок, дури и помал од оној на катран. На некои места има пукнатини, но не повеќе од оптоварувањето на едно јадро.
Избор и оправдување на критериуми за споредба
Како што е наведено во една од претходните написи, системот за резервна копија мора да ги исполнува следниве критериуми:
- Леснотија на користење
- разноврсност
- Стабилност
- Брзина
Вреди да се разгледа секоја точка одделно подетално.
Леснотија на работа
Најдобро е кога има едно копче „Направи сè добро“, но ако се вратите на вистинските програми, најзгодно ќе биде некој познат и стандарден принцип на работа.
На повеќето корисници најверојатно ќе им биде подобро ако не мора да запомнат еден куп клучеви за cli, да конфигурираат куп различни, често нејасни опции преку веб или tui, или да поставуваат известувања за неуспешна операција. Ова ја вклучува и можноста за лесно „вклопување“ на резервното решение во постоечката инфраструктура, како и автоматизација на процесот на резервна копија. Исто така, постои можност за инсталација со помош на менаџер на пакети, или во една или две команди како „преземи и отпакувај“. curl ссылка | sudo bash - комплексен метод, бидејќи треба да проверите што пристигнува преку врската.
На пример, од разгледуваните кандидати, едноставно решение е burp, rdiff-backup и restic, кои имаат мнемонички копчиња за различни режими на работа. Малку посложени се боргот и дволичноста. Најтешка беше АМАНДА. Останатите се некаде на средина во однос на леснотијата на користење. Во секој случај, ако ви требаат повеќе од 30 секунди за да го прочитате упатството за употреба, или треба да отидете на Google или друг пребарувач, а исто така да скролувате низ долг лист со помош, одлуката е тешка, на овој или оној начин.
Некои од разгледуваните кандидати можат автоматски да испратат порака преку e-mailjabber, додека други се потпираат на конфигурирани предупредувања во системот. Покрај тоа, најчесто сложените решенија немаат сосема очигледни поставки за предупредување. Во секој случај, ако резервната програма произведе шифра за враќање без нула, која ќе биде правилно разбрана од системската услуга за периодични задачи (ќе биде испратена порака до администраторот на системот или директно до следење) - ситуацијата е едноставна. Но, ако системот за резервна копија, кој не работи на резервен сервер, не може да се конфигурира, очигледниот начин да се каже за проблемот е дека сложеноста е веќе прекумерна. Во секој случај, издавањето предупредувања и други пораки само на веб-интерфејсот или на дневникот е лоша практика, бидејќи најчесто тие ќе бидат игнорирани.
Што се однесува до автоматизацијата, едноставна програма може да чита променливи на околината што го поставуваат нејзиниот режим на работа, или има развиено клип што може целосно да го дуплира однесувањето кога работи преку веб-интерфејс, на пример. Ова исто така вклучува можност за континуирано работење, достапност на можности за проширување итн.
разноврсност
Делумно повторувајќи го претходниот потсекција во врска со автоматизацијата, не треба да биде посебен проблем да се „вклопи“ процесот на резервна копија во постоечката инфраструктура.
Вреди да се напомене дека употребата на нестандардни порти (добро, освен веб-интерфејсот) за работа, имплементацијата на шифрирање на нестандарден начин, размената на податоци со помош на нестандарден протокол се знаци на не -универзално решение. Во најголем дел, сите кандидати ги имаат на еден или друг начин од очигледна причина: едноставноста и разновидноста обично не одат заедно. По исклучок - подригни, има и други.
Како знак - способност за работа со користење на редовни ssh.
Брзина на работа
Најконтроверзна и најконтроверзна точка. Од една страна, го започнавме процесот, тој работеше што е можно побрзо и не ги попречуваше главните задачи. Од друга страна, има наплив на сообраќај и оптоварување на процесорот за време на периодот на резервна копија. Исто така, вреди да се напомене дека најбрзите програми за правење копии обично се најсиромашни во однос на функциите што се важни за корисниците. Повторно: ако за да добиете една несреќна текстуална датотека со големина од неколку десетици бајти со лозинка, и поради тоа чини целата услуга (да, да, разбирам дека процесот на резервна копија најчесто не е виновен овде), и треба последователно да ги читате сите датотеки во складиштето или да ја проширите целата архива - системот за резервна копија никогаш не е брз. Друга точка што често станува камен на сопнување е брзината на распоредување на резервна копија од архива. Овде има јасна предност за оние кои едноставно можат да ги копираат или преместуваат датотеките на саканата локација без многу манипулации (рсинк, на пример), но најчесто проблемот мора да се реши на организациски начин, емпириски: со мерење на времето за враќање на резервната копија и отворено информирање на корисниците за ова.
Стабилност
Треба да се разбере вака: од една страна, мора да биде можно да се распореди резервната копија назад на кој било начин, од друга страна, таа мора да биде отпорна на разни проблеми: прекин на мрежата, дефект на дискот, бришење на дел од складиште.
Споредба на алатки за резервна копија
Време на создавање копии
Копирај го времето за обновување
Лесна инсталација
Лесно поставување
Едноставна употреба
Едноставна автоматизација
Дали ви треба клиент-сервер?
Проверка на интегритетот на складиштето
Диференцијални копии
Работа преку цевка
разноврсност
Независност
Транспарентност на складиштето
Шифрирање
Компресија
Дедупликација
Веб интерфејс
Пополнување до облакот
Windows поддршка
Резултат
Rsync
4м15с
4м28с
Да
Нема
Нема
Нема
Да
Нема
Нема
Да
Нема
Да
Да
Нема
Нема
Нема
Нема
Нема
Да
6
Tar
чиста
3м12с
2м43с
Да
Нема
Нема
Нема
Нема
Нема
Да
Да
Нема
Да
Нема
Нема
Нема
Нема
Нема
Нема
Да
8,5
gzip
9м37с
3м19с
Да
Rdiff-резервна копија
16м26с
17м17с
Да
Да
Да
Да
Да
Нема
Да
Нема
Да
Нема
Да
Нема
Да
Да
Да
Нема
Да
11
Rsnapshot
4м19с
4м28с
Да
Да
Да
Да
Нема
Нема
Да
Нема
Да
Нема
Да
Нема
Нема
Да
Да
Нема
Да
12,5
Бурпа
11м9с
7м2с
Да
Нема
Да
Да
Да
Да
Да
Нема
Да
Да
Нема
Нема
Да
Нема
Да
Нема
Да
10,5
Двојност
без шифрирање
16м48с
10м58с
Да
Да
Нема
Да
Нема
Да
Да
Нема
Нема
Да
Нема
Да
Да
Нема
Да
Нема
Да
11
gpg
17м27с
15м3с
Дупликат
без шифрирање
20м28с
13м45с
Нема
Да
Нема
Нема
Нема
Да
Да
Нема
Нема
Да
Нема
Да
Да
Да
Да
Да
Да
11
аес
29м41с
21м40с
gpg
26м19с
16м30с
Резервна копија
без шифрирање
40м3с
11м8с
Да
Да
Нема
Нема
Нема
Да
Да
Да
Нема
Да
Нема
Да
Да
Да
Нема
Нема
Нема
10
аес
42м0с
14м1с
аес+лзо
18м9с
6м19с
BorgBackup
без шифрирање
4м7с
2м45с
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Нема
Да
Да
Да
Да
Нема
Да
16
аес
4м58с
3м23с
blake2
4м39с
3м19с
Рестик
5м38с
4м28с
Да
Да
Да
Да
Нема
Да
Да
Да
Да
Да
Нема
Да
Нема
Да
Нема
Да
Да
15,5
urBackup
8м21с
8м19с
Да
Да
Да
Нема
Да
Нема
Да
Нема
Да
Да
Нема
Да
Да
Да
Да
Нема
Да
12
Amanda
9м3с
2м49с
Да
Нема
Нема
Да
Да
Да
Да
Нема
Да
Да
Да
Да
Да
Нема
Да
Да
Да
13
Резервна копија
rsync
12м22с
7м42с
Да
Нема
Да
Да
Да
Да
Да
Нема
Да
Нема
Нема
Да
Да
Нема
Да
Нема
Да
10,5
катран
12м34с
12м15с
Легенда на табелата:
- Зелено, време на работа помалку од пет минути или одговорете „Да“ (освен за колоната „Ви треба клиентски сервер?“), 1 поен
- Жолта, време на работа пет до десет минути, 0.5 поени
- Црвено, работното време е повеќе од десет минути или одговорот е „Не“ (освен колоната „Дали ви треба клиент-сервер?“), 0 поени
Според табелата погоре, наједноставната, најбрзата и во исто време удобна и моќна алатка за резервна копија е BorgBackup. Рестиќ го зазеде второто место, останатите разгледувани кандидати беа приближно подеднакво пласирани со распон од еден или два поени на крајот.
Им благодарам на сите што ја прочитаа серијата до крај, ве повикувам да разговарате за опциите и да понудите своја, доколку ги има. Како што напредува дискусијата, табелата може да се прошири.
Резултатот од серијата ќе биде последниот напис, во кој ќе се направи обид да се развие идеална, брза и управувана алатка за резервна копија која ви овозможува да распоредите копија назад во најкус можен рок и во исто време да биде погодна и лесна. за конфигурирање и одржување.
Соопштение
Резервна копија Дел 6: Споредување на алатките за резервна копија
Бекап Дел 7: Заклучоци
Извор: www.habr.com