We are happy to announce that Vesta is back under active development as of 25 February 2024. We are working on v1 candidate and expect to engage more with the community over the coming months. We are committed to open source, and we encourage contributors to help us build the future of Vesta.
Сжатие резервных копий BackUp
Сжатие резервных копий BackUp
Здравствуйте. У меня в панеле файлы резервных копий в формате tar Возможно их дополнительно сжать? К примеру tbz2 или tgz. Все ж места будут меньше занимать. И по ftp быстрее сливаться будут.
Re: Сжатие резервных копий BackUp
картинки и видео если я не ошибаюсь - не сжимаются, т.е. сжимаются но размер их от этого не меняется, а в некоторых случаях возможно ухудшение качества картинки. А скрипты составляют даже не половину архива. Но на счет мускуля - он наверное стоит того, что бы его сжимать
Re: Сжатие резервных копий BackUp
Это хорошее предложение и оно уже реализовано :)
Внутри tar файла находится дерево папок разбитое по соответсвующим категориям. Внутри каждой категории данные сжаты gzip-ом и упакованы в отдельный ахрив:
Пример для web домена
Пример для базы данных
Получается архив внутри архива. Только первый уровень идет без сжатия, просто склейка файлов для удобства.
Внутри tar файла находится дерево папок разбитое по соответсвующим категориям. Внутри каждой категории данные сжаты gzip-ом и упакованы в отдельный ахрив:
Пример для web домена
Code: Select all
./web/demo.vestacp.com/domain_data.tar.gz
./web/demo.vestacp.com/vesta/web.conf
./web/demo.vestacp.com/conf/httpd.conf
./web/demo.vestacp.com/conf/nginx.conf
Code: Select all
./db/admin_demo/admin_demo.mysql.sql.gz
./db/admin_demo/vesta/db.conf
./db/admin_demo/conf/admin_demo.mysql.admin_demo
Re: Сжатие резервных копий BackUp
не усложнится ли процесс развертывания бэкапа? Чувствую что очень даже усложнится.
Re: Сжатие резервных копий BackUp
Правильно ли я понял...???
1. Сначала каждый сайт склеивается в tar
2. Затем сжимается gz
То есть каждый сайт - это один архив плюс файлы конфига.
Аналогично для баз данных и прочих категорий.
3. Далее все сжатые gz файлы (от всех сайтов, баз данных и пр.) опять склеиваются в один tar, чтобы получить единый файл-архив.
И поэтому бэкап дополнительно сжимать не надо.
Посмотрел структуру бэкапа, вроде все так и получается...
1. Сначала каждый сайт склеивается в tar
2. Затем сжимается gz
То есть каждый сайт - это один архив плюс файлы конфига.
Аналогично для баз данных и прочих категорий.
3. Далее все сжатые gz файлы (от всех сайтов, баз данных и пр.) опять склеиваются в один tar, чтобы получить единый файл-архив.
И поэтому бэкап дополнительно сжимать не надо.
Посмотрел структуру бэкапа, вроде все так и получается...
Last edited by moonback on Thu Mar 14, 2013 8:38 pm, edited 2 times in total.
Re: Сжатие резервных копий BackUp
skid можешь пояснить такой подход к созданию архива?
например мне это кажется сложным, хотелось бы наверное видеть один архив, т.к. у пользователя на сайте также могут быть архивы свои, и сложная древовидная структура в которой даже ему разобраться сложно.
например мне это кажется сложным, хотелось бы наверное видеть один архив, т.к. у пользователя на сайте также могут быть архивы свои, и сложная древовидная структура в которой даже ему разобраться сложно.
Re: Сжатие резервных копий BackUp
Да все он правильно делает. tar это по сути не архив а просто пачка файлов склеенных в 1 файл - открывается и под линухами и под виндой быстро и на ура. Если не ошибаюсь когдато файловая система в операционке OS/2 от IBM именно так и хранила папки и при большом количестве мелких файлов это даже улучшало производительность. А вот данные которые надо сжимать и методы как их надо сжимать уже внутри распределенныXakRu wrote:skid можешь пояснить такой подход к созданию архива?
например мне это кажется сложным, хотелось бы наверное видеть один архив, т.к. у пользователя на сайте также могут быть архивы свои, и сложная древовидная структура в которой даже ему разобраться сложно.
Т.е. имхо вполне удобно а разворачивается все быстро и на ура.
В винде тем же тоталом как по папкам можно ползать, в линуксах через тот же midnight commander если надо
Re: Сжатие резервных копий BackUp
moonback, все верно, процесс именной такой.
XakRu, понимаю, что вложенность может показаться избыточной, но за этим решеним стоит рациональный мотив. Процесс восстановления будет модульным. Можно будет восстановить отдельно базу данных или один днс домен. По опыту могу сказать, что это востребованный сценарий. Теперь представим ситуацию, в которой файлы сайта занимают десятки гигабайт, а база данных весит несколько метров. Если все упаковано в один архив, то для извлечения базы, прийдется распаковать гигабайты ненужных данных. В текущей схеме этой проблемы нет. tar работает как оболочка из которой можно быстро извлечь нужный архив с базой.
Kudja я читал, что tar был очень полезен при бэкапах на ленточные накопители. Там было слабо с поизиционированием головки, поэтому было проще записывать/считывать файлы большими кусками.
XakRu, понимаю, что вложенность может показаться избыточной, но за этим решеним стоит рациональный мотив. Процесс восстановления будет модульным. Можно будет восстановить отдельно базу данных или один днс домен. По опыту могу сказать, что это востребованный сценарий. Теперь представим ситуацию, в которой файлы сайта занимают десятки гигабайт, а база данных весит несколько метров. Если все упаковано в один архив, то для извлечения базы, прийдется распаковать гигабайты ненужных данных. В текущей схеме этой проблемы нет. tar работает как оболочка из которой можно быстро извлечь нужный архив с базой.
Kudja я читал, что tar был очень полезен при бэкапах на ленточные накопители. Там было слабо с поизиционированием головки, поэтому было проще записывать/считывать файлы большими кусками.
Re: Сжатие резервных копий BackUp
Взгляд с будущими перспективами - это конечно хорошо. Но по опыту - база данных в несколько гигабайт обычно лежит на отдельном сервере с репликацией на еще несколько серверов, что бы не нагружать дисковую систему. Легко масштабируется. Я думал вы позиционируете ваш проект для небольших серверов. У меня была мысль задать вам вопрос по поводу администрирования нескольких серверов одной панелью, но наверное те, кто администрируют такие большие проекты - предпочитают делать всё руками, я не против автоматизации.
Я понимаю целесообразность использования tar архивов ( контейнеров для папок ). Я думаю что вложенные архивы усложнят жизнь обычным пользователям, немного админов со стажем пользуется этой панелью, больше начинающие, или те, которым нужно быстро развернуть сервер не вникая в детали, что бы не читать кучу мануалов и форумов.
Как вариант - думаю что можно отделить архив БД от архива сайта или предложить скачать одним архивом упаковав мгновенно, ведь архивация в tar много времени не занимает. Также возможно пользователь захочет сохранять в облаке архивы только БД.
Модификация или добавление нескольих строк кода в обычный архив выглядит проще, чем то, что нужно разбирать переменные и зависимости возникающие при упаковке и распаковке архива. Вы правы - когда говорите о том, что пользователь возможно захочет развернуть бэкап только БД или только файлов и скриптов сайта ( да еще лучше будет выделить разные скрипты пи кнопки в веб-интерфейсе для раскатки бэкапов-Бд от файлов, и в этом случае кажется разделение архивов БД от файловых более конструктивным.
Моё видение решения от вашего конечно может отличаться, на то мы люди, также у вас большой опыт в работе с linux системами в отличие от моего, надеюсь что моё развернутое изложение мыслей не оставит негативного мнения о ваших способах решения задач.
Я понимаю целесообразность использования tar архивов ( контейнеров для папок ). Я думаю что вложенные архивы усложнят жизнь обычным пользователям, немного админов со стажем пользуется этой панелью, больше начинающие, или те, которым нужно быстро развернуть сервер не вникая в детали, что бы не читать кучу мануалов и форумов.
Как вариант - думаю что можно отделить архив БД от архива сайта или предложить скачать одним архивом упаковав мгновенно, ведь архивация в tar много времени не занимает. Также возможно пользователь захочет сохранять в облаке архивы только БД.
Модификация или добавление нескольих строк кода в обычный архив выглядит проще, чем то, что нужно разбирать переменные и зависимости возникающие при упаковке и распаковке архива. Вы правы - когда говорите о том, что пользователь возможно захочет развернуть бэкап только БД или только файлов и скриптов сайта ( да еще лучше будет выделить разные скрипты пи кнопки в веб-интерфейсе для раскатки бэкапов-Бд от файлов, и в этом случае кажется разделение архивов БД от файловых более конструктивным.
Моё видение решения от вашего конечно может отличаться, на то мы люди, также у вас большой опыт в работе с linux системами в отличие от моего, надеюсь что моё развернутое изложение мыслей не оставит негативного мнения о ваших способах решения задач.
Re: Сжатие резервных копий BackUp
Перед созданием бэкапа предлагаю сделать выбор формата сжатия. TGZ TAR ZIP
XakRu правильно ли я Вас понял вы предлагаете что при создании главного бекапа будут как бы "подбэкапы" базы , файлы доменов, почтовые ящики и т.д ? А потом то что нужно будет опция моментально заархивировать и скачать или восстановить прямо в панели?
XakRu правильно ли я Вас понял вы предлагаете что при создании главного бекапа будут как бы "подбэкапы" базы , файлы доменов, почтовые ящики и т.д ? А потом то что нужно будет опция моментально заархивировать и скачать или восстановить прямо в панели?