В данной статье будут рассматриваться программные средства для резервного копирования, которые путем разбиения потока данных на отдельные компоненты (chunks), формируют репозиторий.
Компоненты репозитория могут дополнительно сжиматься и шифроваться, а самое главное — при повторных процессах резервного копирования — переиспользоваться повторно.
Резервная копия в подобном репозитории — именованная цепочка связанных друг с другом компонентов, например, на основе различных hash-функций.
Есть несколько подобных решений, я остановлюсь на 3: zbackup, borgbackup и restic.
Nsonaazụ tụrụ anya
Поскольку все претенденты так или иначе требуют создания репозитория, одним из важнейших факторов будет оценка размера репозитория. В идеальном случае его размер должен быть не более 13 гб согласно принятой методике, а то и меньше — при условии хорошей оптимизации.
Также крайне желательно иметь возможность создавать резервные копии файлов напрямую, без применения архиваторов типа tar, а также работу с ssh/sftp без дополнительных средств вроде rsync и sshfs.
Omume mgbe ị na-emepụta nkwado ndabere:
- Размер репозитория будет равен размеру изменений, или меньше.
- Ожидается большая нагрузка на процессор при использовании сжатия и/или шифрования, а также вероятна достаточно большая нагрузка на сеть и дисковую подсистему, если процесс архивации и/или шифрования будет работать на сервере хранения резервных копий.
- Если повредить репозиторий — вероятна отложенная ошибка как при создании новых резервных копий, так и при попытке восстановления. Надо планировать дополнительные меры по обеспечению целостности репозитория или использовать встроенные средства проверки его целостности.
В качестве эталонного значения принята работа с tar, как это было показано в одной из прошлых статей.
Тестирование zbackup
Общий механизм работы zbackup заключается в том, что программа находит в потоке данных, подаваемом на входе, области, содержащие одинаковые данные, затем опционально их сжимает, шифрует, сохраняя каждую область только 1 раз.
Для дедупликации используется 64-битная кольцевая hash-функция со скользящим окном для побайтной проверки на совпадение с уже существующими блоками данных (подобному тому, как это реализовано в rsync).
Для сжатия применяется lzma и lzo в многопоточном исполнении, а для шифрования — aes. В последних версиях присутствует возможность в будущем удалять старые данные из репозитория.
Программа написана на C++ с минимальными зависимостями. Автор по всей видимости вдохновлялся unix-way, поэтому программа принимает данные на stdin при создании резервных копий, выдавая аналогичный поток данных в stdout при восстановлении. Таким образом, zbackup можно использовать как весьма неплохой «кирпичик» при написании собственных решений резервного копирования. Например, у автора статьи эта программа является основным средством резервного копирования для домашних машин примерно с 2014 года.
В качестве потока данных будет применяться обычный tar, если не сказано иначе.
Ka anyị hụ ihe ga-esi na ya pụta:
Проверка работы выполнялась в 2 вариантах:
- создается репозиторий и запускается zbackup на сервере с исходными данными, потом содержимое репозитория передается на сервер хранения резервных копий.
- создается репозиторий на сервере хранения резервных копий, запускается zbackup через ssh на сервере хранения резервных копий, ему через pipe выдаются данные.
Результаты первого варианта были такие: 43m11s — при использовании нешифрованного репозитория и компрессора lzma, 19m13s — при замене компрессора на lzo.
Нагрузка на сервере с исходными данными была следующей (показан пример с lzma, с lzo была примерно такая же картинка, но доля rsync была примерно четверть от времени):
Ясно видно, что подобный процесс резервного копирования годится лишь при относительно редких и небольших изменениях. Также крайне желательно ограничивать работу zbackup в 1 поток, иначе будет весьма высокая загрузка по процессору, т.к. программа весьма хорошо умеет работать в несколько потоков. Нагрузка на диск была небольшой, что в целом при современной дисковой подсистеме на основе ssd будет незаметно. Также четко видно запуск процесса синхронизации данных репозитория на удаленный сервер, скорость работы сравнима с обычным rsync и упирается в производительность дисковой подсистемы сервера хранения резервных копий. Минусом подхода является хранение локального репозитория и, как следствие, — дублирование данных.
Более интересным и применимым на практике является второй вариант с запуском zbackup сразу на сервере хранения резервных копий.
Для начала будет проверена работа без использования шифрования c компрессором lzma:
Oge ịgba ọsọ nke ọsọ ule ọ bụla:
Mwepụta 1
Mwepụta 2
Mwepụta 3
39 m45
40 m20
40 m3
7 m36
8 m3
7 m48
15 m35
15 m48
15 m38
Если активировать шифрование с применением aes, результаты достаточно близки:
Oge na-arụ ọrụ na otu data, yana izo ya ezo:
Mwepụta 1
Mwepụta 2
Mwepụta 3
43 m40
44 m12
44 m3
8 m3
8 m15
8 m12
15 m0
15 m40
15 m25
Если шифрование совместить с сжатием на lzo, выходит так:
Oge ọrụ:
Mwepụta 1
Mwepụta 2
Mwepụta 3
18 m2
18 m15
18 m12
5 m13
5 m24
5 m20
8 m48
9 m3
8 m51
Размер результирующего репозитория был относительно одинаков и составлял 13гб. Это значит, что дедупликация работает корректно. Также на уже сжатых данных применение lzo дает ощутимый эффект, по общему времени работы zbackup вплотную приближается к duplicity/duplicati, однако отставая от основанных на librsync в 2-5 раз.
Преимущества очевидны — экономия дискового пространства на сервере хранения резервных копий. Что касается инструментов проверки репозитория — автором zbackup они не предусмотрены, рекомендуется применять отказоустойчивый дисковый массив или облачный провайдер.
В целом весьма неплохое впечатление, несмотря на то, что проект примерно 3 года стоит на месте (последний feature request был около года назад, но без ответа).
Тестирование borgbackup
Borgbackup является форком attic, еще одной, схожей с zbackup системы. Написан на python, имеет схожий с zbackup список возможностей, но дополнительно умеет:
- Монтировать резервные копии через fuse
- Проверять содержимое репозитория
- Работать в режиме клиент-сервер
- Использовать различные компрессоры для данных, а также эвристическое определение типа файла при его компрессии.
- 2 варианта шифрования, aes и blake
- Встроенное средство для
проверки производительности
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Результаты получились такие:
C-Z-BIG 96.51 MB/s (10 100.00 MB all-zero files: 10.36s)
R-Z-BIG 57.22 MB/s (10 100.00 MB all-zero files: 17.48s)
U-Z-BIG 253.63 MB/s (10 100.00 MB all-zero files: 3.94s)
D-Z-BIG 351.06 MB/s (10 100.00 MB all-zero files: 2.85s)
C-R-BIG 34.30 MB/s (10 100.00 MB random files: 29.15s)
R-R-BIG 60.69 MB/s (10 100.00 MB random files: 16.48s)
U-R-BIG 311.06 MB/s (10 100.00 MB random files: 3.21s)
D-R-BIG 72.63 MB/s (10 100.00 MB random files: 13.77s)
C-Z-MEDIUM 108.59 MB/s (1000 1.00 MB all-zero files: 9.21s)
R-Z-MEDIUM 76.16 MB/s (1000 1.00 MB all-zero files: 13.13s)
U-Z-MEDIUM 331.27 MB/s (1000 1.00 MB all-zero files: 3.02s)
D-Z-MEDIUM 387.36 MB/s (1000 1.00 MB all-zero files: 2.58s)
C-R-MEDIUM 37.80 MB/s (1000 1.00 MB random files: 26.45s)
R-R-MEDIUM 68.90 MB/s (1000 1.00 MB random files: 14.51s)
U-R-MEDIUM 347.24 MB/s (1000 1.00 MB random files: 2.88s)
D-R-MEDIUM 48.80 MB/s (1000 1.00 MB random files: 20.49s)
C-Z-SMALL 11.72 MB/s (10000 10.00 kB all-zero files: 8.53s)
R-Z-SMALL 32.57 MB/s (10000 10.00 kB all-zero files: 3.07s)
U-Z-SMALL 19.37 MB/s (10000 10.00 kB all-zero files: 5.16s)
D-Z-SMALL 33.71 MB/s (10000 10.00 kB all-zero files: 2.97s)
C-R-SMALL 6.85 MB/s (10000 10.00 kB random files: 14.60s)
R-R-SMALL 31.27 MB/s (10000 10.00 kB random files: 3.20s)
U-R-SMALL 12.28 MB/s (10000 10.00 kB random files: 8.14s)
D-R-SMALL 18.78 MB/s (10000 10.00 kB random files: 5.32s)
При тестировании будет использоваться эвристика при компрессии с определением типа файла (compression auto), а результаты будут такие:
Для начала проверим работу без шифрования:
Oge ọrụ:
Mwepụta 1
Mwepụta 2
Mwepụta 3
4 m6
4 m10
4 m5
56s
58s
54s
1 m26
1 m34
1 m30
Если включить авторизацию репозитория (режим authenticated), результаты получатся близкими:
Oge ọrụ:
Mwepụta 1
Mwepụta 2
Mwepụta 3
4 m11
4 m20
4 m12
1 m0
1 m3
1 m2
1 m30
1 m34
1 m31
При активации шифрования aes результаты не сильно ухудшились:
Mwepụta 1
Mwepụta 2
Mwepụta 3
4 m55
5 m2
4 m58
1 m0
1 m2
1 m0
1 m49
1 m50
1 m50
А если поменять aes на blake, ситуация вовсе улучшится:
Oge ọrụ:
Mwepụta 1
Mwepụta 2
Mwepụta 3
4 m33
4 m43
4 m40
59s
1 m0
1 m0
1 m38
1 m43
1 m40
Как и в случае с zbackup, размер репозитория составил 13гб и даже чуть меньше, что, в целом, ожидаемо. Весьма порадовало время работы, оно сравнимо с решениями на основе librsync, обеспечивая гораздо более широкие возможности. Также порадовала возможность задания различных параметров через переменные окружения, что дает весьма серьезное преимущество при использовании borgbackup в автоматическом режиме. Также порадовала нагрузка при резервном копировании: судя по загрузке процессора — borgbackup работает в 1 поток.
Особых минусов при использовании не обнаружилось.
Тестирование restic
Несмотря на то, что restic достаточно новое решение (первые 2 кандидата были известны еще с 2013 года и старше), он обладает достаточно неплохими характеристиками. Написан на Go.
Если сравнивать с zbackup, дополнительно дает:
- Проверку целостности репозитория (включая проверку по частям).
- Огромный список поддерживаемых протоколов и провайдеров для хранения резервных копий, а также поддержку rclone — rsync для «облачных» решений.
- Сравнение 2 резервных копий между собой.
- Монтирование репозитория через fuse.
В целом список возможностей достаточно близок к borgbackup, местами больше, местами меньше. Из особенностей — отсутствие возможности отключения шифрования, а следовательно, резервные копии будут зашифрованными всегда. Давайте посмотрим на практике, что можно выжать из этого ПО:
Результаты получились таковы:
Oge ọrụ:
Mwepụta 1
Mwepụta 2
Mwepụta 3
5 m25
5 m50
5 m38
35s
38s
36s
1 m54
2 m2
1 m58
Результаты работы также сравнимы с решениями на основе rsync и, в целом, весьма близки к borgbackup, но нагрузка на процессор более высокая (работает несколько потоков) и пилообразная.
Вероятнее всего, программа упирается в производительность дисковой подсистемы на сервере хранения данных, как это уже было с rsync. Размер репозитория составил 13гб, как и у zbackup или borgbackup, явных минусов при использовании этого решения не обнаружилось.
Результаты
По факту у всех кандидатов получились близкие показатели, однако разной ценой. Лучше всех показал себя borgbackup, чуть медленнее — restic, zbackup, вероятно, не стоит начинать применять,
а если он уже используется — пробовать менять на borgbackup или restic.
Nchoputa
Наиболее перспективным решением выглядит restic, т.к. именно он обладает наилучшим соотношением возможностей к скорости работы, но пока не будем торопиться с общими выводами.
Borgbackup в принципе ничем не хуже, а вот zbackup вероятно лучше заменить. Правда, для обеспечения работы правила 3-2-1 zbackup все еще можно задействовать. Например, в дополнение к средствам резервного копирования на основе (lib)rsync.
Ọkwa
Ndabere akụkụ 5: Nnwale bacula na veeam ndabere maka Linux
Ndabere akụkụ 6: atụnyere ngwaọrụ ndabere
Ndabere akụkụ 7: Mkpebi
Biputere ya bụ: Pavel Demkovich
isi: www.habr.com