Бекап VestaCP в Google Cloud Storage (Nearline)

[rez0n]

Всем привет, так как официальной реализации бекапов в облачные хранилища (в частности засвеченный 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

Code: Select all

usermod -a -G backup admin

2. Скорректируем права на /home/backup/ (дадим разрешения не только для владельца, а и для группы backup)

Code: Select all

chmod 0751 /home/backup/

3. Устанавливаем gsutil (В первом же шаге, установщик спросит куда устанавливать утилиту, рекомендую указать - /opt/) Инструкции под разные ОС

Code: Select all

curl https://sdk.cloud.google.com | bash
exec -l $SHELL

4. Переключаемся в юзера "admin"

Code: Select all

su admin

5. Передаем на сервер скачанный при создании сервисного аккаунта в Google Cloud .json файл и авторизируем gsutil для работы с созданным хранилищем.

Code: Select all

gcloud auth activate-service-account --key-file путь_к_файлу.json

6. Проверяем что авторизация работает, запрашиваем у GCP список фалов в вашем сегменте.

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://название-сегмента/

Использованные ключи утилиты gsutil

• -q - Не выводить информацию о процессе синхронизации, если его не указать - VestaCP будет присылать письмо о каждом создании бекапа с выводом утилиты gsutil.

• -r - рекурсивное копирование.

Так же, для экономии места на диске, можно в VestaCP -> Packages -> default (или какой у вас применен пакет для пользователей) сменить кол-во хранимых локально резервных копий с 3 на 1, в Google Cloud Storage они все равно будут оставаться на протяжении того времени, которое вы укажете в настройках жизненного цикла объектов хранилища.

[webkmua]

Так же, для экономии места на диске, можно в VestaCP -> Packages -> default (или какой у вас применен пакет для пользователей) сменить кол-во хранимых локально резервных копий с 3 на 1, в Google Cloud Storage они все равно будут оставаться на протяжении того времени, которое вы укажете в настройках жизненного цикла объектов хранилища.

неудобство в том что пользователю нет возможности скачать старый (не самый последний) бекап из своего аккаунта в панели.
Лично я нашел практичное и недорогое решение через монтирование папки /backup в файловою систему s3ql с любым объектным хранилищем (GCS или OVH CLOUD STORAGE или любой другой). В итоге места на сервере бекапы не занимают вообще, ротация проходит нормально средствами самой vesta, и пользователи всегда имеют доступ к всем бекапам.

[one]

Так же, для экономии места на диске, можно в VestaCP -> Packages -> default (или какой у вас применен пакет для пользователей) сменить кол-во хранимых локально резервных копий с 3 на 1, в Google Cloud Storage они все равно будут оставаться на протяжении того времени, которое вы укажете в настройках жизненного цикла объектов хранилища.

неудобство в том что пользователю нет возможности скачать старый (не самый последний) бекап из своего аккаунта в панели.
Лично я нашел практичное и недорогое решение через монтирование папки /backup в файловою систему s3ql с любым объектным хранилищем (GCS или OVH CLOUD STORAGE или любой другой). В итоге места на сервере бекапы не занимают вообще, ротация проходит нормально средствами самой vesta, и пользователи всегда имеют доступ к всем бекапам.

Может выложите мануал по настройке данного метода?

[rez0n]

Не остановился на этом методе по двум причинам.
1. Временные файлы бекапа сначала пишутся в обьектное хранилище, а потом забираются обратно для дальнейшей упаковки в архив, если обьем будет серьезным можно влететь в хорошую кореечку на исходящем трафике из хранилища.
2. Пишут что часто отваливается монтированная директория.

[webkmua]

Не остановился на этом методе по двум причинам.
1. Временные файлы бекапа сначала пишутся в обьектное хранилище, а потом забираются обратно для дальнейшей упаковки в архив, если обьем будет серьезным можно влететь в хорошую кореечку на исходящем трафике из хранилища.
2. Пишут что часто отваливается монтированная директория.

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

1. При создании s3ql файловой системы, можно выбрать размер кеша на локальной машине. Я выбрал размер кеша чуть больше чем максимально возможный бекап (к примеру 100 гб), в итоге временные файлы не пишуться в хранилище, а только локально, а в хранилище уже уходит архив. В большинстве хранилищ (yfghvbth OVH) входящий трафик не тарифицируется, только хранение и исходящий. На данный момент хранение ротация бекапов общим размером около 200гб выходит примерно в 2 бакса в месяць. Это при том что пользователи панели имеют полный доступ к своим бекапам любой давности.
2. Было такое вначале, но последнии версии довольно стабильны. У меня пока что 4-й месяць ничего не отваливается, сделал через сервисы с автоматическим монтированием/отмонтированием при перезагрузке системы. Возможен сбой при внезапном выключении сервера, тогда нужно будет делать fscheck.

Возможно выложу в дальнейшем мануал, пока что еще сам тестирую все.

[webkmua]

Не остановился на этом методе по двум причинам.
1. Временные файлы бекапа сначала пишутся в обьектное хранилище, а потом забираются обратно для дальнейшей упаковки в архив, если обьем будет серьезным можно влететь в хорошую кореечку на исходящем трафике из хранилища.
2. Пишут что часто отваливается монтированная директория.

по поводу первого пункта, сейчас Vesta предусматривает в конфигурации отдельную папку для временных файлов:
Дописать в /usr/local/vesta/conf/vesta.conf
BACKUP_TEMP='/backup_temp'

На данный момент хочу посоветовать всем желающим хранилиже Hetzer nextcloud box. По цене примерно тоже что и основные хранилища, но с вебинтерфейсом nextcloud и возможностю монтирования через WEBDAV который довольно стабилен, по крайней мере у меня за полгода не отвалилось ниразу.

[yariksat]

Вот,я когда-то писал - viewtopic.php?f=36&t=18056
С самого начала декабря и по сейчас ничего не отваливается,бекап каждые три дня делается,бекап в 50гиг.Пока все нормально.Ротация и прочее.

[webkmua]

Вот,я когда-то писал - viewtopic.php?f=36&t=18056
С самого начала декабря и по сейчас ничего не отваливается,бекап каждые три дня делается,бекап в 50гиг.Пока все нормально.Ротация и прочее.

Хороший вариант. Вижу только небольших 2 нюанса:
1. Как выше писали:

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

что может негативно сказатся на трафике как для сервера так и для хранилища, а так же скорости. Решение как я писал выше, дописать в конфиг папку для временных файлов (на время создания архива).
Дописать в /usr/local/vesta/conf/vesta.conf
BACKUP_TEMP='/backup_temp'

2. То что в вашем топике

chown: changing ownership of ‘/backup/ftp/backup/admin.2018-12-16_05-21-16.tar’: Operation not permitted

тоже не критично, но может сказатся на безопасности сайтов хранящихся на сервере. Теоретически, если немного изменить get-запрос с админки то можно будет скачать бекап другого пользователя.


Ну и вообще очень важна цена хранилища.
У кого какие варианты недорогие, с поддержкой webdav или ftp?

[yariksat]

1.Для меня критично выполнение в том числе и временной папки,так как она не вместится на сервере.Мне дешевле взять бекап диск по цене 1гиг за 1руб чем увеличивать диск на сервере.Это стоит значительно дороже.
Трафик у меня анлим везде,скорость вроде как сильно не страдает.
2.Для меня так же не критично,я один на сервере.