Решено:ищу адекватный архиватор

[folibis]

На сервере делаются бекапы сайтов.
Все очень просто. папка сжимается tar | bzip2, проверяется MD5, если он отличается от такого же на сервере то архив выгружается на сервер, иначе игнорируется.
С недавних пор сайтов стало больше, бекап стал занималь больше часа и потреблял слишком много ресурсов, из-за чего вылетали некоторые процессы, в частности cron (Cannot allocate memory: fork: Unable to fork new process)
Было решено перейти на менее ресурсоёмкий архиватор. Пробовал 7za, pbzip2. Оказалось что все архиваторы кроме bzip2 имеют какую то нелинейную зависимость размера архива от исходного файла. Одна и та же директория архивированная с разницей в 12 часов дает разный MD5. Файлы идентичные, изменений никаких не было. Как результат - на FTP сервер выгружаются все архивы, даже те которые не были изменены, что меня совсем не устраивает.
Нужен совет - адекватный архиватор, или как побороть эту проблему.

Вот примерно что происходит:

Время архивации_Размер директории__tar______7z______pbzip
--------------------------------------------------------------------
вчера___________10609217___________12718080_5007014_2987662
сегодня_________10609217___________12718080_5007112_2987744

Команды использовались в таком виде :
tar --exclude='cache/*' --exclude='stat/*' -cPf - /path-to-dir/ | pbzip2 -c > /file.tar.bz2
tar --exclude='cache/*' --exclude='stat/*' -cPf - /path-to-dir/ | 7za a -si /file.tar.7z 2>/dev/null

[KiWi]

С недавних пор сайтов стало больше, бекап стал занималь больше часа и потреблял слишком много ресурсов, из-за чего вылетали некоторые процессы, в частности cron (Cannot allocate memory: fork: Unable to fork new process)

Сжимать стоит самим tarом, раз уж начали его использовать.
Он точно будет это делать практически на лету без дикого количества памяти.

Оказалось что все архиваторы кроме bzip2 имеют какую то нелинейную зависимость размера архива от исходного файла.

Очень может быть, никто о линейности не говорил.

Одна и та же директория архивированная с разницей в 12 часов дает разный MD5.

Учитывая, что в примерах pbzip -- очень может быть, что один и тот tar-архив(то есть одинаковый набор файлов с одинаковыми аттрибутами типа времени модификации с файлами, следующими в том же порядке) будет разным -- ненулевая(надо смотреть как оно параллелится): где-то что-то выполнилось на 1 тик быстрее или медленнее и результат будет другим.

Файлы идентичные, изменений никаких не было.

А точно одинаковые? Может, всё же где-то поменялся mtime? Права? Можно распаковать и сравнить rsyncом, например.

Нужен совет - адекватный архиватор, или как побороть эту проблему.

Использовать для резервного копирования инструменты, созданные для этого, а не архиваторы.
bacula, например.

[folibis]

Сжимать стоит самим tarом, раз уж начали его использовать.

Как вариант, сжимать tar-ом, сверять контрольную сумму, затем дожимать pbzip-ом. Но хотелось бы все таки сделать это нормальным способом.

[drBatty]

се очень просто. папка сжимается tar | bzip2, проверяется MD5

жуть. зачем bzip тут?? в идеале надо считать md5 ФАЙЛОВ. Никто не гарантирует даже порядок этих файлов, т.ч. даже если файлы будут сжаты в ином порядке, md5 будет другой. Не говоря уже об атрибутах (atime, и проч.).

В любом случае, md5 следует считать ДО сжатия, а не после.

Пробовал 7za, pbzip2. Оказалось что все архиваторы кроме bzip2 имеют какую то нелинейную зависимость

что вы хотели? Простой пример: вам надо вычислить
1) 2+2=?
2) 3+3=?
3) 12+17=?
и записать в файл. Вот так:

Код: Выделить всё

1-4
2-6
3-29

Всё будет прекрасно работать, пока вы не используете многопоточность. Как только вы про неё узнаете, всё станет уныло, ибо файл

Код: Выделить всё

2-6
1-4
3-29

тоже допустим, и вы будете равновероятно получать оба этих файла. Несмотря на то, что оба файла правильные, их md5 разная. Возможны и другие файлы, которые тоже разные, но правильные.

[Bizdelnick]

Может есть смысл отказаться от tar'а? Делайте раз в неделю, когда нагрузка минимальная, полные бекапы dar'ом, всё остальное время - дифференциальные бекапы.

[SLEDopit]

Посмотрите на другие бэкапные решения, например rsnapshot.

[folibis]

Решил сначала проверять MD5 всех файлов в директории, затем, если не совпадает, делать архив и выгружать его на сервер.
Получилось даже лучше - не нужно делать архив чтоб получить его MD5, экономия ресурсов все таки.
команда такая:

Код: Выделить всё

MD5=`find ${DIR}  -type d \( -name stat -o -name cache \) -prune -o -type f -name "*" -exec md5sum {} + | awk '{print $1}' | sort | md5sum | awk '{print $1}'`

Я прнимаю что лучше было бы использовать какое то комплексное, готовое решение, но у меня уже все настроено и отлажено. Бекапы со многих серверов скидываются на один FTP. Скрипт прекрасно делал свою работу. Не хотелось что то кардинально менять из-за такой небольшой проблемы.
Теперь все ок, и даже стало лучше, как мне кажется.
Всем спасибо за участие!

[drBatty]

>не нужно делать архив чтоб получить его MD5, экономия ресурсов все таки.

ещё большая экономия получится, если вы будете бекапить только новые файлы, и файлы с изменившейся md5.

[azsx]

drBatty то есть архиваторы 7za, pbzip2 используют многопотоность?

[lastpriot]

2 azsx:
да, эти архиваторы используют многопоточность, но от этого результат НЕ меняется

[azsx]

lastpriot меня интересует не столько процесс проверки мд5, сколько скорость архивации. Ежесуточно создаются файлы от 4 до 20 гб (сейчас три файла). Их надо загнать в архив. Интересует наиболее скоростной архиватор. Степень сжатия желательна не ниже среднего, таким образом хочется, чтобы архиватор использовал по максимуму ресурсы десктопа.
У меня: дебиан 6, i5-3750, физически 2 разных винчестера (с одного берется оригинал, на другой архивируется), оперативной сейчас около 10 гб свободной из 16.

[lastpriot]

разбивать большие файлы на несколько меньших

[drBatty]

7za, pbzip2 используют многопотоность?

да.

да, эти архиваторы используют многопоточность, но от этого результат НЕ меняется

вы заблуждаетесь. Результат упаковки+распаковки не меняется, что не мешает меняться самой упаковки. файл file.gz отличается от файла file.bz2, даже если исходный file один и тот же. многопоточный архиватор разделяет задачу на подзадачи, а потом ждёт, когда подзадачи выполняться. Как только выполнится первая подзадача, её результат записывается на диск. Какая именно подзадача выполнится первой - зависит от случайных причин.

Их надо загнать в архив. Интересует наиболее скоростной архиватор.

tar без сжатия.

Степень сжатия желательна не ниже среднего, таким образом хочется, чтобы архиватор использовал по максимуму ресурсы десктопа.

тогда bzip2 если память жалко.

оперативной сейчас около 10 гб свободной из 16.

...а если не жалко - используйте xz. Вы можете попробовать использовать многопоточность, несмотря на то, что сам по себе xz её НЕ использует - сжимайте свои 3 файла одновременно, а уж потом - используйте tar (можно даже сразу слить все 3 потока в один, но это сложнее).

Вот только это всё НЕ даст результата. И в теории и на практике. А причина очень проста - у вас многоядерный CPU, а для сжатия нужно несколько процессоров, каждый со своей персональной памятью. Потому - жмите в один поток программой xz.