- PVSM.RU - https://www.pvsm.ru -
В данной статье будут рассматриваться программные средства для резервного копирования, которые путем разбиения потока данных на отдельные компоненты (chunks), формируют репозиторий.
Компоненты репозитория могут дополнительно сжиматься и шифроваться, а самое главное — при повторных процессах резервного копирования — переиспользоваться повторно.
Резервная копия в подобном репозитории — именованная цепочка связанных друг с другом компонентов, например, на основе различных hash-функций.
Есть несколько подобных решений, я остановлюсь на 3: zbackup, borgbackup и restic.
Поскольку все претенденты так или иначе требуют создания репозитория, одним из важнейших факторов будет оценка размера репозитория. В идеальном случае его размер должен быть не более 13 гб согласно принятой методике, а то и меньше — при условии хорошей оптимизации.
Также крайне желательно иметь возможность создавать резервные копии файлов напрямую, без применения архиваторов типа tar, а также работу с ssh/sftp без дополнительных средств вроде rsync и sshfs.
Поведение при создании резервных копий:
В качестве эталонного значения принята работа с tar, как это было показано в одной из прошлых статей.
Общий механизм работы zbackup заключается в том, что программа находит в потоке данных, подаваемом на входе, области, содержащие одинаковые данные, затем опционально их сжимает, шифрует, сохраняя каждую область только 1 раз.
Для дедупликации используется 64-битная кольцевая hash-функция со скользящим окном для побайтной проверки на совпадение с уже существующими блоками данных (подобному тому, как это реализовано в rsync).
Для сжатия применяется lzma и lzo в многопоточном исполнении, а для шифрования — aes. В последних версиях присутствует возможность в будущем удалять старые данные из репозитория.
Программа написана на C++ с минимальными зависимостями. Автор по всей видимости вдохновлялся unix-way, поэтому программа принимает данные на stdin при создании резервных копий, выдавая аналогичный поток данных в stdout при восстановлении. Таким образом, zbackup можно использовать как весьма неплохой "кирпичик" при написании собственных решений резервного копирования. Например, у автора статьи эта программа является основным средством резервного копирования для домашних машин примерно с 2014 года.
В качестве потока данных будет применяться обычный tar, если не сказано иначе.
Проверка работы выполнялась в 2 вариантах:
Результаты первого варианта были такие: 43m11s — при использовании нешифрованного репозитория и компрессора lzma, 19m13s — при замене компрессора на lzo.
Нагрузка на сервере с исходными данными была следующей (показан пример с lzma, с lzo была примерно такая же картинка, но доля rsync была примерно четверть от времени):
Ясно видно, что подобный процесс резервного копирования годится лишь при относительно редких и небольших изменениях. Также крайне желательно ограничивать работу zbackup в 1 поток, иначе будет весьма высокая загрузка по процессору, т.к. программа весьма хорошо умеет работать в несколько потоков. Нагрузка на диск была небольшой, что в целом при современной дисковой подсистеме на основе ssd будет незаметно. Также четко видно запуск процесса синхронизации данных репозитория на удаленный сервер, скорость работы сравнима с обычным rsync и упирается в производительность дисковой подсистемы сервера хранения резервных копий. Минусом подхода является хранение локального репозитория и, как следствие, — дублирование данных.
Более интересным и применимым на практике является второй вариант с запуском zbackup сразу на сервере хранения резервных копий.
Для начала будет проверена работа без использования шифрования c компрессором lzma:
Время работы каждого тестового запуска:
Запуск 1 | Запуск 2 | Запуск 3 |
---|---|---|
39m45s | 40m20s | 40m3s |
7m36s | 8m3s | 7m48s |
15m35s | 15m48s | 15m38s |
Если активировать шифрование с применением aes, результаты достаточно близки:
Время работы на тех же данных, с шифрованием:
Запуск 1 | Запуск 2 | Запуск 3 |
---|---|---|
43m40s | 44m12s | 44m3s |
8m3s | 8m15s | 8m12s |
15m0s | 15m40s | 15m25s |
Если шифрование совместить с сжатием на lzo, выходит так:
Время работы:
Запуск 1 | Запуск 2 | Запуск 3 |
---|---|---|
18m2s | 18m15s | 18m12s |
5m13s | 5m24s | 5m20s |
8m48s | 9m3s | 8m51s |
Размер результирующего репозитория был относительно одинаков и составлял 13гб. Это значит, что дедупликация работает корректно. Также на уже сжатых данных применение lzo дает ощутимый эффект, по общему времени работы zbackup вплотную приближается к duplicity/duplicati, однако отставая от основанных на librsync в 2-5 раз.
Преимущества очевидны — экономия дискового пространства на сервере хранения резервных копий. Что касается инструментов проверки репозитория — автором zbackup они не предусмотрены, рекомендуется применять отказоустойчивый дисковый массив или облачный провайдер.
В целом весьма неплохое впечатление, несмотря на то, что проект примерно 3 года стоит на месте (последний feature request был около года назад, но без ответа).
Borgbackup является форком attic, еще одной, схожей с zbackup системы. Написан на python, имеет схожий с zbackup список возможностей, но дополнительно умеет:
При тестировании будет использоваться эвристика при компрессии с определением типа файла (compression auto), а результаты будут такие:
Время работы:
Запуск 1 | Запуск 2 | Запуск 3 |
---|---|---|
4m6s | 4m10s | 4m5s |
56s | 58s | 54s |
1m26s | 1m34s | 1m30s |
Если включить авторизацию репозитория (режим authenticated), результаты получатся близкими:
Время работы:
Запуск 1 | Запуск 2 | Запуск 3 |
---|---|---|
4m11s | 4m20s | 4m12s |
1m0s | 1m3s | 1m2s |
1m30s | 1m34s | 1m31s |
При активации шифрования aes результаты не сильно ухудшились:
Запуск 1 | Запуск 2 | Запуск 3 |
---|---|---|
4m55s | 5m2s | 4m58s |
1m0s | 1m2s | 1m0s |
1m49s | 1m50s | 1m50s |
А если поменять aes на blake, ситуация вовсе улучшится:
Время работы:
Запуск 1 | Запуск 2 | Запуск 3 |
---|---|---|
4m33s | 4m43s | 4m40s |
59s | 1m0s | 1m0s |
1m38s | 1m43s | 1m40s |
Как и в случае с zbackup, размер репозитория составил 13гб и даже чуть меньше, что, в целом, ожидаемо. Весьма порадовало время работы, оно сравнимо с решениями на основе librsync, обеспечивая гораздо более широкие возможности. Также порадовала возможность задания различных параметров через переменные окружения, что дает весьма серьезное преимущество при использовании borgbackup в автоматическом режиме. Также порадовала нагрузка при резервном копировании: судя по загрузке процессора — borgbackup работает в 1 поток.
Особых минусов при использовании не обнаружилось.
Несмотря на то, что restic достаточно новое решение (первые 2 кандидата были известны еще с 2013 года и старше), он обладает достаточно неплохими характеристиками. Написан на Go.
Если сравнивать с zbackup, дополнительно дает:
В целом список возможностей достаточно близок к borgbackup, местами больше, местами меньше. Из особенностей — отсутствие возможности отключения шифрования, а следовательно, резервные копии будут зашифрованными всегда. Давайте посмотрим на практике, что можно выжать из этого ПО:
Результаты работы также сравнимы с решениями на основе rsync и, в целом, весьма близки к borgbackup, но нагрузка на процессор более высокая (работает несколько потоков) и пилообразная.
Вероятнее всего, программа упирается в производительность дисковой подсистемы на сервере хранения данных, как это уже было с rsync. Размер репозитория составил 13гб, как и у zbackup или borgbackup, явных минусов при использовании этого решения не обнаружилось.
По факту у всех кандидатов получились близкие показатели, однако разной ценой. Лучше всех показал себя borgbackup, чуть медленнее — restic, zbackup, вероятно, не стоит начинать применять,
а если он уже используется — пробовать менять на borgbackup или restic.
Наиболее перспективным решением выглядит restic, т.к. именно он обладает наилучшим соотношением возможностей к скорости работы, но пока не будем торопиться с общими выводами.
Borgbackup в принципе ничем не хуже, а вот zbackup вероятно лучше заменить. Правда, для обеспечения работы правила 3-2-1 zbackup все еще можно задействовать. Например, в дополнение к средствам резервного копирования на основе (lib)rsync.
Резервное копирование, часть 1: Зачем нужно резервное копирование, обзор методов, технологий [10]
Резервное копирование, часть 2: Обзор и тестирование rsync-based средств резервного копирования [11]
Резервное копирование, часть 3: Обзор и тестирование duplicity, duplicati [12]
Резервное копирование, часть 4: Обзор и тестирование zbackup, restic, borgbackup
Резервное копирование, часть 5: Тестирование bacula и veeam backup for linux
Резервное копирование, часть 6: Сравнение средств резервного копирования
Резервное копирование, часть 7: Выводы
Автор публикации: Павел Демкович
Автор: nAbdullin
Источник [13]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/backup/319943
Ссылки в тексте:
[1] Image: https://habrastorage.org/webt/pp/d3/hs/ppd3hsaxn_kffamwcrwstrb_sds.png
[2] Image: https://habrastorage.org/webt/wf/m4/g0/wfm4g0zjf3cktbvihsmmtbg-hcu.png
[3] Image: https://habrastorage.org/webt/mf/7p/yv/mf7pyvnly6bmjtxbno88mjtrtn4.png
[4] Image: https://habrastorage.org/webt/38/cz/tb/38cztb4tuzxtgsorc6uysied59k.png
[5] Image: https://habrastorage.org/webt/fe/ep/xm/feepxmsoyorprvvt5h00tuj2spg.png
[6] Image: https://habrastorage.org/webt/3c/qe/kx/3cqekxviy9rzhafckbi0tidjxn4.png
[7] Image: https://habrastorage.org/webt/oa/yz/zl/oayzzliqw8zixlppy_idv2l8gzm.png
[8] Image: https://habrastorage.org/webt/df/kh/ay/dfkhayqoecs9hw_c_aj2fmxjkbu.png
[9] Image: https://habrastorage.org/webt/tq/k5/xn/tqk5xn1xknn33dydmslqofrjfvs.png
[10] Резервное копирование, часть 1: Зачем нужно резервное копирование, обзор методов, технологий: https://habr.com/ru/company/southbridge/blog/449282/
[11] Резервное копирование, часть 2: Обзор и тестирование rsync-based средств резервного копирования: https://habr.com/ru/company/southbridge/blog/452630/
[12] Резервное копирование, часть 3: Обзор и тестирование duplicity, duplicati: https://habr.com/ru/company/southbridge/blog/454420/
[13] Источник: https://habr.com/ru/post/454734/?utm_source=habrahabr&utm_medium=rss&utm_campaign=454734
Нажмите здесь для печати.