Состоялся (https://www.borgbackup.org/releases/borg-1.1.html) релиз системы резервного копирования BorgBackup 1.1.0 (https://borgbackup.github.io/), несколько лет назад ответвившейся от проекта Attic (https://attic-backup.org/). Система поддерживает дедупликацию, шифрование и сжатие данных в хранилище резервных копий. Основной код проекта написан на языке Python 3, но около 9% критичных к производительности частей оформлены на языке Си. Исходные тексты распространяются (https://github.com/borgbackup/borg) под лицензией BSD. Сборки подготовлены (https://github.com/borgbackup/borg/releases/tag/1.1.0) для FreeBSD, Linux и macOS.
Отличия от системы Attic сводятся к открытому процессу разработки с более простой организацией приёма изменений, устранению нерешённых в Attic проблем, более компактному и потребляющему меньше памяти формату индекса дедуплицированных блоков, более быстрой реализацией кэша синхронизации, поддержке хранения данных в сжатом виде, использованию шифрования по ключам вместо парольной фразы, эффективному хранению файлов с пустотами внутри (например, образов виртуальных машин), системе блокировок на основе вызова mkdir, расширенным сообщениям об ошибках, индикацим прогресса выполнения операций, тестированию в разнообразных ОС.
Возможности и особенности:
- Экономия дискового пространства в хранилище резервных копий за счёт применения дедупликации (как следствие, снижение избыточности и повышение шансов потерять сразу все бэкапы из-за сбоя в усложнённом хранилище или повреждения эталонных блоков). Объединение дублирующихся данных производится на основе выявления идентичных блоков. Файлы разбиваются на блоки, если блок не встречался ранее - он сохраняется в хранилище, если встречался, то записывается ссылка на уже имеющийся в хранилище блок. Применяемый метод дедупликациии не привязан к файлам и директориям, эффективно обрабатывает операции изменения файлов (переписываются только изменившиеся блоки) и смены позиции блоков внутри файла. Дубликаты объединяются в контексте всего репозитория-хранилища и могут охватывать прошлые резервные копии, бэкапы с различных компьютеров, а также идентичные блоки в том же файле.- Высокая производительность - критичный с точки зрения скорости работы код, такой как обработка блоков, сжатие и шифрование, реализован на языке Си с использованием Cython. В BorgBackup также применяется быстрый алгоритм выявления неизменившихся файлов и локальное кэширование индексов, используемых для связывания файлов и блоков в репозитории.
- Данные хранятся с использованием симметричного шифрования AES c 256-разрядным ключом. Для проверки подлинности зашифрованных данных используется HMAC-SHA256. Данные шифруются на стороне клиента (системы, для которой создаётся резервная копия);
- Данные в хранилище могут храниться в сжатом виде с использованием алгоритмов lz4 (быстро, но посредственный уровень сжатия) или lzma (медленно, но высокая степень сжатия);
- Возможность размещения хранилища резервных копий на любом внешнем сервере, на который имеется доступ по протоколу SSH. Для повышения производительности на хост-хранилище могут быть установлены серверные компоненты Borg;
- Поддержка монтирования резервных копий в форме файловых систем (используется FUSE);
- Простота установки - BorgBackup поставляется в форме единого исполняемого файла, который может быть запущен без предварительной установки.Ключевые улучшения в выпуске BorgBackup 1.1.0:
- Добавлена экспериментальная команда "borg recreate" для переупаковки файлов в существующем архиве, что позволяет организовать дедупликацию между старыми архивами Attic / Borg 0.xx и новым форматом архивов Borg 1.x;- Добавлена команда "borg diff" для отображений отличий между двумя архивами;
- В команде "borg mount" реализовано отображение всех имеющихся версий файлов в версионном представлении;- Добавлены дополнительные опции форматирования для команды "borg list", в том числе возможность генерации хэшей и статистики о разбиении каждого файла;
- В команде "borg create" появилась опция "-C auto,zlib/lz4/..." для включения режима автоматического сжатия, ускорена работа с большим числом файлов, добавлена экспериментальная поддержка масок (--patterns, --patterns-from), реализованы средства управления кэшированием mtime/ctime;- Добавлена команда "borg export-tar" для экспорта в формат GNU tar;
- Появилась возможность прикрепления комментариев к архивам;
- Добавлены режим шифрования на базе алгоритма BLAKE2b256 и режимы аутентифицированного хранения для гарантирования целостности без шифрования;
- В индексах репозитория и кэше задействованы контрольные суммы для выявления повреждения информации;- Добавлен API для вывода результата выполнения команд "borg list", "borg info" и "borg create" в формате JSON;
- Реализована возможность ведения лога всех выполненных команд, сохраняемого в формате JSON;- В команды "borg list", "borg info", "borg mount", "borg check", "borg delete" и "borg prun" добавлена опция "--prefix", дополняющая опции --glob-archives (-a), --sort-by, --last и --first;
- По умолчанию включено сжатие lz4.
URL: https://mail.python.org/pipermail/borgbackup/2017q4/000824.html
Новость: http://www.opennet.me/opennews/art.shtml?num=47361
Вот если бы сжатие кто сделал многопоточным... так грустно смотреть в 21 веке, когда процесс бекапа грузит одно ядро, а 100500 простаивают
(PS сам попытку такое сделать уже предпринимал на основе pigz, но как-то не доделал)
И как ты, интересно, собрался распараллеливать lz4? Вот lzma2 отлично распараллеливается.
да хоть бы распараллелили то, что уже параллелится.
Вот gzip и lzma2 уже - и большинству бы админов хватило такого выбора с головой
gzip тоже не параллелится. Подтянул бы матчасть прежде чем хотелки хотеть.
pigz?
нет. pigz не параллелит декомпрессию
И вообще, что значит не параллелится? Больше одного файла - вот и параллельте :)
> gzip тоже не параллелится. Подтянул бы матчасть прежде чем хотелки хотеть.даже если бы gzip не параллелился, то это не повод этого не хотеть.
Когда то и огонь приходилось часами выжимать из двух деревяшек, и это тоже была матчасть.
> Вот lzma2 отлично распараллеливается.к сожалению, не декомпрессия! На терабайтном архиве 4 кратная разница во времени при распаковке (в зависимости от количества ядер, но потом, конечно, упирается в диск) заставляет пользоваться bzip2. Он умеет.
zstd? brotli? Всё открытое, жмет в районе 1 Гб/сек при приемлемом уровне сжатия и возможности распараллеливания.
> И как ты, интересно, собрался распараллеливать lz4?На сжатие можно, если высокие уровни: запустил несколько тредов да фигарь там разные куски. У lz4 адресуемое смещение мелкое, степень сжатия от независимой паковки не испортится. На распаковку LZ4 может быть скоростью RAM подперт и там смысла в потоках мало. Можешь разжать небольшой кусок из одного и того же src в dst, посмотреть до какого космоса LZ4 разгоняется если память быстрая.
> Вот lzma2 отлично распараллеливается.
Но его скорость работы весьма скромная и никакие потоки ему не помогут.
Многопоточность на версию 1.2 заплонирована
о, отличные новости!
Хорошая система. Еще использую Veeam for Linux.
Касперский стырит твои данные.
радостная весть, очень удобная штука.
> borg mountбомба!
>BorgBackup поставляется в форме единого исполняемого файла, который может быть запущен без предварительной установки.Славный шаг в продолжении Windows-way.
>>BorgBackup поставляется в форме единого исполняемого файла, который может быть запущен без предварительной установки.
> Славный шаг в продолжении Windows-way.Для утилиты бэкапа (и соотв. – восстановления) "домашнего/локалхостного пользования" – минимальные зависимости и "все свое ношу с собой" вообще-то скорее в плюс. Проще собрать минимальный образ для рекавери, использовать в готовом лайв-диске/флешке в случае "форс-мажора и накрытия тазом" того самого приготовленного образа для рекавери и т.д. и т.п.
Зависимость в виде питона - это так чудесно для инструмента бэкапа. В ответственный момент оно грохнется с трэйсом на три страницы, а окажется что это как всегда - версия питона в системе не та. Вся питонятина так делает. И инструменты бэкапа на этом - вот уж нафиг.
> Зависимость в виде питона - это так чудесно для инструмента бэкапа.А в огороде бузина? Или у кого что болит?
Читаем глазами:
>>>> единого исполняемого файла, который может быть запущен без предварительной установки.
>>> Славный шаг в продолжении Windows-way.
>>Для утилиты бэкапа (и соотв. – восстановления) "домашнего/локалхостного пользования" – минимальные зависимости и "все свое ношу с собой" вообще-то скорее в плюс.Вообще-то, мы в этой ветке вроде как о смысле минимальных зависимостей для бэкапа, а не о том, у кого от чего чуть пониже спины эт-самое.
> Зависимость в виде питона - это так чудесно для инструмента бэкапа.А лучше было бы, если еще и левые пакеты подтягивались через pip?
> В ответственный момент оно грохнется с трэйсом на три страницы,
То ли дело натив, да? Ни сегфолтов, ни проблем с зависимостями?
Тут вон zbackup упоминали - так оно вполне может отвалиться из-за несовместимой версии protobuf, как в самой системе, так и использованной при создании репы-бэкапа.
А так все хорошо, прекрасная маркиза, ага.> грохнется с трэйсом на три страницы, а окажется что это как всегда - версия питона в системе не та.
> Вся питонятина так делает.Т.е. у вас скрипты на питоне падают с трейсом на три страницы? Причем, все только из-за того, что вы так и не удосужились узнать, что у питона аж две ветки, зато ноете в каждой новосте с упоминанием питона?
Ну, что тут можно сказать – о прямизне ваших рук, познаниях в этой области, как и твердости характера в упорном желании страдать, можно вполне слагать легенды!> И инструменты бэкапа на этом - вот уж нафиг.
Вообще-то, задачи и цели у бэкапа разные бывают.
> Вообще-то, мы в этой ветке вроде как о смысле минимальных зависимостей для
> бэкапа, а не о том, у кого от чего чуть пониже спины эт-самое.Минимальные такие зависимости. В виде интерпретера на хренадцать метров и его рантайма и стандартных либ, интенсивно переколупываемых и совместимых лишь частично. От чего сторонние скрипты на раз дохнут с громадным трэйсом. Ибо код надо переписывать не реже раза в год for teh greater good. Притащить один файлик? Это какой? Архив где до кучи будет еще интерпретер питона заведомо правильной версии вместе со всеми его стандартнми либами и прочей обвязкой? Да тут даже шняга на го на 10 мегов покажется небольшой и компактной программой, пожалуй. А без всего этого есть риск что притащенный скрипт лоханется с вот этим вариантом интерпретера. Потому что там в очередной раз что-то несовместимо поменяли.
> А лучше было бы, если еще и левые пакеты подтягивались через pip?
"Вам швабру как лучше - целиком или наполовину?" Себе вашу швабру внедрите!
> То ли дело натив, да? Ни сегфолтов, ни проблем с зависимостями?
Если ставить софт из репов то там как правило ни сегфолтов, ни проблем с зависимостями. Для этого в дистрах есть майнтайнеры, они этому очень способствуют. В отличие от притащенных со стороны программ и скриптов, межжу прочим.
> Тут вон zbackup упоминали - так оно вполне может отвалиться из-за несовместимой
> версии protobuf, как в самой системе, так и использованной при создании репы-бэкапа.
> А так все хорошо, прекрасная маркиза, ага.Могу представить себе сколько приколов такого рода навешали питонисты. И конечно же мы узнаем об этом потом. Впрочем, безбашенно используемый протобуф очень способствует таким факапам. Hype driven development - штука злая. Нафиг бэкапалке именно протобуф, при том судя по всему использованный безбашенно? Ах, он крутой и им сам гугл пользуется? :)
> Т.е. у вас скрипты на питоне падают с трейсом на три страницы?
> Причем, все только из-за того, что вы так и не удосужились
> узнать, что у питона аж две ветки, зато ноете в каждой
> новосте с упоминанием питона?У питона две ветки, а реально в них еще с дюжину квазиполунесовместимых субдиалектов. Постоянно что-то несовместимо меняют и скрипты там и сям отваливаются. Что в 2.х что в 3.х.
> Ну, что тут можно сказать – о прямизне ваших рук, познаниях в
> этой области, как и твердости характера в упорном желании страдать, можно
> вполне слагать легенды!Я не понимаю почему спич про какую-то прямизну рук релевантен при обсуждении идеи раскатать бэкап.
>> И инструменты бэкапа на этом - вот уж нафиг.
> Вообще-то, задачи и цели у бэкапа разные бывают.И сношение с интимными проблемами скрипта и интерпретатора в них обычно не входит. И вот что-что а бэкапы совсем не то где греет душу даже минимальный шанс попасть на такие приключения.
Вы и ваши бэкапы будете ассимилированы.
All your back are belong to ups!
))))
Сегодня ваши фотографии забекапили, а завтра уже вас.))
В тексте новости не указано главное преимущество Borg перед Attic: последний уже несколько лет не развивается, что и послужило причиной форка (автор не принимал патчи и сам ничего не делал).> файлов с пустотами внутри
Устоявшееся выражение "sparse file" лучше не переводить.
> borg prun
Должно быть "prune".
> В тексте новости не указано главное преимущество Borg перед Atticпотому что это не преимущество.
> последний уже несколько лет не развивается
что вы хотите "развивать" - в бэкапе? (вот с этого места - могут быть и преимущества. Но чаще оказываются поломанные бэкапы старых версий, несовместимость со старыми системами и т д)
mount это вещь.
Круто, но добавили бы уже поддержку самой популярной платформы. Для бекапа хомячка много заморочек.
юзаю zbackup особых улучшений в borg не вижу, что бы начать пользоваться.