Тази обзорна бележка продължава , написана по молба на читателите, в нея ще стане дума за UrBackup, BackupPC, както и AMANDA.
Обзор на UrBackup.
По молба на участника добавям обзор на UrBackup, клиент-серверната система за резервно копиране. Тя позволява да се правят пълни и инкрементни резервни копия, умее да работи със снимки на устройства (само за Win?), а също така създава файлови резервни копия. Клиентът може да бъде в една мрежа със сървера или да се свързва през интернет. Заявено е проследяване на изменения, което позволява бързо намиране на разлики между резервните копия. Също така има поддръжка на дедупликация на данните на страната на сървера, което спестява заетото място. Мрежовите връзки са криптирани, има и уеб интерфейс за управление на сървера. Нека видим на какво е способна:
В режим на създаване на пълно резервно копие получихме следните резултати:
Време на работа:
Първо стартиране
Второ стартиране
Трето стартиране
Първи тест
8m20s
8m19s
8m24s
Втори тест
8m30s
8m34s
8m20s
Трети тест
8m10s
8m14s
8m12s
В режим на създаване на инкрементални резервни копия:
Време на работа:
Първо стартиране
Второ стартиране
Трето стартиране
Първи тест
8m10s
8m10s
8m12s
Втори тест
3m50s
4m12s
3m34s
Трети тест
2m50s
2m35s
2m38s
Размерът на репозитория в двата случая е около 14 GB, което говори за работеща дедупликация на страната на сървера. Също така трябва да се отбележи несъответствието между времето на създаване на резервното копие на сървера и на клиента, което е ясно видимо от графиците и е доста приятен бонус, тъй като уеб интерфейсът показва времето на операцията по резервно копиране от страната на сървера без да взема предвид
състоянието на клиента. Като цяло графиците за пълно и инкрементално копие почти не се различават. Вероятно разликата е само в обработката на страната на сървера. Освен това, ниското натоварване на процесора на резервираната система беше приятно изненадващо.
Обзор на BackupPC
По молба на участника Добавям преглед на BackupPC. Този софтуер се инсталира на сървър за съхранение на резервни копия, написан е на perl, работи върху различни средства за резервно копиране - предимно rsync и tar. За транспорт се използват ssh и smb, наличен е и уеб интерфейс на основата на cgi (разгръща се върху apache). В уеб интерфейса има обширен списък с настройки. От особеностите - възможността за задаване на минимален интервал между резервните копия, както и период, в който резервните копия няма да се създават. При избора на файлова система за сървъра за резервни копия е необходимо да се следи за поддръжка на жестоки линкове. По този начин, файлова система за хранилището не може да бъде разделена на монтажни точки. В общи линии, впечатлението е доста приятно, да видим на какво е способен този софтуер:
В режим на създаване на пълни резервни копия с rsync получихме такива резултати:
Първо стартиране
Второ стартиране
Трето стартиране
Първи тест
12м25с
12м14с
12м27с
Втори тест
7м41с
7м44с
7м35с
Трети тест
10м11с
10м0с
9м54с
Ако обаче използваме пълни резервни копия и tar:
Първо стартиране
Второ стартиране
Трето стартиране
Първи тест
12м41с
12м25с
12м45с
Втори тест
12м35с
12м45с
12м14с
Трети тест
12м43с
12м25с
12м5с
В режим на създаване на инкрементални резервни копия се наложи да се откажем от tar, тъй като при тези настройки резервните копия не се създаваха.
Резултати от създаването на инкрементални резервни копия с rsync са следните:
Първо стартиране
Второ стартиране
Трето стартиране
Първи тест
11м55с
11м50с
12м25с
Втори тест
2м42с
2m50s
2м30с
Трети тест
6м00с
5m35s
5m30s
В общи линии се вижда малко предимство в скоростта на rsync, също така rsync работи по-икономично с мрежата. Отчасти това може да бъде компенсирано с по-ниската използваемост на CPU от tar като програма за създаване на резервни копия. Друго предимство на rsync е работата с инкрементални копия. Размерът на хранилището при създаване на пълни резервни копия е един и същ и е 16 GB, в случай на инкрементални копия - 14 GB за един цикъл, което означава работеща дедупликация.
Преглед на AMANDA
По молба на участника Добавям тестове на AMANDA,
Резултатите от тестовия прогон с tar в качеството на архиватор и активиране на компресията са следните:
Първо стартиране
Второ стартиране
Трето стартиране
Първи тест
9м5с
8м59с
9м6с
Втори тест
0м5с
0м5с
0м5с
Трети тест
2м40с
2м47с
2m45s
Програмата напълно натоварва едно процесорно ядро, но заради ограничените iops на диска от страната на сървъра за съхранение на резервни копия не може да постигне висока скорост на пренос на данни. Общото настрояване създаде малко повече трудности в сравнение с останалите участници, тъй като авторът на програмата не използва ssh като преносно средство, а реализира подобна схема с ключове, създавайки и поддържайки пълнофункционална CA. Има възможност за широко ограничаване на клиента и сървъра за резервиране: например, ако те не могат напълно да се доверят един на друг, може, като вариант, да се забрани инициирането на възстановяване на резервна копия от страна на сървъра, задавайки стойност на съответната променлива на нула в конфигурационния файл. Съществува възможност да се свърже уеб интерфейс за управление, но общо взето настройваната система може да бъде напълно автоматизирана с помощта на малки bash скриптове (или SCM, например ansible). Има не тривиална система за настройка на хранилището, което очевидно е свързано с поддръжката на обширен списък от различни устройства за съхранение на данни (касети LTO, твърди дискове и т.н.). Също така си струва да се отбележи, че от всички програми, разгледани в тази статия, AMANDA е единствената, която успя да открие преименуването на директорията. Размерът на репозитория при едно стартиране беше 13 GB.
Анонс
Резервно копиране, част 6: Сравнение на средствата за резервно копиране
Резервно копиране, част 7: Изводи
Източник: habr.com
