Какой архиватор лучше для бекапов

Посмотрел lz4 / lzf но там в опциях не нашёл как сделать исключение по маске при архивации

Ты архивацию с компрессией точно не путаешь? (путаешь. вопрос риторический.)

Bzip2 выбрал так как он лучше сжимает.

Выбирать bzip2 по своей воле в 2020 — самый дебильный выбор из всех возможных.

Если канал невыносимо узкий, то xz. Если нет, то zstd. Всё остальное бессмысленно.

Сжимается всё в один большой tar <…> Это всё хорошо и работает, но есть один маленький минус. Если нужно срочно достать какой-нибудь небольшой файлик из этого огромного бекапа, то придётся ждать часами.

Как там идиоматично делается у больших дядь в большом энтерпрайзе — не знаю, но буду оригинален: попробуй borg.

А вообще, вменяемых архиваторов с произвольным доступом в линукс так и не завезли.

squashfs, архиватор с произвольный доступом, который мы заслужили =)

то придётся ждать часами.

Я думаю, это из-за того что bzip2 фактически будет распаковывать в один поток. Есть

vitus@devuan:~/tmp$ apt search PBZIP2
Сортировка… Готово
Полнотекстовый поиск… Готово
pbzip2/stable 1.1.9-1+b1 amd64
  parallel bzip2 implementation

для ускорения сего действа. Попробуй может тебе даже такого ускорения хватит.

Что ты такой нетолерантный? Все лапочки veeam используют для бекапов, а ты…

переходи на borg

ставь готовые решения от proxmox, — там тебе и proxmox ve и proxmox backup.

лучше ты сам ничего накостыляешь. это раз.

два. если тебе надо бэкап системы, что смотри в сторону stateless-дистрибутивов, которые могут возвращаться в исходный вид нажатием одной кнопки reset, а вот тут вариантов немного, NixOS, что не всем подойдёт, либо же смотри мой Boobstrap с закатыванием уже _любого_ дистрибутива в SquashFS с последующим использованием с Overlay FS либо же загрузкой в SHMFS. это не бэкап системы в классическом его понимании, а ты каждый раз загружаешься заново в этот самый уже настроенный «бэкап».

бэкап данных, опять же, в случае установленных систем это лютый геморой, потому что данные у тебя размазываются по всему корню. я эту проблему решил и всё, что пишется поверх системы хранится в отдельной директории /mnt/overlayfs/rootfs-changes, ты её можешь любым удобным тебе образом сохранить, да хоть тупо через scp -r на другой сервер передать, да.

вопрос какой архиватор лучше, да пофигу. тебе сперва надо определиться, либо proxmox ve+backup, либо stateless. а там уже пофигу какой архиватор. ;)

Гм, концептуально.

А вообще, вменяемых архиваторов с произвольным доступом в линукс так и не завезли.

Чем плох dar?

Отрицательной распространённостью Вау, оказывается, завезли. Ну собственно см. выше.

Кстати

Современный архиватор-2016 (комментарий)

Лично я использую xz.

У меня lz4 все жмет на лету в zfs пулах. Вообще не парюсь с этими вашими архивами.

lrzip жжот жмёт.

У меня lz4 все жмет на лету в zfs пулах.

Не везде оно нужно. Где-то лучше без сжатия, а где-то можно и gzip прикрутить.

Где-то лучше без сжатия

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

Лишние потуги со стороны процессора же.

Зато мне не надо выбирать, что сжимать, а что нет

У меня для мультимедии отдельный сабвол без сжатия. А для конфигов — отдельный сабвол с gzip-сжатием.

Лишние потуги со стороны процессора

Все что быстрее калькулятора даже не заметит этого сжатия. Я специальных тестов не видел, но по отзывам 5-летней давности гигабитный трафик съедал всего 10% десктопного проца. А я вообще нагрузки не замечаю, тоже какие-то %%. По остальному можно глянуть https://catchchallenger.first-world.info/wiki/Quick_Benchmark:_Gzip_vs_Bzip2_vs_LZMA_vs_XZ_vs_LZ4_vs_LZO

У меня для мультимедии отдельный сабвол без сжатия

Аналогично.

Bzip2 100% не стоит использовать, он сливает более новым архиваторам по всем параметрам.

Произвольный доступ на чтение и запись противоречит самой идее компрессии.

Если компрессия не нужна, идеальный вариант - user space fs, её можно в отдельном файле держать.

ZPAQ

по отзывам 5-летней давности гигабитный трафик съедал всего 10% десктопного проца

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

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

zip или 7zip без tar

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

Среди крупняка у меня жмутся диски виртуальных машин. Все отлично. И сжатие хорошо помогает. Есть еще образы/дистры софта и игр, на них просто сжатие не работает, но фишка в том, что на несжимаемых данных нет видимого замедления. Просто не надо ставить нищебродский проц или разворачивать СХД на роутере, иначе и ручная архивация будет тормозной.

backuppc!

Если так любите самописные скрипты, то почему бы не .bz2.tar вместо .tar.bz2 ?

Среди крупняка у меня жмутся диски виртуальных машин.

Зойчемъ?! ZFS же умеет сабволюмы как сырые девайсы:

У меня так Alpine в bhyve живёт со своей разметкой.

lrzip

• Если использовать ZPAQ, то сжатие и особенно распаковка занимают очень много времени. Очень.
• Похоже, держит результаты в ОЗУ, поэтому требует не только много памяти для внутреннего состояния алгоритмов сжатия, но ещё и для результатов сжатия. Странно, что не сбрасывает результаты сразу на диск.
• Для LZMA нельзя выбрать режим 9e, как в xz, только 9, поэтому с помощью xz можно добиться меньшего размера. При этом распаковка будет достаточно быстрой.

для lrzip можно выбрать максимальное количество используемой памяти (что не отменяет долгой упаковки/распаковки)

Шел 2020 год, люди продолжали жать тарболы.

Они же права доступа не сохраняют.

Кстати, почему бы их не добавить в 7z? Если автор отказывается принимать, то форкнуть.

в zip можно сохранять

zstd - лучший вариант, быстр почти как lz4, жмет лучше gzip

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

Duply умеет так.

Помнится, ещё лет 10 назад в btrfs были эвристики, которые сами нормально решали, что жать, а что не жать. Вымерли? Не дошли до ZFS?

Помнится, ещё лет 10 назад в btrfs были эвристики, которые сами нормально решали, что жать, а что не жать.

Вот только оно нещадно разваливалось из-за смены погоды на Марсе. Вне зависимости от наличия/отсутствия сжатия.

Если кто-то считает что думать не нужно — пусть сдаст голову на нужды науки. Студенты-медики должны на чём-то анатомию изучать. ☺

Собственно, с Btrfs я на ZFS и свалил. А когда начали крылья подрезать, свалил с Linux за нормальной файловой системой.

Вымерли? Не дошли до ZFS?

Я не проверял. Просто не использую сжатие там где оно не нужно.

Лента магнитная, не?

Duply умеет так.

Он через duplicity работает, который через ещё пачку всякого работает (unix-way), а посему отдельные файлы достаёт долго.

Но duplicity вещь нормальная. Лет 7 инкрементальные бэкапы им делаются.

Надо хоть развернуть набэкапленное попробовать, а то, мож, и не работает уже?..

Помнится, ещё лет 10 назад в btrfs были эвристики, которые сами нормально решали, что жать, а что не жать.

Есть такое мнение об этом:

The «automatic compression detector» of btrfs is a total bullshit.
It just kills compression performance, almost at random.
The «detector» itself is very poorly done, and wrongly believes it can determine compressibility from some trivial-to-grab statistics.
That couldn’t be more wrong.

Besides, and that’s the funny point, modern compressors such as LZ4, LZO and Zstandard have built-in skippers which know when things are not compressible and just intelligently skip past the bad section.
The only case for this external detector is zlib, but it’s wrongly applied to all !

Try it on zstd, it skips the incompressible parts at > 1 GB / s !
That’s faster than the processing of this «compressibility detector».

Bottom line : on btrfs, always use «force compress» on any partition with anything else than zlib.

Из комментариев на phoronix

Лол. Он явно скипает весь файл после несжимаемого начала, но читать весело.

Если канал невыносимо узкий, то xz. Если нет, то zstd. Всё остальное бессмысленно.

На сколько я помню на высоких уровнях сжатия zstd сжимает лучше xz. Правда проц при этом жрёт нещадно

Надо хоть развернуть набэкапленное попробовать, а то, мож, и не работает уже?..

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

P.S. Время от времени, т.е. регулярно, „развернуть набэкапленное“ это обязательная практика. Сколько народу попалось на том, что бэкап вроде бы есть, а восстановиться из него нельзя — не перечесть.

Да я знаю что bzip2 умеет распаковывать файлы выборочно, но по времени это займёт столько же как распаковать целиком весь архив.

man ratarmount

Обойти архив ему нужно всего один раз, чтобы сформировать sqlite-индекс.

Поддерживаются голые тарболы, .tar.gz и .tar.bz2. Вот .tar.xz, например, нет. Так что Вам повезло с выбором ;)

Выбирать bzip2 по своей воле в 2020 — самый дебильный выбор из всех возможных.

Чисто для моей осведомлённости: а xz умеет жать из потока? Ну чтобы можно было сказать что-то вроде cat file | xz > file.xz

Конечно.

А библиотека на подобие libbz2 у него есть?

liblzma называется.

Спасибо.

man ratarmount

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

P.S. Время от времени, т.е. регулярно, „развернуть набэкапленное“ это обязательная практика. Сколько народу попалось на том, что бэкап вроде бы есть, а восстановиться из него нельзя — не перечесть.

Давным давно, когда работал в ЕМС, решил и себе дома собрать конфигурацию на Fiber Channel. Глючный драйвер FC регулярно рушил таргет, у инициатора ФС, бывало, портилась, и я бэкапы разворачивал.

Потом плюнул, старый пылесос на двух Penryn отправил на пенсию, отдельный NAS-box туда же, винты воткнул в халявную мамку с IvyBridge (питание сгорело, отдали, починил), и аптаймы больше года стали, между ребутами в новое ядро.

От выключенных двух L5420 энергопотребление дома на 20% снизилось. Вот так вот.

Но ведь один раз ему всё же придётся сделать некий индекс архива?

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