Данная обзорная заметка продолжает
Обзор UrBackup.
По просьбе участника
В режиме создания полной резервной копии получились такие результаты:
Время работы:
Первый запуск
Второй запуск
Третий запуск
Первый тест
8m20s
8m19s
8m24s
Второй тест
8m30s
8m34s
8m20s
Третий тест
8m10s
8m14s
8m12s
В режиме создания инкрементальных резервных копий:
Время работы:
Первый запуск
Второй запуск
Третий запуск
Первый тест
8m10s
8m10s
8m12s
Второй тест
3m50s
4m12s
3m34s
Третий тест
2m50s
2m35s
2m38s
Размер репозитория в обоих случаях составил примерно 14 гб, что говорит о работающей дедупликации на стороне сервера. Также следует отметить несоответствие времени создания резервной копии на сервере и на клиенте, что достаточно четко видно по графикам и является весьма приятным бонусом, поскольку web-интерфейс показывает время работы процесса резервного копирования на стороне сервера без учета
состояния клиента. В целом графики для полной и инкрементальной копии неотличимы. Вероятно, различие только в том, как это обрабатывается на стороне сервера. Также порадовала низкая загрузка процессора на резервируемой системе.
Обзор BackupPC
По просьбе участника
В режиме создания полных резервных копий с 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
По просьбе участника
Результаты тестового прогона с tar в качестве архиватора и активацией сжатия таковы:
Первый запуск
Второй запуск
Третий запуск
Первый тест
9m5s
8m59s
9m6s
Второй тест
0m5s
0m5s
0m5s
Третий тест
2m40s
2m47s
2m45s
Программа полностью загружает одно процессорное ядро, но из-за ограниченного по iops диска на стороне сервера хранения резервных копий не может развить большую скорость передачи данных. В целом, настройка доставила чуть больше хлопот, чем у остальных участников, поскольку автор программы не использует в качестве транспорта ssh, а реализует схожую схему с ключами, создавая и поддерживая полноценную CA. Есть возможность широко ограничить клиента и сервер резервного копирования: например, если они не могут полностью доверять друг другу, то можно, как вариант, запретить инициирование восстановления резервной копии со стороны сервера, задавая значение соответствующей переменной в ноль в файле настроек. Есть возможность подключить web-интерфейс для управления, но в целом настроенную систему можно автоматизировать полностью с помощью небольших скриптов на bash (или SCM, к примеру ansible). Существует несколько нетривиальная система настройки хранилища, что, по всей видимости, связано с поддержкой обширного списка различных устройств для хранения данных (кассеты LTO, жесткие диски и т.п.). Также стоит отметить, что из всех программ, рассмотренных в этой статье, AMANDA — единственная, сумевшая обнаружить переименование каталога. Размер репозитория при одном прогоне составил 13 гб.
Анонс
Резервное копирование, часть 6: Сравнение средств резервного копирования
Резервное копирование, часть 7: Выводы
Источник: habr.com