Тази обзорна бележка продължава , написана по молба на читателите, в нея ще става въпрос за UrBackup, BackupPC и AMANDA.
Преглед на UrBackup.
По молба на участника добавям преглед на UrBackup, клиент-сървърна система за резервно копиране. Тя позволява да се създават пълни и инкрементални резервни копия, може да работи със снимки на устройства (само за Win?), както и да създава файлови резервни копия. Клиентът може да бъде в една мрежа със сървъра или да се свързва през Internet. Обявено е проследяване на промените, което позволява бързо намиране на разлики между резервните копия. Има и поддръжка на дедупликация на данните на страна на сървъра, което позволява икономия на заетото място. Мрежовите връзки са криптирани, има и уеб-интерфейс за управление на сървъра. Нека видим на какво е способна:
В режима на създаване на пълно резервно копие получихме следните резултати:
Време на работа:
Първо стартиране
Второ стартиране
Трето стартиране
Първият тест
8м20с
8м19с
8м24с
Вторият тест
8м30с
8м34с
8м20с
Третият тест
8м10с
8м14с
8м12с
В режима на създаване на инкрементални резервни копия:
Време на работа:
Първо стартиране
Второ стартиране
Трето стартиране
Първият тест
8м10с
8м10с
8м12с
Вторият тест
3м50с
4м12с
3м34с
Третият тест
2м50с
2м35с
2м38с
Размерът на репозитория и в двата случая е около 14 ГБ, което говори за работеща дедупликация на страна на сървъра. Също така е нужно да се отбележи несъответствието между времето за създаване на резервното копие на сървъра и на клиента, което е доста ясно видимо по графиките и е много приятен бонус, тъй като уеб-интерфейсът показва времето за работа на процеса на резервно копиране на страна на сървъра без да се вземе предвид
състоянието на клиента. Като цяло графиките за пълното и инкременталното копие не са различими. Вероятно разликата е само в начина, по който това се обработва на страна на сървъра. Също така приятно изненада с ниското натоварване на процесора на резервираната система.
Преглед на BackupPC
По молба на участника Добавям преглед на BackupPC. Това софтуерно решение се инсталира на сървър за съхранение на резервни копия, написано е на Perl и работи с различни инструменти за резервно копиране — предимно rsync и tar. За транспорт се използват ssh и smb, а също така е наличен уеб интерфейс на базата на cgi (разгръща се върху apache). В уеб интерфейса има обширен списък с настройки. Сред особеностите е възможността да се зададе минимално време между резервните копия, както и период, през който резервните копия няма да се създават. При избора на файловата система за сървъра за резервни копия е необходимо да се обърне внимание на поддръжката на твърди линкове. По този начин, файловата система за хранилището не може да се раздели на точки на монтиране. В общи линии, имам приятно впечатление, нека видим какво може това софтуерно решение:
В режим на създаване на пълни резервни копия с 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
2м50с
2m30s
Третият тест
6m00s
5m35s
5m30s
В общи линии се вижда малко предимство в скоростта на rsync, както и по-икономичното използване на мрежата. Част от това може да бъде компенсирано с по-малкото използване на CPU от tar като програма за резервно копиране. Друго предимство на rsync е работата с инкрементални копия. Размерът на хранилището при създаването на пълни резервни копия е идентичен и е 16 GB, в случай на инкрементални копия — 14 GB за един цикъл, което означава функционираща дедупликация.
Преглед на AMANDA
По молба на участника Добавям тестовете на AMANDA,
Резултатите от тестовия цикъл с tar като архиватор и активиране на компресията са:
Първо стартиране
Второ стартиране
Трето стартиране
Първият тест
9m5s
8m59s
9m6s
Вторият тест
0m5s
0m5s
0m5s
Третият тест
2m40s
2m47s
2m45s
Програмата напълно използва одно ядро на процесора, но заради ограниченото iops на диска на сървъра за съхранение на резервни копия не може да достигне голяма скорост на предаване на данни. Като цяло настройката достави малко повече трудности от останалите участници, тъй като авторът на програмата не използва ssh за транспорт, а реализира сходна схема с ключове, създавайки и поддържайки пълноценна CA. Има възможност широко да се ограничи клиентът и сървърът за резервни копия: например, ако не могат напълно да се доверят един на друг, то може, като вариант, да се забрани инициирането на възстановяване на резервна копия от страна на сървъра, задавайки стойността на съответната променлива на нула в конфигурационния файл. Има възможност за свързване на уеб интерфейс за управление, но, като цяло, настроената система може да се автоматизира напълно с помощта на малки bash скриптове (или SCM, например ansible). Съществува нетривиална система за настройка на хранилището, което явно е свързано с поддръжката на обширен списък от различни устройства за съхранение на данни (каси LTO, твърди дискове и т.н.). Струва си също да се отбележи, че от всички програми, разгледани в тази статия, AMANDA е единствената, която успя да разпознае преименуването на директория. Размерът на репозитория при едно изпълнение беше 13 GB.
Анонс
Резервно копиране, част 6: Сравнение на инструменти за резервно копиране
Резервно копиране, част 7: Изводи
Източник: habr.com
