Странная реализация tar backup

[clayrabbit]

Господа разработчики, может я чего-то не понимаю, но из каких таких религиозных соображений скрипт бэкапа выполняет сначала tar а затем gzip требуя для создания файла бэкапа свободное место в размере "несжатая копия"+"сжатая копия", тогда как достаточно было бы выполнять tar сразу со сжатием на лету, чтобы для успешного создания бэкапа требовалось бы _в разы_ меньше места (в размере лишь "сжатой копии").
(Не говоря уже об уменьшении объемов бессмысленной записи временных данных на диск.)

[xlandhost]

скрипт создания бэкапа очень простой
подправь и выложи для народа

[skurudo]

Никакой особой избыточности или огромного оверхеда не видно.

Активно и подробно разбиралось вот в этой теме:
viewtopic.php?f=28&t=3655

Прошу ознакомиться.

[clayrabbit]

Прошу ознакомиться.

Ознакомился. Ну там в основном структура обсуждается, тут вопрос немного другой.
Просто клиент обратился с проблемой - бэкап не работает. У него 7гиг почты и 7гиг места свободного. Казалось бы должно хватать - ан нет. Скрипту, чтобы забэкапить эту почту требуется 7+3.5гига, в результате аккаунт не бэкапится совсем. А если бы просто использовали опцию z в команде tar или пайп tar | gzip, то эти 7гиг для хранения временного tar'а были бы вовсе не нужны и хватило бы 3.5гиг свободного места, и кстати это быстрее чем писать 7гиг tar а потом его читать и паковать gzip.
Если же данные совсем нежмущиеся, то для создания бэкапа потребуется свободное место в двукратном размере.

[clayrabbit]

Хотелось бы еще раз поднять этот вопрос.
Насколько я понимаю, в текущей реализации бэкапа одни и те же данные пишутся на диск 3! раза.
(1 раз несжатые данные пишутся в tar, потом пишутся еще раз cо сжатием в gzip, и затем все архивы объединяются в 1 общий tar.)
Тогда как при адекватной реализации достаточно было бы скопировать данные 1 раз со сжатием на лету.

Помимо того, что текущая реализация бэкапов требует для работы достаточно большого объема свободного места на сервере, надо ли говорить о том, что происходит с IO на ноде, когда десятки VDS начитают в 5:10 ночи трижды записывать все свои данные на диск, а также во сколько раз это ускоряет износ SSD-дисков?

[PeaceData]

Да уж, лучше взять FreeNAS и настроить бэкап задание по протоколу Rsync, тогда будут копироваться только новые писма. Создание задания https://doc.freenas.org/9.10/tasks.html#rsync-tasks
На бэкап сервере можно включить быстрое сжатие lz4 и периодические снапшоты https://doc.freenas.org/9.10/storage.ht ... shot-tasks https://doc.freenas.org/9.10/storage.ht ... te-dataset

[clayrabbit]

Добавил задачу https://bugs.vestacp.com/issues/577

Путем несложных правок можно пропустить первый этап создания несжатого .tar и создавать сразу сжатый tar.gz
https://github.com/serghey-rodin/vesta/pull/1254/

Чтобы можно было SQL-дампы жать на лету придется видимо еще mysql_dump() и psql_dump() в func/db.sh поправить
https://github.com/serghey-rodin/vesta/pull/1255/

[Stesh]

Добавил голос к задаче.

[gecube_ru]

Я думаю, что нам действительно нужна вторая схема бекапа.
Та которая есть - годится для маленьких проектов и/или с большим количеством свободного места.

[Djalin]

Проголосовал, с бекапами еще одна проблемка есть
https://bugs.vestacp.com/issues/556