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

Внести вклад Функция
1

Процесс резервного копирования создаёт tar-архив, а затем сжимает его с помощью gzip. В tar-архиве содержится два типа данных: уже сжатый дамп SQL и содержимое папки uploads (если это было запрошено). В моём случае каждый файл в uploads уже сжат: gz, gzip, gif, jpeg, png, zip. Поэтому финальное сжатие gzip даёт прирост лишь в 1% по размеру.

Я считаю, что было бы лучше снизить требования к свободному месту.

В одной из тем 2016 года упоминается отключение сжатия резервных копий, но тогда дамп SQL ещё не был сжат, что меняло баланс компромиссов.

Добавить опцию отключения сжатия резервных копий

11 лайков
'Download remote images to local' disabled despite enough free disk space
Can I just tar the whole /var/discourse and run it on a new server?
Any way to disable gzipping backups?
Migrate from gz compression to zstd for backups
Backup requires 2x disk space - could the process be improved?
2

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

13 лайков
3

Отлично, @gerhard!

2 лайка
4

Есть ли какие-то новости по этому вопросу? Спасибо.

1 лайк
5

Не хочу надоедать, но как продвигается работа?

6

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

4 лайка
Add option to disable backup compression
Backup requires 2x disk space - could the process be improved?
Migrate from gz compression to zstd for backups
7

Если я напишу патч, который будет принимать значение 0 в параметре уровня сжатия для отключения gzip, примете ли вы его?

1 лайк
8

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

9

Я стремлюсь сэкономить время процессора. На самом деле я думал использовать 0 как флаг, который изменит путь выполнения кода, чтобы оно не сжимало с помощью gzip (к сожалению, ноль, насколько мне известно, не является допустимым уровнем сжатия, поддерживаемым во всех версиях gzip).

10

Хм, это мне совсем не поможет! (Точно так же и для других, у кого возникла та же проблема с нехваткой места на диске.)

Если бы использовался tar, его можно было бы применять с опциями z или j. Если бы использовалась подсистема, вывод tar можно было бы передать через конвейер в gzip. Но я думаю, что на самом деле могут использоваться некоторые функции более высокого уровня Ruby.

1 лайк
11

кашель

2 лайка
12

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

Из tar --help

-a, --auto-compress использовать суффикс архива для определения компрессии
-z, --gzip, --gunzip, --ungzip фильтровать архив через gzip

1 лайк
13

Действительно ли флаг -z выполняет сжатие на месте? Я всегда думал, что gzip запускается только после завершения создания архива tar.

14

В данном случае — ошибочно! Байты, представляющие несжатый tar-файл, никогда не записываются на диск.

2 лайка
15

Вы имеете в виду, что мы можем просто добавить
"--gzip",

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

1 лайк
16

Да, это изменение в команде tar.

1 лайк
17

Похоже, что ещё лучший вариант — --zstd, но тогда в образе Docker также должен быть установлен пакет ‘zstd’.

2 лайка
18

Возможно, более подходящий подход, который мог бы упростить задачу, — это возможность работать с существующими резервными копиями, которые могут иметь расширение *.gz или *.zst, используя автоматическое определение tar:

tar --auto-compress -c -f ../file.tar.gz .
tar --auto-compress -c -f ../file.tar.zst .

Более важно, конечно, при распаковке, когда мы можем не знать, с чем именно столкнёмся.

В настоящее время код на Ruby выполняет множество операций, которые может выполнить сам tar. Надеемся, это позволит упростить процесс, а не усложнить его.

2 лайка
19

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

(Если бы zstd использовался и для дампа SQL, в моём случае он был бы на 10% меньше.)

1 лайк