Оваа статија ќе го разгледа софтверот за резервна копија што, со разбивање на протокот на податоци на посебни компоненти (парчиња), формира складиште.
Компонентите на складиштето може дополнително да се компресираат и шифрираат, и што е најважно - за време на повторени процеси на резервна копија - повторно да се користат.
Резервна копија во такво складиште е именуван синџир на компоненти поврзани едни со други, на пример, врз основа на различни хаш функции.
Има неколку слични решенија, ќе се фокусирам на 3: zbackup, borgbackup и restic.
Очекувани резултати
Бидејќи сите апликанти бараат создавање складиште на еден или друг начин, еден од најважните фактори ќе биде да се процени големината на складиштето. Идеално, неговата големина треба да биде не повеќе од 13 GB според прифатената методологија, или уште помалку - предмет на добра оптимизација.
Исто така, многу е пожелно да може директно да се креираат резервни копии на датотеки, без да се користат архиви како tar, како и да се работи со ssh/sftp без дополнителни алатки како rsync и sshfs.
Однесување при креирање резервни копии:
- Големината на складиштето ќе биде еднаква на големината на промените, или помалку.
- Се очекува големо оптоварување на процесорот кога се користи компресија и/или шифрирање, а веројатно е доста големо оптоварување на мрежата и дискот ако процесот на архивирање и/или шифрирање се извршува на резервен сервер за складирање.
- Ако складиштето е оштетено, веројатно е одложена грешка и при креирање на нови резервни копии и кога се обидувате да ги вратите. Неопходно е да се планираат дополнителни мерки за да се обезбеди интегритет на складиштето или да се користат вградени алатки за проверка на неговиот интегритет.
Работата со катран се зема како референтна вредност, како што беше прикажано во една од претходните написи.
Тестирање на zbackup
Општиот механизам на zbackup е дека програмата наоѓа области во протокот на влезни податоци што ги содржат истите податоци, а потоа опционално ги компресира и шифрира, зачувувајќи ја секоја област само еднаш.
Дедупликацијата користи 64-битна хаш-функција за прстен со лизгачки прозорец за да провери дали бајт-по-бајт се совпаѓа со постоечките блокови на податоци (слично на тоа како rsync го имплементира).
Повеќенавојните lzma и lzo се користат за компресија, а aes за шифрирање. Најновите верзии имаат можност да ги бришат старите податоци од складиштето во иднина.
Програмата е напишана во C++ со минимални зависности. Авторот очигледно бил инспириран од unix-way, така што програмата прифаќа податоци за stdin при креирање резервни копии, создавајќи сличен проток на податоци на stdout при обновување. Така, zbackup може да се користи како многу добар „градежен блок“ кога пишувате сопствени резервни решенија. На пример, авторот на статијата ја користи оваа програма како главна алатка за резервна копија за домашните машини од приближно 2014 година.
Протокот на податоци ќе биде обичен катран освен ако не е поинаку наведено.
Ајде да видиме кои се резултатите:
Работата беше проверена во 2 опции:
- се креира складиште и се стартува zbackup на серверот со изворните податоци, а потоа содржината на складиштето се пренесува на серверот за складирање резервни копии.
- се креира складиште на серверот за складирање резервни копии, zbackup се стартува преку ssh на серверот за складирање резервни копии и податоците се испраќаат до него преку цевка.
Резултатите од првата опција беа следни: 43m11s - при користење на нешифрирано складиште и компресорот lzma, 19m13s - при замена на компресорот со lzo.
Оптоварувањето на серверот со оригиналните податоци беше како што следува (прикажан е пример со lzma; со lzo имаше приближно иста слика, но уделот на rsync беше приближно четвртина од времето):
Јасно е дека таков резервен процес е погоден само за релативно ретки и мали промени. Исто така, препорачливо е да се ограничи zbackup на 1 нишка, во спротивно ќе има многу големо оптоварување на процесорот, бидејќи Програмата е многу добра за работа во повеќе нишки. Оптоварувањето на дискот беше мало, што воопшто не би било забележливо со модерен потсистем на диск базиран на ssd. Можете исто така јасно да го видите почетокот на процесот на синхронизирање на податоците од складиштето со оддалечен сервер; брзината на работа е споредлива со редовното rsync и зависи од перформансите на потсистемот на дискот на серверот за складирање резервна копија. Недостаток на овој пристап е складирањето на локално складиште и, како резултат на тоа, дуплирање на податоците.
Поинтересна и поприменлива во пракса е втората опција, вклучување zbackup директно на серверот за складирање резервни копии.
Прво, ќе ја тестираме операцијата без користење на шифрирање со компресорот lzma:
Времетраење на секое тестирање:
Стартување 1
Стартување 2
Стартување 3
39м45с
40м20с
40м3с
7м36с
8м3с
7м48с
15м35с
15м48с
15м38с
Ако овозможите шифрирање користејќи aes, резултатите се доста блиски:
Работно време на истите податоци, со шифрирање:
Стартување 1
Стартување 2
Стартување 3
43м40с
44м12с
44м3с
8м3с
8м15с
8м12с
15м0с
15м40с
15м25с
Ако шифрирањето се комбинира со компресија користејќи lzo, изгледа вака:
Време:
Стартување 1
Стартување 2
Стартување 3
18м2с
18м15с
18м12с
5м13с
5м24с
5м20с
8м48с
9м3с
8м51с
Големината на добиеното складиште беше релативно иста со 13 GB. Ова значи дека дедупликацијата работи правилно. Исто така, на веќе компресирани податоци, користењето lzo дава забележлив ефект; во однос на вкупното време на работа, zbackup се приближува до duplicity/duplicati, но заостанува зад оние базирани на librsync за 2-5 пати.
Предностите се очигледни - заштеда на простор на дискот на серверот за резервна копија. Што се однесува до алатките за проверка на складиштето, авторот на zbackup не ги обезбедува; се препорачува да се користи низа на дискови толерантни за грешки или провајдер на облак.
Севкупно, многу добар впечаток, и покрај фактот што проектот мируваше околу 3 години (последното барање за функција беше пред околу една година, но без одговор).
Тестирање на borgbackup
Borgbackup е вилушка на поткровје, друг систем сличен на zbackup. Напишан во python, има листа на способности слични на zbackup, но дополнително може:
- Монтирајте резервни копии преку осигурувач
- Проверете ја содржината на складиштето
- Работете во режим клиент-сервер
- Користете различни компресори за податоци, како и хеуристичко определување на типот на датотеката при нивното компресирање.
- 2 опции за шифрирање, aes и blake
- Вградена алатка за
проверки на перформансите
borgbackup репер crud ssh://backup_server/repo/path local_dir
Резултатите беа следни:
CZ-BIG 96.51 MB/s (10 100.00 MB датотеки со целосно нула: 10.36 секунди)
RZ-BIG 57.22 MB/s (10 100.00 MB датотеки со целосно нула: 17.48 секунди)
UZ-BIG 253.63 MB/s (10 100.00 MB датотеки со целосно нула: 3.94 секунди)
DZ-BIG 351.06 MB/s (10 100.00 MB датотеки со целосно нула: 2.85 секунди)
CR-BIG 34.30 MB/s (10 100.00 MB случајни датотеки: 29.15 секунди)
RR-BIG 60.69 MB/s (10 100.00 MB случајни датотеки: 16.48 секунди)
UR-BIG 311.06 MB/s (10 100.00 MB случајни датотеки: 3.21 секунди)
DR-BIG 72.63 MB/s (10 100.00 MB случајни датотеки: 13.77 секунди)
CZ-MEDIUM 108.59 MB/s (1000 1.00 MB датотеки со целосно нула: 9.21 секунди)
RZ-MEDIUM 76.16 MB/s (1000 1.00 MB датотеки со целосно нула: 13.13 секунди)
UZ-MEDIUM 331.27 MB/s (1000 1.00 MB датотеки со целосно нула: 3.02 секунди)
DZ-MEDIUM 387.36 MB/s (1000 1.00 MB датотеки со целосно нула: 2.58 секунди)
CR-MEDIUM 37.80 MB/s (1000 1.00 MB случајни датотеки: 26.45 секунди)
RR-MEDIUM 68.90 MB/s (1000 1.00 MB случајни датотеки: 14.51 секунди)
UR-MEDIUM 347.24 MB/s (1000 1.00 MB случајни датотеки: 2.88 секунди)
DR-MEDIUM 48.80 MB/s (1000 1.00 MB случајни датотеки: 20.49 секунди)
CZ-SMALL 11.72 MB/s (10000 10.00 kB датотеки со сите нула: 8.53s)
RZ-SMALL 32.57 MB/s (10000 10.00 kB датотеки со сите нула: 3.07s)
UZ-SMALL 19.37 MB/s (10000 10.00 kB датотеки со сите нула: 5.16s)
DZ-SMALL 33.71 MB/s (10000 10.00 kB датотеки со сите нула: 2.97s)
CR-SMALL 6.85 MB/s (10000 10.00 kB случајни датотеки: 14.60 секунди)
RR-SMALL 31.27 MB/s (10000 10.00 kB случајни датотеки: 3.20 секунди)
UR-SMALL 12.28 MB/s (10000 10.00 kB случајни датотеки: 8.14 секунди)
DR-SMALL 18.78 MB/s (10000 10.00 kB случајни датотеки: 5.32 секунди)
При тестирањето, хеуристиката за компресија ќе се користи за да се одреди типот на датотеката (автоматска компресија), а резултатите ќе бидат како што следува:
Прво, да провериме како работи без шифрирање:
Време:
Стартување 1
Стартување 2
Стартување 3
4м6с
4м10с
4м5с
56s
58s
54s
1м26с
1м34с
1м30с
Ако овозможите овластување за складиштето (автентициран режим), резултатите ќе бидат блиски:
Време:
Стартување 1
Стартување 2
Стартување 3
4м11с
4м20с
4м12с
1м0с
1м3с
1м2с
1м30с
1м34с
1м31с
Кога беше активирана шифрирањето aes, резултатите не се влошија многу:
Стартување 1
Стартување 2
Стартување 3
4м55с
5м2с
4м58с
1м0с
1м2с
1м0с
1м49с
1м50с
1м50с
И ако го промените aes во blake, ситуацијата целосно ќе се подобри:
Време:
Стартување 1
Стартување 2
Стартување 3
4м33с
4м43с
4м40с
59s
1м0с
1м0с
1м38с
1м43с
1м40с
Како и во случајот со zbackup, големината на складиштето беше 13 GB, па дури и малку помалку, што генерално се очекува. Бев многу задоволен од времето на работа; тоа е споредливо со решенија базирани на librsync, обезбедувајќи многу пошироки можности. Бев задоволен и од можноста да се постават различни параметри преку променливите на околината, што дава многу сериозна предност кога се користи borgbackup во автоматски режим. Бев задоволен и од оптоварувањето при резервна копија: судејќи според оптоварувањето на процесорот, borgbackup работи во 1 нишка.
Немаше посебни недостатоци при неговото користење.
рестициско тестирање
И покрај фактот дека рестиц е прилично ново решение (првите 2 кандидати беа познати уште во 2013 година и постари), тој има доста добри карактеристики. Напишано во Go.
Во споредба со zbackup, тој дополнително дава:
- Проверка на интегритетот на складиштето (вклучувајќи проверка на делови).
- Огромна листа на поддржани протоколи и провајдери за складирање резервни копии, како и поддршка за rclone - rsync за решенија во облак.
- Споредување на 2 резервни копии едни со други.
- Монтирање на складиштето преку осигурувач.
Генерално, списокот на функции е доста блиску до borgbackup, на некои места повеќе, на други помалку. Една од карактеристиките е тоа што не постои начин да се оневозможи шифрирањето и затоа резервните копии секогаш ќе бидат шифрирани. Ајде да видиме во пракса што може да се исцеди од овој софтвер:
Резултатите беа следни:
Време:
Стартување 1
Стартување 2
Стартување 3
5м25с
5м50с
5м38с
35s
38s
36s
1м54с
2м2с
1м58с
Резултатите од изведбата се исто така споредливи со решенија базирани на rsync и, генерално, многу блиску до borgbackup, но оптоварувањето на процесорот е поголемо (повеќе нишки работат) и пила.
Најверојатно, програмата е ограничена од перформансите на потсистемот на дискот на серверот за складирање податоци, како што веќе беше случај со rsync. Големината на складиштето беше 13 GB, исто како zbackup или borgbackup, немаше очигледни недостатоци при користење на ова решение.
Наоди
Всушност, сите кандидати постигнаа слични резултати, но по различни цени. Borgbackup беше најдобро од сè, Restic беше малку побавен, zbackup веројатно не вреди да се започне со употреба,
и ако е веќе во употреба, пробај да го смениш во borgbackup или restic.
Наоди
Најперспективно решение се чини дека е остаток, бидејќи ... тој е тој што има најдобар сооднос на способности и брзина на работа, но да не брзаме со општи заклучоци засега.
Borgbackup во основа не е полош, но zbackup е веројатно подобро заменет. Точно, zbackup сè уште може да се користи за да се обезбеди функционирање на правилото 3-2-1. На пример, покрај (lib)rsync-базирани резервни објекти.
Соопштение
Бекап Дел 5: Тестирање на бакула и бекап на veeam за Linux
Резервна копија Дел 6: Споредување на алатките за резервна копија
Бекап Дел 7: Заклучоци
Објавено од: Павел Демкович
Извор: www.habr.com