Дадзеная аглядная нататка працягвае , напісана па просьбе чытачоў, у ёй гаворка пойдзе пра UrBackup, BackupPC, а таксама AMANDA.
Агляд UrBackup.
Па просьбе ўдзельніка дадаю агляд UrBackup, кліент-сервернай сістэмы для рэзервовага капіявання. Яна дазваляе ствараць поўныя і інкрыментальныя рэзервовыя копіі, умее працаваць са здымкамі прылад (Win only?), а таксама ўмее ствараць файлавыя рэзервовыя копіі. Кліент можа знаходзіцца як у адной сетцы з серверам, так і падлучацца праз Internet. Заяўлена адсочванне змен, што дазваляе хутка знайсці адрозненні паміж рэзервовымі копіямі. Таксама маецца падтрымка дэдуплікацыі захоўвання дадзеных на баку сервера, што дазваляе эканоміць займанае месца. Сеткавыя злучэнні шыфруюцца, таксама маецца web-інтэрфейс для кіравання серверам. Давайце паглядзім, на што яна здольная:
У рэжыме стварэння поўнай рэзервовай копіі атрымаліся наступныя вынікі:
Час працы:
першы запуск
Другі запуск
Трэці запуск
Першы тэст
8m20s
8m19s
8m24s
Другі тэст
8m30s
8m34s
8m20s
Трэці тэст
8m10s
8m14s
8m12s
У рэжыме стварэння інкрыментальных рэзервовых копій:
Час працы:
першы запуск
Другі запуск
Трэці запуск
Першы тэст
8m10s
8m10s
8m12s
Другі тэст
3m50s
4m12s
3m34s
Трэці тэст
2m50s
2m35s
2m38s
Памер рэпазітара ў абодвух выпадках склаў прыкладна 14 гігабайт, што кажа аб якая працуе дэдуплікацыі на баку сервера. Таксама варта адзначыць неадпаведнасць часу стварэння рэзервовай копіі на серверы і на кліенце, што дастаткова выразна відаць па графіках і з'яўляецца вельмі прыемным бонусам, паколькі web-інтэрфейс паказвае час працы працэсу рэзервовага капіявання на баку сервера без уліку
стану кліента. У цэлым графікі для поўнай і інкрыментальнай копіі неадрозныя. Верагодна, адрозненне толькі ў тым, як гэта апрацоўваецца на баку сервера. Таксама парадавала нізкая загрузка працэсара на рэзервуемай сістэме.
Агляд BackupPC
Па просьбе ўдзельніка дадаю агляд BackupPC. Дадзенае ПА усталёўваецца на сервер захоўвання рэзервовых дзід, напісана на perl, працуе па-над рознымі сродкамі рэзервовага капіявання — у першую чаргу rsync, tar. У якасці транспарта выкарыстоўваецца ssh і smb, таксама ў наяўнасці ёсць web-інтэрфейс на аснове cgi (разгортваецца па-над apache). У web-інтэрфейсе ёсць шырокі спіс налад. З асаблівасцяў - наяўнасць магчымасці задання мінімальнага часу паміж рэзервовымі копіямі, а таксама перыяду, на працягу якога рэзервовыя копіі не будуць стварацца. Пры выбары файлавай сістэмы для сервера рэзервовага капіявання трэба сачыць за падтрымкай цвёрдых спасылак. Такім чынам, файлавую сістэму для сховішча не разаб'еш на кропкі мантавання. У цэлым, досыць прыемнае ўражанне, давайце паглядзім, на што здольна гэтае ПЗ:
У рэжыме стварэння поўных рэзервовых дзід з rsync атрымаліся такія вынікі:
першы запуск
Другі запуск
Трэці запуск
Першы тэст
12m25s
12m14s
12m27s
Другі тэст
7m41s
7m44s
7m35s
Трэці тэст
10m11s
10m0s
9m54s
Калі ж выкарыстоўваць поўныя рэзервовыя копіі і tar:
першы запуск
Другі запуск
Трэці запуск
Першы тэст
12m41s
12m25s
12m45s
Другі тэст
12m35s
12m45s
12m14s
Трэці тэст
12m43s
12m25s
12m5s
У рэжыме стварэння інкрыментальных рэзервовых копій прыйшлося адмовіцца ад tar, паколькі пры такіх наладах рэзервовыя копіі не ствараліся.
Вынікі стварэння інкрыментальных рэзервовых копій з выкарыстаннем rsync наступныя:
першы запуск
Другі запуск
Трэці запуск
Першы тэст
11m55s
11m50s
12m25s
Другі тэст
2m42s
2m50s
2m30s
Трэці тэст
6m00s
5m35s
5m30s
У цэлым відаць невялікая перавага па хуткасці ў rsync, таксама rsync эканомней працуе з сеткай. Збольшага гэта можа быць скампенсаванае меншым выкарыстаннем cpu з tar у якасці праграмы для стварэння рэзервовых копій. Іншай перавагай rsync з'яўляецца праца з інкрыментальнымі копіямі. Памер рэпазітара пры стварэнні поўных рэзервовых копій аднолькавы, складае 16 гб, у выпадку інкрыментальных копій - 14 гб за адзін прагон, што азначае працуючую дэдуплікацыю.
Агляд AMANDA
Па просьбе ўдзельніка дадаю тэсты AMANDA,
Вынікі тэставага прагону з tar у якасці архіватара і актывацыяй сціску такія:
першы запуск
Другі запуск
Трэці запуск
Першы тэст
9m5s
8m59s
9m6s
Другі тэст
0m5s
0m5s
0m5s
Трэці тэст
2m40s
2m47s
2m45s
Праграма цалкам загружае адно працэсарнае ядро, але з-за абмежаванага па iops дыска на баку сервера захоўвання рэзервовых копій не можа развіць вялікую хуткасць перадачы даных. У цэлым, налада даставіла крыху больш клопатаў, чым у астатніх удзельнікаў, паколькі аўтар праграмы не выкарыстоўвае ў якасці транспарту ssh, а рэалізуе падобную схему з ключамі, ствараючы і падтрымліваючы паўнавартасную CA. Ёсць магчымасць шырока абмежаваць кліента і сервер рэзервовага капіявання: напрыклад, калі яны не могуць цалкам давяраць адзін аднаму, то можна, як варыянт, забараніць ініцыяванне ўзнаўлення рэзервовай копіі са боку сервера, задаючы значэнне якая адпавядае зменнай у нуль у файле налад. Ёсць магчымасць падлучыць web-інтэрфейс для кіравання, але ў цэлым наладжаную сістэму можна аўтаматызаваць цалкам з дапамогай невялікіх скрыптоў на bash (ці SCM, да прыкладу ansible). Існуе некалькі нетрывіяльная сістэма налады сховішча, што, па ўсёй бачнасці, злучана з падтрымкай шырокага спісу розных прылад для захоўвання дадзеных (касеты LTO, цвёрдыя кружэлкі і да т.п.). Таксама варта адзначыць, што з усіх праграм, разгледжаных у гэтым артыкуле, AMANDA – адзіная, якая здолела выявіць перайменаванне каталога. Памер рэпазітара пры адным прагоне склаў 13 гб.
анонс
Рэзервовае капіраванне, частка 6: Параўнанне сродкаў рэзервовага капіявання
Рэзервовае капіраванне, частка 7: Высновы
Крыніца: habr.com