Форум OlegON > Компьютеры и Программное обеспечение > Операционные системы и программное обеспечение

Сравнение borgbackup и restic : Операционные системы и программное обеспечение

28.03.2024 17:33


08.04.2021 16:35
OlegON
 
Я являюсь давним поклонником программки borgbackup. Однако, не мог не обратить внимание, что есть у нее и аналог, программка restic. Говорить буду от себя лично, в свете использования на своем компе с Fedora. По мере обнаружения каких-либо новых нюансов буду дописывать сюда, если есть какие-то идеи для тестов или вопросы - пишите.

Borgbackup написан на python, restic - на Go, соответственно в первом случае пакет состоит из вороха .py, во втором - из одного бинарника. Тут преимущество за restic, поскольку маловероятно, что его удастся сломать каким-нибудь обновлением, как у borgbackup уже ломалось что-то в монтировании при обновлении python.

При работе borgbackup работает всегда в один поток, restic многопоточный. Понятное дело, что restic в этом случае можно разогнать практически до космической скорости, если речь идет о выделенном сервере с кучей процессоров. Однако, если сервер невыделенный, то вариант borgbackup может быть предпочтительнее. Разные варианты использования могут быть с разными предпочтениями.

Обе программы могут работать с удаленными хранилищами, но borgbackup только по SSH, а restic еще с кучей других хранилищ, в том числе интегрируя rclone. Я это не тестировал, поскольку мне нужно локальное хранение, которое я потом rclone копирую в разные места самостоятельно. Да, при этом restic может брать данные из stdin (например, от tar), borgbackup, впрочем, тоже.

Репозитории каждой из программок устроен по разному, restic сразу создает 256 директорий с кучей вложенных файлов небольшого размера, имена напоминают какой-то hash, borgbackup делает поддиректории только для каждого из уровня бекапов, внутри каждой из директорий файлы в полгигабайта, из имени с порядковым номером. В данном случае restic создает нечто более тяжелое для файловой системы и, главное, синхронизация этого счастья по узкому каналу достаточно долгая должна быть. Пример:
Тестовый архив: find . | wc -l
344529
Репозиторий borg: find . | wc -l
626
Репозиторий restic: find . | wc -l
59654

Каждая из программок делает в хомяке пользователя, под которым работает, директорию кеша. По моему тесту, например, borg занял 512Мб, а restic - 220Мб. Однако, программки коренным образом отличаются отношением к очистке этого кеша. Если при инкрементальном архиве restic икнул и секунд за 20 все вернул обратно, то borgbackup озадачился и пошел полностью пересканировать, на что потратил около 50 минут.
08.04.2021 19:24
OlegON
 
На тему скорости и итогового объема получаемого архива, исходный образец 60Гб (32852 файла):
Инициализация репозитория:
borgbackup - 0m1,531s
restic - 0m2,588s

Первый проход:
borgbackup - 16m21,296s - 55Гб
restic - 22m31,803s - 55Гб

Второй проход, файлы не изменились:
borgbackup - 0m4,283s
restic - 0m2,115s

Третий проход, в тесте самая большая директория (36Гб и 16376 файлов) задублирована рядом:
borgbackup - 4m10,509s
restic - 4m30,405s
размеры бекапов если и увеличились, то незначительно, 55Гб оба по прежнему

Четвертый проход, в тесте созданная в предущем бекапе директория удалена:
borgbackup - 0m4,655s
restic - 0m2,155s
размеры бекапов не изменились
кстати, у меня больше чем в два потока restic не пытался работать...
08.04.2021 19:29
OlegON
 
Докинул в тест образ XP на 4Гб:
borgbackup - 0m45,364s
restic - 0m56,343s
но размер у borgbackup стал 57Гб, а у restic - 58Гб
08.04.2021 19:31
OlegON
 
По общему выводу... restic проигрывает... Выигрывая только 2 секунды на просмотр неизменившегося архива, на монолит бинарника и на работу со сломаным кешем, он проигрывает borgbackup практически во всем остальном...
09.04.2021 14:29
OlegON
 
просмотр замонтированного архива сильно различается по скорости... restic входит, как в обычную директорию, borg каждый из уровней архива открывает после размышления секунд на 5.
10.04.2021 20:08
OlegON
 
Синхронизация restic с гугловым диском идет адски долго за счет такого количества файлов... По сети открытие и закрытие файла достаточно долгая операция.
Часовой пояс GMT +3, время: 17:33.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.