company_banner

Резервное копирование, часть по просьбам читателей: Обзор UrBackup, BackupPC, AMANDA


    Данная обзорная заметка продолжает цикл по резервному копированию, написана по просьбе читателей, в ней речь пойдет о UrBackup, BackupPC, а также AMANDA.


    Обзор UrBackup.


    По просьбе участника VGusev2007 добавляю обзор 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


    По просьбе участника vanzhiganov добавляю обзор 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


    По просьбе участника oller добавляю тесты AMANDA,


    Результаты тестового прогона с tar в качестве архиватора и активацией сжатия таковы:


    Первый запуск Второй запуск Третий запуск
    Первый тест 9m5s 8m59s 9m6s
    Второй тест 0m5s 0m5s 0m5s
    Третий тест 2m40s 2m47s 2m45s

    Программа полностью загружает одно процессорное ядро, но из-за ограниченного по iops диска на стороне сервера хранения резервных копий не может развить большую скорость передачи данных. В целом, настройка доставила чуть больше хлопот, чем у остальных участников, поскольку автор программы не использует в качестве транспорта ssh, а реализует схожую схему с ключами, создавая и поддерживая полноценную CA. Есть возможность широко ограничить клиента и сервер резервного копирования: например, если они не могут полностью доверять друг другу, то можно, как вариант, запретить инициирование восстановления резервной копии со стороны сервера, задавая значение соответствующей переменной в ноль в файле настроек. Есть возможность подключить web-интерфейс для управления, но в целом настроенную систему можно автоматизировать полностью с помощью небольших скриптов на bash (или SCM, к примеру ansible). Существует несколько нетривиальная система настройки хранилища, что, по всей видимости, связано с поддержкой обширного списка различных устройств для хранения данных (кассеты LTO, жесткие диски и т.п.). Также стоит отметить, что из всех программ, рассмотренных в этой статье, AMANDA — единственная, сумевшая обнаружить переименование каталога. Размер репозитория при одном прогоне составил 13 гб.


    Анонс


    Резервное копирование, часть 1: Зачем нужно резервное копирование, обзор методов, технологий
    Резервное копирование, часть 2: Обзор и тестирование rsync-based средств резервного копирования
    Резервное копирование, часть 3: Обзор и тестирование duplicity, duplicati
    Резервное копирование, часть 4: Обзор и тестирование zbackup, restic, borgbackup
    Резервное копирование, часть 5: Тестирование bacula и veeam backup for linux
    Резервное копирование, часть 6: Сравнение средств резервного копирования
    Резервное копирование, часть 7: Выводы

    • +18
    • 5,4k
    • 4
    Southbridge
    537,14
    Обеспечиваем стабильную работу серверов
    Поделиться публикацией

    Комментарии 4

      0
      Благодарю, ожидаем выводов. :) Правда, обзоры не очень глубокие, но всё же.
        0

        Все правильно заметили, т.к. основная цель — сравнить "как есть", не сильно углубляясь в детали и при этом стараясь не выполнять упражнений в bash\ansible копируя команды из руководства администратора\пользователя. Услышал как звать ПО — нашел пакет для своего дистрибутива — поставил из репозитория — забил в cron команду\настроил задания в некоем интерфейсе (web\gui\tui и т.п.) — копии снимаются в приемлемое место и время.

        0

        Автор, обозрите мой инкрементальный бекап, пользуюсь уже лет 15, может я что-то не так делаю? Надо брать Duplicaty? duplicity? Bacula?


        FROM=$1 # откуда
        TO=$2 # куда
        LINKTO=--link-dest=$TO/`basename $FROM`.1 # предыдущая копия
        OPTS="-Ca --delete" # полезные опции для rsync
        NUMBER_OF_BACKUPS=10 # столько копий мы храним 
        # шаманим с переименованием папок, чтобы предыдущие версии сохранялись под именами
        # dir.1, dir.2, dir.3 и так далее до dir.9
        find $TO -maxdepth 1 -type d -name '*.[0-9]'| sort -rn| while read dir
        do
            this=`expr match "$dir" '.*\([0-9]\)'`; 
            let next=($this+1)%$NUMBER_OF_BACKUPS;
            basedirname=${dir%.[0-9]}
            if [ $next -eq 0 ] ; then
                 rm -rf $dir
            else
                 mv $dir $basedirname.$next
            fi
        done
        # шаманство закончилось, запускаем rsync
        rsync $OPTS $LINKTO $FROM/ $TO/`basename $FROM.0`
          0

          Этот скрипт только первая и самая малая часть того, что будет включено в процесс резервного копирования.


          В принципе, если каталог в переменной $TO указывает на дисковое пространство, размещенное не на этом же сервере, или, по крайней мере, не на этом же диске, где и каталог в переменной $FROM — первый шаг уже сделан, и если десять копий необходимо и достаточно — на этом можно и остановиться.


          Однако стоило бы определиться с тем, от чего защищаемся, делая резервные копии, для чего можно попробовать ответить на несколько вопросов:


          • устроит ли потребителей этих данных время восстановления из резервной копии?
          • что делать с данными, которые были, но не успели попасть в резервную копию?
          • нужны ли все данные из копии целиком, или важно иметь возможность достать индивидуальный файл или каталог?

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое