LINUX.ORG.RU

ZBackup 1.0

 , , , zbackup


11

5

Вышел первый публичный релиз утилиты резервного копирования с глобальной дедупликацией zbackup. Программа находит области, содержащие одни и те же данные во всех сохраняемых в неё образах, и сохраняет их только один раз. Данные затем сжимаются и, по желанию, шифруются. Оптимально подавать на вход один большой .tar файл, содержащий полный бэкап системы, или же непосредственно сырой образ диска, подлежащий резервному копированию - программа не пытается интерпретировать формат файла, а просто дедуплицирует любой полученный от пользователя. Дедупликация глобальна - данные, полученные в разное время из разных образов, сохраняются только один раз. За счет этого достигается высокая инкрементальность и низкие затраты дискового пространства.

Для достижения данной функциональности программа использует кольцевую хэш-функцию со скользящим окном для побайтной проверки на совпадение с уже существующими блоками данных, наподобие того, как это реализовано в программе rsync.

Программа имеет следующие особенности по сравнению с другими ей подобными:

  • Многопоточное сжатие данных с помощью алгоритма LZMA;
  • Встроенное в программу шифрование AES;
  • Возможность в будущем удалять старые данные из хранилища;
  • Использование 64-битной кольцевой хэш-функции, что позволяет достичь гораздо большей масштабируемости по сравнению с обычно использующимися 32-битными;
  • Написана на C++ с минимальными зависимостями;
  • Безопасна для использования на реальных данных. Так как программа никогда не модифицирует существующие файлы, добавляя только новые, достаточно после сохранения бэкапа просто восстановить его обратно в /dev/null. Для каждого бэкапа сохраняется его SHA256-сумма, проверяемая при восстановлении. Если восстановление прошло успешно, значит, оно будет так же успешно и в будущем. Объем кода, который осуществляет подсчет SHA256-суммы на входе и сверяет его на выходе очень мал и легко поддается аудиту.

Стоит отметить, что данные подавать в программу надо в несжатом и нешифрованном виде (например, то, что выдает tar c), иначе дедупликацию произвести не получится. Лучше всего подавать большие файлы типа несжатых .tar или сырых дисковых образов. Результирующий репозиторий можно копировать на другие машины с помощью rsync, или же хранить в любых облачных хранилищах, в которых можно хранить обычные файлы. Так как программа никогда не модифицирует уже существующие файлы, последнее довольно удобно - достаточно просто не копировать те файлы, которые уже есть на удаленном хранилище. А встроенное шифрование позволяет не заботится о конфиденциальности хранимых там данных.

В заключение можно добавить, что автор использовал предыдущую версию программы на реальных данных уже больше года и не имел никаких проблем. Что касается эффективности дедупликации, например, .tar-файл с ежедневным домашним бэкапом занимает 25GB, а 185 таких бэкапов за прошедший год в хранилище zbackup занимают суммарно только лишь 18GB, то есть даже меньше, чем один ежедневный образ. При этом, разумеется, можно восстановить любой из этих образов обратно байт в байт так, как они были изначально созданы.

Домашняя страница программы: http://zbackup.org/

Страница разработки на github: https://github.com/zbackup/zbackup/

>>> Версия 1.0 (tar.gz)

★★

Проверено: Shaman007 ()
Последнее исправление: ikm (всего исправлений: 1)
Ответ на: комментарий от iron

ну и понятное дело инкрементальный бекап. Без возможности инкрементировать бекап, к сожалению, пока не могу юзать это в продакшине. Так же совсем не лишним будет возможность бекапить базы мускуля и git репы.

Бэкап инкрементальный всегда - на то дедупликация и нужна. Бэкапить базы и репы можно, сам бэкаплю (для git-репов рекомендуется прописывать core.compression = 0 в .git/config, чтобы дедупликация работала по всему .git).

ikm ★★
() автор топика
Ответ на: BUP от mmarkk

Да, с него всё и началось. Однако их дизайн не позволяет удалять уже существующие данные, что не устраивало категорически.

ikm ★★
() автор топика
Ответ на: комментарий от mmarkk

И как решили?

В первой версии zbackup каждый блок просто хранился в отдельном файле - соответственно, вопрос удаления проблемой не был. В текущей, чтобы уменьшить оверхед файловой системы и улучшить качество сжатия, блоки группируются в более крупные бандлы, но идея в общем та же самая остается - при удалении данных, когда бандлы пустеют, они перепаковываются в новые.

ikm ★★
() автор топика
Ответ на: комментарий от ikm

Да, с него всё и началось. Однако их дизайн не позволяет удалять уже существующие данные, что не устраивало категорически.

zbackup вроде тоже не удаляет старые данные?
There's no option to delete old backup data yet. The possibility is all there, though. Someone needs to implement it.
Н

Marvin
()
Ответ на: комментарий от mmarkk

Но git rebase -i (с удалением коммита) и git gc кагбе это уже всё делают...

А можно и вовсе заново все бекапы перепаковывать, чем плохо? В bup за одну сессию пишется один пак - соответственно, при его удалении все данные, которые используются в других сессиях, придется переписать отдельным. Короче, если вам нравится, пользуйтесь на здоровье.

ikm ★★
() автор топика
Последнее исправление: ikm (всего исправлений: 1)
Ответ на: комментарий от Marvin

zbackup вроде тоже не удаляет старые данные?

Дизайн позволяет. Код не написан. Работы там на день. С меня её уже хватит. Хотите, чтобы была фича, пишите, делайте pull-request'ы. Сам же я её напишу в тот момент, когда уткнусь в её необходимость лично для себя, что пока что не случилось. А вот не иметь возможность ротации в принципе, by design - в системе бэкапов считаю неприемлемым.

ikm ★★
() автор топика

Объясните, как с помощью zbackup делаются бекапы?

Надо как и в rsync запускать rsync-сервер на машине с хранилищем бекапа, или механизм другой?

Xintrea ★★★★★
()
Ответ на: комментарий от Xintrea

Бекапы делаются на локальной машине, потом rsync-ом или как-либо по-другому результирующий репозиторий копируется/синхронизируется на другую машину.

ikm ★★
() автор топика
Ответ на: комментарий от Xintrea

В rsync нет дедупликации. Она существенно экономит место на диске и время записи. Кстати в промышленной системе резервного копирования HP StoreOnce D2D используется подобный принцип как в zbackup - медиа сервер проводит дедупликацию и только потом записывает данные на систему хранения со скоростью 100ТБ/час.

Marvin
()

Попробовал на 3 примерно 200 гиговых бэкапах - сохранилось, хотя и не быстро, я обрадовался, решил развернуть, получил:

libprotobuf ERROR google/protobuf/io/coded_stream.cc:156] A protocol message was rejected because it was too big (more than 67108864 bytes). To increase the limit (or to disable these warnings), see CodedInputStream::SetTotalBytesLimit() in google/protobuf/io/coded_stream.h.

anonymous
()
Ответ на: комментарий от anonymous

Попробуйте версию из git - там вопрос в одной строчке был. Должно всё теперь развернуться.

Вообще лучше создавать issues на github, когда проблемы находятся.

ikm ★★
() автор топика

Спасибо большое, утащу к себе. Но есть пару вопросов:

  1. Какая производительность? Сильно ли жрет ресурсы?
  2. Есть ли в планах кроме lzma прикрутить lzo сжатие?
zunkree
()
Ответ на: комментарий от zunkree

Какая производительность? Сильно ли жрет ресурсы?

Проще попробовать. В основном ресурсы любит алгоритм lzma.

Есть ли в планах кроме lzma прикрутить lzo сжатие?

lzo, gzip... все, что будет в pull request-ах :)

ikm ★★
() автор топика
Ответ на: комментарий от ikm

Попробовал, lzma действительно жрет как не в себя. Так что будет время — поковыряю C++ для lzo. Спасибо большое еще раз.

zunkree
()

а развитие графического интерфейса со справкой на русском языке планируется?

dr04 ★★
()

Запилил PKGBUILD в AUR. Может кому пригодится.

unikum ★★★★★
()
Ответ на: комментарий от cvv

lzma? а я думал - дедупликация ...

Когда бОльшая часть данных уже есть в базе, бэкапы делаются довольно быстро. Когда нет, тогда уже включается lzma для упаковки новых, что, конечно, процесс замедляет - однако хорошо параллелится по всем ядрам. Вообще, на каждый байт входных данных приходится одно умножение с несколькими сложениями и сдвигами для обновления Rabin-Karp, и, если уже набрался полный блок, один O(1) лукап в хэш-таблице. Так что сама дедупликация по процессорному времени довольно недорогая.

ikm ★★
() автор топика
Ответ на: комментарий от dr04

а развитие графического интерфейса со справкой на русском языке планируется?

Это вопрос к общественности :)

ikm ★★
() автор топика

Испытал на ежедневных бэкапа, пять файлов от 196 до 202 гиг, т.е. примерно терабайт - получилось 21 гиг итого. В общем доволен - места не серваке не очень много, но добавляется долго, 200 гиг 460 минут. Правда запускал на слабой машине, два ядра, как-то никто не думал, что от сервера бэкапов нужно особое быстродействие ;-)

anonymous
()
Ответ на: комментарий от anonymous

добавляется долго, 200 гиг 460 минут.

Там вообще должна быть заметная разница между первым файлом и последующими, поскольку в последующих бОльшая часть данных уже хранится, и сжимать заново её не надо.

ikm ★★
() автор топика
Ответ на: комментарий от ikm

Есть разница, именно такая, но 3 файл добавлялся

real    287m59.081s
user    72m20.432s
sys     12m13.902s

4-й дольше

real    470m26.717s
user    571m17.958s                              
sys     35m20.786s
5-й
real    463m10.665s
user    599m32.379s                                      
sys     32m5.578s

До того не время не мерил, проц: Pentium(R) Dual-Core CPU E5400 @ 2.70GHz

anonymous
()
Ответ на: комментарий от anonymous

Судя по большой разнице между real и user/sys для третьего файла, производительность там уперлась в диск. Интересно было бы посмотреть time cat backup3 > /dev/null

Что касается других, то там явно были новые данные. Судя по разнице между 3-м и последующими, там уже участвовали два ядра - могу предположить, что бОльшую часть времени занял lzma. Вполне вероятно, что если перейти на использование gzip (zlib), производительность станет такой же, как и в случае для третьего бэкапа. Остается дождаться трехсот строчек кода от желающих их написать, поскольку мне хотелось бы участия других людей в проекте тоже.

ikm ★★
() автор топика
Ответ на: комментарий от ikm

производительность там уперлась в диск

Возможно, ночью было, в это время как раз новые бэкапы пишутся.

anonymous
()
Ответ на: комментарий от anonymous

А что Вы думаете по поводу lz4?

Иметь выбор - всегда хорошо :)

Вообще, мне кажется, что использование алгоритма сжатия с пропускной способностью, превышающей скорость чтения с диска на порядок, большого смысла не имеет, поскольку в этом случае он всё равно будет будет простаивать бОльшую часть времени, а дисковое пространство из-за худшей компрессии будет расходоваться зазря. Тем не менее, ситуации бывают разные, так же, как и пропускные способности, так что я в конечном итоге за включение любых алгоритмов сжатия, а там пусть пользователь пробует и решает, какой выбрать.

ikm ★★
() автор топика

Если это смог написать один человек, то почему ни одна компания не создала подобное?

kerneliq ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.