Бұл мақалада деректер ағынын бөлек құрамдастарға (бөлшектерге) бөлу арқылы репозиторийді құрайтын сақтық көшірме бағдарламалық құралы қарастырылады.
Репозиторий құрамдастарын одан әрі қысуға және шифрлауға, ең бастысы – қайталанатын сақтық көшірме процестері кезінде – қайта пайдалануға болады.
Мұндай репозиторийдегі сақтық көшірме - бұл әртүрлі хэш-функцияларға негізделген, мысалы, бір-бірімен қосылған құрамдастардың аталған тізбегі.
Бірнеше ұқсас шешімдер бар, мен 3-ке тоқталамын: zbackup, borgbackup және restic.
Күтілетін нәтижелер
Барлық өтініш берушілер сол немесе басқа жолмен репозиторий құруды талап ететіндіктен, репозиторийдің көлемін бағалау маңызды факторлардың бірі болады. Ең дұрысы, оның өлшемі қабылданған әдістемеге сәйкес 13 ГБ-тан аспауы керек немесе жақсы оңтайландыру жағдайында одан да аз болуы керек.
Сондай-ақ tar сияқты мұрағатшыларды қолданбай, файлдардың сақтық көшірмелерін тікелей жасай алу, сондай-ақ rsync және sshfs сияқты қосымша құралдарсыз ssh/sftp-мен жұмыс істеу өте қажет.
Сақтық көшірмелерді жасау кезіндегі әрекет:
- Репозиторийдің өлшемі өзгерістер өлшеміне тең немесе одан аз болады.
- Сығымдау және/немесе шифрлауды пайдалану кезінде процессордың ауыр жүктемесі күтіледі, ал егер мұрағаттау және/немесе шифрлау процесі сақтық көшірме сақтау серверінде орындалса, желі мен дискіге айтарлықтай жоғары жүктеме болуы мүмкін.
- Репозиторий зақымдалған болса, жаңа сақтық көшірмелерді жасау кезінде де, қалпына келтіру әрекеті кезінде де кешіктірілген қате болуы мүмкін. Репозиторийдің тұтастығын қамтамасыз ету үшін қосымша шараларды жоспарлау немесе оның тұтастығын тексеру үшін кіріктірілген құралдарды пайдалану қажет.
Гудронмен жұмыс алдыңғы мақалалардың бірінде көрсетілгендей анықтамалық мән ретінде алынады.
zbackup тексерілуде
Zbackup бағдарламасының жалпы механизмі мынада: бағдарлама кіріс деректер ағынында бірдей деректерді қамтитын аумақтарды табады, содан кейін оларды міндетті түрде қысады және шифрлайды, әрбір аймақты тек бір рет сақтайды.
Дерексіздендіру бар деректер блоктарымен байт-байт сәйкестіктерін тексеру үшін сырғымалы терезесі бар 64-биттік сақина хэш функциясын пайдаланады (rsync оны іске асыру әдісіне ұқсас).
Көп ағынды lzma және lzo қысу үшін, ал aes шифрлау үшін қолданылады. Соңғы нұсқаларда болашақта репозиторийден ескі деректерді жою мүмкіндігі бар.
Бағдарлама C++ тілінде ең аз тәуелділіктермен жазылған. Авторды unix-way шабыттандырған сияқты, сондықтан бағдарлама сақтық көшірмелерді жасау кезінде stdin деректерін қабылдайды, қалпына келтіру кезінде stdout-та ұқсас деректер ағынын жасайды. Осылайша, zbackup өзіңіздің сақтық көшірме шешімдеріңізді жазу кезінде өте жақсы «құрылыс блогы» ретінде пайдаланылуы мүмкін. Мысалы, мақала авторы бұл бағдарламаны шамамен 2014 жылдан бастап үй машиналарының негізгі резервтік құралы ретінде пайдаланды.
Егер басқаша көрсетілмесе, деректер ағыны кәдімгі тар болады.
Нәтижелер қандай екенін көрейік:
Жұмыс 2 нұсқада тексерілді:
- репозиторий жасалады және бастапқы деректермен серверде zbackup іске қосылады, содан кейін репозиторийдің мазмұны сақтық көшірме сақтау серверіне тасымалданады.
- резервтік көшірме сақтау серверінде репозиторий жасалады, zbackup сақтық көшірме сақтау серверінде ssh арқылы іске қосылады және деректер оған құбыр арқылы жіберіледі.
Бірінші нұсқаның нәтижелері келесідей болды: 43м11с - шифрланбаған репозиторий мен lzma компрессорын пайдаланған кезде, 19м13с - компрессорды 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 ГБ кезінде салыстырмалы түрде бірдей болды. Бұл деупликация дұрыс жұмыс істеп тұрғанын білдіреді. Сондай-ақ, қазірдің өзінде қысылған деректерде lzo пайдалану айтарлықтай нәтиже береді; жалпы жұмыс уақыты бойынша zbackup қайталанатын/қайталанатынына жақын келеді, бірақ 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 МБ/с (10 100.00 МБ барлық нөлдік файлдар: 10.36 с)
RZ-BIG 57.22 МБ/с (10 100.00 МБ барлық нөлдік файлдар: 17.48 с)
UZ-BIG 253.63 МБ/с (10 100.00 МБ барлық нөлдік файлдар: 3.94 с)
DZ-BIG 351.06 МБ/с (10 100.00 МБ барлық нөлдік файлдар: 2.85 с)
CR-BIG 34.30 МБ/с (10 100.00 МБ кездейсоқ файлдар: 29.15 с)
RR-BIG 60.69 МБ/с (10 100.00 МБ кездейсоқ файлдар: 16.48 с)
UR-BIG 311.06 МБ/с (10 100.00 МБ кездейсоқ файлдар: 3.21 с)
DR-BIG 72.63 МБ/с (10 100.00 МБ кездейсоқ файлдар: 13.77 с)
CZ-ORTA 108.59 МБ/с (1000 1.00 МБ барлық нөлдік файлдар: 9.21 с)
RZ-ORTA 76.16 МБ/с (1000 1.00 МБ барлық нөлдік файлдар: 13.13 с)
UZ-MEDIUM 331.27 МБ/с (1000 1.00 МБ барлық нөлдік файлдар: 3.02 с)
DZ-MEDIUM 387.36 МБ/с (1000 1.00 МБ барлық нөлдік файлдар: 2.58 с)
CR-ORTA 37.80 МБ/с (1000 1.00 МБ кездейсоқ файлдар: 26.45 с)
RR-ОРТА 68.90 МБ/с (1000 1.00 МБ кездейсоқ файлдар: 14.51 с)
UR-ORTA 347.24 МБ/с (1000 1.00 МБ кездейсоқ файлдар: 2.88 с)
DR-MEDIUM 48.80 МБ/с (1000 1.00 МБ кездейсоқ файлдар: 20.49 с)
CZ-SMALL 11.72 МБ/с (10000 10.00 кБ барлық нөлдік файлдар: 8.53 с)
RZ-SMALL 32.57 МБ/с (10000 10.00 кБ барлық нөлдік файлдар: 3.07 с)
UZ-SMALL 19.37 МБ/с (10000 10.00 кБ барлық нөлдік файлдар: 5.16 с)
DZ-SMALL 33.71 МБ/с (10000 10.00 кБ барлық нөлдік файлдар: 2.97 с)
CR-SMALL 6.85 МБ/с (10000 10.00 кБ кездейсоқ файлдар: 14.60 с)
RR-SMALL 31.27 МБ/с (10000 10.00 кБ кездейсоқ файлдар: 3.20 с)
UR-SMALL 12.28 МБ/с (10000 10.00 кБ кездейсоқ файлдар: 8.14 с)
DR-SMALL 18.78 МБ/с (10000 10.00 кБ кездейсоқ файлдар: 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-ті Блейкке ауыстырсаңыз, жағдай толығымен жақсарады:
Жұмыс уақыты:
Іске қосу 1
Іске қосу 2
Іске қосу 3
4м33с
4м43с
4м40с
59s
1м0с
1м0с
1м38с
1м43с
1м40с
Zbackup жағдайындағыдай, репозиторий өлшемі 13 ГБ және одан да аз болды, бұл әдетте күтіледі. Мен жұмыс уақытына өте риза болдым; ол әлдеқайда кең мүмкіндіктерді қамтамасыз ететін librsync негізіндегі шешімдермен салыстыруға болады. Сондай-ақ, мен автоматты режимде borgbackup пайдалану кезінде өте маңызды артықшылық беретін орта айнымалылары арқылы әртүрлі параметрлерді орнату мүмкіндігіне риза болдым. Мен сақтық көшірме жасау кезіндегі жүктемеге де риза болдым: процессордың жүктемесіне қарағанда, borgbackup 1 ағында жұмыс істейді.
Оны пайдалану кезінде ерекше кемшіліктер болған жоқ.
тынығу сынағы
Restic - бұл өте жаңа шешім болғанына қарамастан (алғашқы 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 ГБ болды, zbackup немесе borgbackup сияқты, бұл шешімді пайдалану кезінде ешқандай айқын кемшіліктер болған жоқ.
нәтижелері
Іс жүзінде барлық үміткерлер ұқсас нәтижелерге қол жеткізді, бірақ әртүрлі бағамен. Borgbackup ең жақсы орындады, рестик сәл баяу болды, zbackup пайдалануды бастауға тұрарлық емес шығар,
және ол әлдеқашан қолданыста болса, оны borgbackup немесе restic деп өзгертіп көріңіз.
қорытындылар
Ең перспективті шешім тыныштық сияқты көрінеді, өйткені... ол мүмкіндіктердің жұмыс жылдамдығына ең жақсы қатынасына ие, бірақ қазір жалпы қорытындыға асықпайық.
Borgbackup негізінен жаман емес, бірақ zbackup ауыстырылғаны жақсы. Рас, zbackup әлі де 3-2-1 ережесінің жұмыс істеуін қамтамасыз ету үшін пайдаланылуы мүмкін. Мысалы, (lib)rsync негізіндегі сақтық көшірме құралдарына қосымша.
Хабарландыру
Сақтық көшірме 5-бөлім: Linux үшін bacula және veeam сақтық көшірмесін сынау
Сақтық көшірме 6-бөлім: Сақтық көшірме құралдарын салыстыру
Сақтық көшірме 7-бөлім: Қорытынды
Жариялаған: Павел Демкович
Ақпарат көзі: www.habr.com