FastNetMon

пятница, 18 апреля 2014 г.

librsync и утилита rdiff - все что Вы НЕ знали о резервном копировании

Данный пакет утилит крайне полезен. Чем? В первую очередь, очень высоким в отличие от rsync уровнем контроля за тем, что же делается :)

Вот, например, мы можем взять 8 гигабайтный бинарный файл (созданный из данных за 8е апреля) и сгенерировать для него signature файл вот так:
time rdiff signature 56640_root_hdd.gz_84cab040-bed0-11e3-b5aa-80259087d80c /root/56640.signature

real    0m42.922s
user    0m34.305s
sys     0m2.209s

Займет он при этом 47 мегабайт всего-то. Что такое signature файл? Грубо говоря, это файл с полной информацией о блоках данного файла и их хэш суммах. Для чего это может понадобится? Об этом позже.

Итак, допустим у нас есть актуальная (за 18е апреля) копия данного файла (это НЕ архив, это просто большой файл с бинарными данными).

Итак, мы хотим сделать бинарный патч между версией от 8е апреля и версией за 18е. Нужен ли нам весь 8гб дамп за 8е апреля? Не-а :) Достаточного его signature файла!

Итак, создаем инкрементальный бэкап не имея полного бэкапа на руках (вообще!):
time rdiff delta /root/56640.signature /vz/tmp/56640.hdd /vz/tmp/56640_diff_between_8_and_18_april.rdiff

И на выходе мы получим дельта-файл между бэкапами за 8е и 18е апреля :)


Но есть одно но, ОН ОЧЕНЬ МЕДЛЕННЫЙ:
real    13m27.094s
user    13m14.457s
sys    0m9.089s
Но при этом бесконечно радует размер файла инкремента:
ls -alh /vz/tmp/56640_diff_between_8_and_18_april.rdiff
-rw-r--r-- 1 root root 447M Апр 18 00:37 /vz/tmp/56640_diff_between_8_and_18_april.rdiff

Теперь попробуем обратный процесс создание полного бэкапа за 18е апреля из дельты + бэкапа за 8е.

Эти тесты я не уверен, что проведу сегодня, так что пока сделаем лишь чексуммы:
sha1sum /vz/tmp/56640.hdd
1580e28b7c23f390e02c30d62f10971a77b9ace8  /vz/tmp/56640.hdd
Также об ускорении. Решил попробовать увеличить блок обработки до 1 мегабайта. Для этого нужно регенерировать signatures файл:

rdiff --statistics  --block-size=1048576 signature 56640_root_hdd.gz_84cab040-bed0-11e3-b5aa-80259087d80c /root/56640.signature
Запускаем создание дельты снова:

 time rdiff --statistics  --block-size=1048576 delta /root/56640.signature /vz/tmp/56640.hdd /vz/tmp/56640_diff_between_8_and_18_april.rdiff
Он сразу сообщит, что используется на порядок меньше блоков (стандартный блок - 2048 байт):

rdiff: loadsig statistics: signature[7938 blocks, 1048576 bytes per block]
Ура! Победа :)
real    2m30.670s
user    2m17.618s
sys    0m10.665s
Но не во всем, сам дельта файл оказался крайне огромный:
ls -alh  /vz/tmp/56640_diff_between_8_and_18_april.rdiff
-rw-r--r-- 1 root root 3,9G Апр 18 01:26 /vz/tmp/56640_diff_between_8_and_18_april.rdiff
Так что с оптимизацией тут нужно быть поосторожнее :(


2 комментария :

  1. Теперь ясно, почему apt так долго обновляет кэш репов с сорсами.

    Я в своё время курил xdelta. Там фишка в объединении патчей и сжатии.

    ОтветитьУдалить
    Ответы
    1. Да, круто! xdelta есть в репах :) Но мне хочется, чтобы генератор работал не в режиме: сравнить файл1 файл2, а в режиме сравнить чек_сумма_файла_1 файл_2. Так как у меня в одном месте нет обоих файлов.

      Удалить

Примечание. Отправлять комментарии могут только участники этого блога.