Почему архиваторы не эффективно сжимают одинаковые файлы?

Question

[van000]

При попытке сжать большие (~2Гб) файлы. Это backup postgresql базы данных, его делаю так: pg_dump -F c -b -U postgres -f 1 MyDB), но для чистоты эксперимента я взял 2 одинаковых.

[user@comp test_compress]$ md5sum 1 2 
8b6582a7fa0250692c9c0e1747878aa1  1
8b6582a7fa0250692c9c0e1747878aa1  2

[user@comp test_compress]$ du -sh *
1,8G	1
1,8G	2

При добавление их в архив tar:
[user@comp test_compress]$ tar -cf all.tar 1 2
и последующего сжатия (пробовал gzip, xz и bzip2) размер не уменьшается (ожидал увидеть 1.8, но не как не 3.5, ведь фалы одинаковые)

[user@comp test_compress]$ du -sh all*
3,6G	all.tar
3,6G	all.tar.bz2
3,5G	all.tar.gz
3,5G	all.tar.xz

В чем причина, и как можно эффективного сжимать близкие по содержимому большие файлы?

Comments

[Adamos]

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

[Valentin Barbolin]

Если так?
tar -zcf all.tar.gz 1 2

[Melkij]

мимоходом хочу обратить внимание, что pg_dump -F c сжат сам по себе.

[mayton2019]

Melkij, это похоже правильный ответ. Я сделаю +1. Положи в ответы.

[van000]

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

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

Вот мне и интересно, может кто-то уже задавался этим вопросом, и имеется опыт.

[Adamos]

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

[pfg21]

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

[chupasaurus]

Adamos, Потребуются возвратно-поступательные упражнения с этими ФС.

[Adamos]

chupasaurus, ну, у ТС как раз бодро стоит вопрос.

[chupasaurus]

Adamos,

места предостаточно и сама база не очень большая

не сказал бы

[shurshur]

van000, в данном случае большая ошибка считать, что архиватор реально вычисляет повторения. На самом деле нет.

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

[freeExec]

shurshur, ну почему же, надо просто использовать архиваторы, которые позволяют указать размеры словарей. Тот же 7Z позволяет (судя по гуишной оболочке) задать размер словаря в 1.5Гб

[Adamos]

freeExec, и уронить VPS-ку, на которой вы захотите распаковать этот архив? ;)

[freeExec]

Adamos, и что? важно же сжатие, за это надо платить памятью.

[Adamos]

freeExec, особенно если ее физически нет.

[mayton2019]

В чем причина, и как можно эффективного сжимать близкие по содержимому большие файлы?

Несколько лет назад я интересовался таким подходом. Взять два бэкапа БД и выявив различия в блоках сделать - некое сжатие на основе дедупликации.

Пробовал утилиты наподобие bsdiff
bsdiff: usage: bsdiff oldfile newfile patchfile
но они работают очень медленно т.к. расчитаны не на бэкапы баз а на изготовление бинарных патчей к
приложениям. Например там поправить 2 байтика в exe-шнике размером 50 Мб - это как раз самое то.

Попробуйте может вам способ подойдет. Но мне кажется что bsdiff не знает с чем имеет дело и поэтому
работает на уровне байтов хотя для бэкапов Postgres можно было искать различия на уровне 4-К страничек
или что-то в этом роде.

Опять-же такая природа может быть характерна для PG датафайлов но никак не для сжатых дампов. После
сжатия подобная блочная структура будет уничтожена.

Поэтому в идеале нужно делать копию дата-файлов. Потом блочый bsdiff. И только потом сжатие дельты
и сжатие первой копии.

[shurshur]

freeExec, я в жизни неоднократно забивал/подбивал гвозди или выкручивал шурупы пассатижами, но это же слегка неправильный способ использования инструмента, да?

А в задаче автора эти гигантские словари ещё и не помогут, так как вряд ли эти полтора гига будут одинаковыми каждый день до байтика. А если даже да, то проще уж тогда считать md5 архива и вместо очередного бэкапа класть текстовый readme.txt "сегодня ничего не поменялось".

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

[Everything_is_not_so_bad]

Melkij,

pg_dump -F c сжат сам по себе

каким алгоритмом сжатия? Gzip?

[Melkij]

Román Mirilaczvili, zlib

Answer 1

[ky0]

Хотите эффективно сжать бэкап - делайте не -Fc (который кое-как сжат сам по себе - поэтому и ваши архиваторы не осилили), а -Fp - и натравливайте на получившееся что-нибудь типа xz -9.

Comments

[Everything_is_not_so_bad]

Можно отметить решением

Answer 2

[4144]

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

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

Comments

[Everything_is_not_so_bad]

Для примера:

pg_dump -Ft $POSTGRES_DB -U postgres | zbackup <опции> backup /path/to/zbackup/repo/backups/<любое имя папки>/pg.dump-`date '+%Y-%m-%d'`.tar.zbk

Answer 3

[vadimr]

Как архиватор поймёт, что это одинаковые куски? Ему нужно для этого проанализировать все частичные совпадения вплоть до 1.8 гигабайт, что совершенно неэффективно. Словарь для элементов такого размера построить не представляется возможным.

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