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.
Бекап VestaCP в Google Cloud Storage (Nearline)
Бекап VestaCP в Google Cloud Storage (Nearline)
Всем привет, так как официальной реализации бекапов в облачные хранилища (в частности засвеченный Google Nearline expiremental backup support) дождаться не пришлось - накостылял максимально простую и в то же время гибкую реализацию выгрузки бекапов в Google Cloud Storage.
Изначально была идея использовать CloudBerry Backup, который умеет выгрузку в Google Cloud, но позже счел данную утилиту неуместной и громоздкой в данной ситуации, не будем пересоздавать бекапы, а будем работать с теми архивами, которые создает VestaCP в /home/backup/ и выгружать их официальной утилитой для работы с Google Cloud - gsutil.
Настройка Google Cloud Storage
У вас уже должен быть аккаунт в console.cloud.google.com, с настроенным методом оплаты, создадим хранилище и учетную запись для доступа к нему.
1. IAM и администрирование -> Сервисные аккаунты: Создаем сервисный аккаунт с ролью (Хранение данных -> Администратор объектов в хранилище), отмечаем чек-бокс "Создать новый закрытый ключ" (в формате .json). Все, сервисный пользователь создан, начнется загрузка .json файла с ключем доступа пользователя, он нам пригодится позже.
2. Переходим в раздел "Storage" и создаем сегмент (собственно хранилище). Класс хранилища выбирайте межу Multi-Regional и Regional (не Nearline, он для хранения данных более одного месяца, за удаление ранее чем через месяц после создания файла в хранилище класса Nearline будет взыматься дополнительная плата (получится в 2 раза дороже чем Multi-Regional при создании ежедневного бекапа одного и того же объема). Насчет стоимости, у меня один виндовый сервер бекапится каждый час инкрементально в Multi-Regional EU, бекапы хранятся около 2х месяцев, общий объем около 80GB - стоимость $0.67/мес. В данном случае я выбрал Regional EU-North1 (так как самый дешевый $0.02/GB)
3. Настраиваем жизненный цикл файлов резервного копирования. В списке сегментов, в столбце "Жизненный цикл" кликаем на "нет" и в открывшемся окне настраиваем удаление файлов (я выбрал удаление файлов спустя 14 дней после создания).
4. Настраиваем права доступа к сегменту
Выбираем созданного в первом шаге пользователя с ролью "Администратор объектов в хранилище" и сохраняем изменения.
Настройка сервера
Все действия по выгрузке бекапа будут выполнятся от учетной записи "admin".
1. Дадим доступ пользователю "admin" к директории /home/backup/ добавлением его в группу backup
2. Скорректируем права на /home/backup/ (дадим разрешения не только для владельца, а и для группы backup)
3. Устанавливаем gsutil (В первом же шаге, установщик спросит куда устанавливать утилиту, рекомендую указать - /opt/) Инструкции под разные ОС
4. Переключаемся в юзера "admin"
5. Передаем на сервер скачанный при создании сервисного аккаунта в Google Cloud .json файл и авторизируем gsutil для работы с созданным хранилищем.
6. Проверяем что авторизация работает, запрашиваем у GCP список фалов в вашем сегменте.
Даже если хранилище пустое - должен вернутся пустой ответ, но без ошибок.
7. Редактируем cron задание бекапа в панели Vesta к такому виду
Использованные ключи утилиты gsutil
Изначально была идея использовать CloudBerry Backup, который умеет выгрузку в Google Cloud, но позже счел данную утилиту неуместной и громоздкой в данной ситуации, не будем пересоздавать бекапы, а будем работать с теми архивами, которые создает VestaCP в /home/backup/ и выгружать их официальной утилитой для работы с Google Cloud - gsutil.
Настройка Google Cloud Storage
У вас уже должен быть аккаунт в console.cloud.google.com, с настроенным методом оплаты, создадим хранилище и учетную запись для доступа к нему.
1. IAM и администрирование -> Сервисные аккаунты: Создаем сервисный аккаунт с ролью (Хранение данных -> Администратор объектов в хранилище), отмечаем чек-бокс "Создать новый закрытый ключ" (в формате .json). Все, сервисный пользователь создан, начнется загрузка .json файла с ключем доступа пользователя, он нам пригодится позже.
2. Переходим в раздел "Storage" и создаем сегмент (собственно хранилище). Класс хранилища выбирайте межу Multi-Regional и Regional (не Nearline, он для хранения данных более одного месяца, за удаление ранее чем через месяц после создания файла в хранилище класса Nearline будет взыматься дополнительная плата (получится в 2 раза дороже чем Multi-Regional при создании ежедневного бекапа одного и того же объема). Насчет стоимости, у меня один виндовый сервер бекапится каждый час инкрементально в Multi-Regional EU, бекапы хранятся около 2х месяцев, общий объем около 80GB - стоимость $0.67/мес. В данном случае я выбрал Regional EU-North1 (так как самый дешевый $0.02/GB)
3. Настраиваем жизненный цикл файлов резервного копирования. В списке сегментов, в столбце "Жизненный цикл" кликаем на "нет" и в открывшемся окне настраиваем удаление файлов (я выбрал удаление файлов спустя 14 дней после создания).
4. Настраиваем права доступа к сегменту
Выбираем созданного в первом шаге пользователя с ролью "Администратор объектов в хранилище" и сохраняем изменения.
Настройка сервера
Все действия по выгрузке бекапа будут выполнятся от учетной записи "admin".
1. Дадим доступ пользователю "admin" к директории /home/backup/ добавлением его в группу backup
Code: Select all
usermod -a -G backup admin
Code: Select all
chmod 0751 /home/backup/
Code: Select all
curl https://sdk.cloud.google.com | bash
exec -l $SHELL
Code: Select all
su admin
Code: Select all
gcloud auth activate-service-account --key-file путь_к_файлу.json
Code: Select all
gsutil ls gs://название-сегмента
7. Редактируем cron задание бекапа в панели Vesta к такому виду
Code: Select all
sudo /usr/local/vesta/bin/v-backup-users && /opt/google-cloud-sdk/bin/gsutil -q rsync -r /home/backup/ gs://название-сегмента/
- -q - Не выводить информацию о процессе синхронизации, если его не указать - VestaCP будет присылать письмо о каждом создании бекапа с выводом утилиты gsutil.
- -r - рекурсивное копирование.
Re: Бекап VestaCP в Google Cloud Storage (Nearline)
неудобство в том что пользователю нет возможности скачать старый (не самый последний) бекап из своего аккаунта в панели.Так же, для экономии места на диске, можно в VestaCP -> Packages -> default (или какой у вас применен пакет для пользователей) сменить кол-во хранимых локально резервных копий с 3 на 1, в Google Cloud Storage они все равно будут оставаться на протяжении того времени, которое вы укажете в настройках жизненного цикла объектов хранилища.
Лично я нашел практичное и недорогое решение через монтирование папки /backup в файловою систему s3ql с любым объектным хранилищем (GCS или OVH CLOUD STORAGE или любой другой). В итоге места на сервере бекапы не занимают вообще, ротация проходит нормально средствами самой vesta, и пользователи всегда имеют доступ к всем бекапам.
Re: Бекап VestaCP в Google Cloud Storage (Nearline)
Может выложите мануал по настройке данного метода?webkmua wrote: ↑Thu Jul 19, 2018 11:08 pmнеудобство в том что пользователю нет возможности скачать старый (не самый последний) бекап из своего аккаунта в панели.Так же, для экономии места на диске, можно в VestaCP -> Packages -> default (или какой у вас применен пакет для пользователей) сменить кол-во хранимых локально резервных копий с 3 на 1, в Google Cloud Storage они все равно будут оставаться на протяжении того времени, которое вы укажете в настройках жизненного цикла объектов хранилища.
Лично я нашел практичное и недорогое решение через монтирование папки /backup в файловою систему s3ql с любым объектным хранилищем (GCS или OVH CLOUD STORAGE или любой другой). В итоге места на сервере бекапы не занимают вообще, ротация проходит нормально средствами самой vesta, и пользователи всегда имеют доступ к всем бекапам.
Re: Бекап VestaCP в Google Cloud Storage (Nearline)
Не остановился на этом методе по двум причинам.
1. Временные файлы бекапа сначала пишутся в обьектное хранилище, а потом забираются обратно для дальнейшей упаковки в архив, если обьем будет серьезным можно влететь в хорошую кореечку на исходящем трафике из хранилища.
2. Пишут что часто отваливается монтированная директория.
1. Временные файлы бекапа сначала пишутся в обьектное хранилище, а потом забираются обратно для дальнейшей упаковки в архив, если обьем будет серьезным можно влететь в хорошую кореечку на исходящем трафике из хранилища.
2. Пишут что часто отваливается монтированная директория.
Re: Бекап VestaCP в Google Cloud Storage (Nearline)
Да, есть свои риски и минусы, но плюсы лично для меня более востребованны.rez0n wrote: ↑Fri Jul 20, 2018 7:41 pmНе остановился на этом методе по двум причинам.
1. Временные файлы бекапа сначала пишутся в обьектное хранилище, а потом забираются обратно для дальнейшей упаковки в архив, если обьем будет серьезным можно влететь в хорошую кореечку на исходящем трафике из хранилища.
2. Пишут что часто отваливается монтированная директория.
1. При создании s3ql файловой системы, можно выбрать размер кеша на локальной машине. Я выбрал размер кеша чуть больше чем максимально возможный бекап (к примеру 100 гб), в итоге временные файлы не пишуться в хранилище, а только локально, а в хранилище уже уходит архив. В большинстве хранилищ (yfghvbth OVH) входящий трафик не тарифицируется, только хранение и исходящий. На данный момент хранение ротация бекапов общим размером около 200гб выходит примерно в 2 бакса в месяць. Это при том что пользователи панели имеют полный доступ к своим бекапам любой давности.
2. Было такое вначале, но последнии версии довольно стабильны. У меня пока что 4-й месяць ничего не отваливается, сделал через сервисы с автоматическим монтированием/отмонтированием при перезагрузке системы. Возможен сбой при внезапном выключении сервера, тогда нужно будет делать fscheck.
Возможно выложу в дальнейшем мануал, пока что еще сам тестирую все.
Re: Бекап VestaCP в Google Cloud Storage (Nearline)
по поводу первого пункта, сейчас Vesta предусматривает в конфигурации отдельную папку для временных файлов:rez0n wrote: ↑Fri Jul 20, 2018 7:41 pmНе остановился на этом методе по двум причинам.
1. Временные файлы бекапа сначала пишутся в обьектное хранилище, а потом забираются обратно для дальнейшей упаковки в архив, если обьем будет серьезным можно влететь в хорошую кореечку на исходящем трафике из хранилища.
2. Пишут что часто отваливается монтированная директория.
Дописать в /usr/local/vesta/conf/vesta.conf
BACKUP_TEMP='/backup_temp'
На данный момент хочу посоветовать всем желающим хранилиже Hetzer nextcloud box. По цене примерно тоже что и основные хранилища, но с вебинтерфейсом nextcloud и возможностю монтирования через WEBDAV который довольно стабилен, по крайней мере у меня за полгода не отвалилось ниразу.
Re: Бекап VestaCP в Google Cloud Storage (Nearline)
Вот,я когда-то писал - viewtopic.php?f=36&t=18056
С самого начала декабря и по сейчас ничего не отваливается,бекап каждые три дня делается,бекап в 50гиг.Пока все нормально.Ротация и прочее.
С самого начала декабря и по сейчас ничего не отваливается,бекап каждые три дня делается,бекап в 50гиг.Пока все нормально.Ротация и прочее.
Re: Бекап VestaCP в Google Cloud Storage (Nearline)
Хороший вариант. Вижу только небольших 2 нюанса:yariksat wrote: ↑Sun Feb 24, 2019 7:11 amВот,я когда-то писал - viewtopic.php?f=36&t=18056
С самого начала декабря и по сейчас ничего не отваливается,бекап каждые три дня делается,бекап в 50гиг.Пока все нормально.Ротация и прочее.
1. Как выше писали:
что может негативно сказатся на трафике как для сервера так и для хранилища, а так же скорости. Решение как я писал выше, дописать в конфиг папку для временных файлов (на время создания архива).Временные файлы бекапа сначала пишутся в обьектное хранилище, а потом забираются обратно для дальнейшей упаковки в архив, если обьем будет серьезным можно влететь в хорошую кореечку на исходящем трафике из хранилища.
Дописать в /usr/local/vesta/conf/vesta.conf
BACKUP_TEMP='/backup_temp'
2. То что в вашем топике
тоже не критично, но может сказатся на безопасности сайтов хранящихся на сервере. Теоретически, если немного изменить get-запрос с админки то можно будет скачать бекап другого пользователя.chown: changing ownership of вЂ/backup/ftp/backup/admin.2018-12-16_05-21-16.tar’: Operation not permitted
Ну и вообще очень важна цена хранилища.
У кого какие варианты недорогие, с поддержкой webdav или ftp?
Re: Бекап VestaCP в Google Cloud Storage (Nearline)
1.Для меня критично выполнение в том числе и временной папки,так как она не вместится на сервере.Мне дешевле взять бекап диск по цене 1гиг за 1руб чем увеличивать диск на сервере.Это стоит значительно дороже.
Трафик у меня анлим везде,скорость вроде как сильно не страдает.
2.Для меня так же не критично,я один на сервере.
Трафик у меня анлим везде,скорость вроде как сильно не страдает.
2.Для меня так же не критично,я один на сервере.