Синхронизация резервных копий VestaCP с Яндекс.Диск
Раздел(ы): Вебмастеру, Панели управления хостингом, Резервное копирование
Просмотры: 4781
Комментарии: 10
Резервных копий много не бывает. Предлагаю еще одно решение по копированию бекапов созданных панелью управления VestaCP на Яндекс.Диск. Особенность данного решения в том, что передаваемые данные на Яндекс.Диск синхронизируются, то есть являются полной копией того, что лежит у вас в директории /home/bakup на сервере.
Консольный клиент
Для реализации задуманного (копирования данных на Яндекс.Диск) я воспользуюсь консольным клиентов Linux/FreeBSD для работы с облачным хранилищем Яндекс.Диск (Yandex.Disk) посредством REST API — https://github.com/abbat/ydcmd.
Установка
Моя инструкция несколько отличается от оригинальной. Для установки клиента выполните следующий код в консоли сервера:
# git clone https://github.com/abbat/ydcmd.git # cp ydcmd/ydcmd.py /usr/local/vesta/bin/ydcmd
Путь сознательно выбран не таким как в официальной документации, это сделано для того, чтобы в последствии вы могли запускать синхронизацию в Cron от имени администратора (пользователя Admin в панели VestaCP).
Получения «токена» для приложения
Чтобы данное приложение работало с облачным хранилищем Яндекс.Диск необходимо его зарегистрировать по адресу https://oauth.yandex.ru/ и получить так называемый токен.
Для этого перейдите по указанной выше ссылке и выберите следующие разрешения для приложения (название может быть любым):
После регистрации скопируйте id приложения:
и перейдите по ссылке:
https://oauth.yandex.ru/authorize?response_type=token&client_id=<id_приложения>
Затем нужно разрешить доступ к данным Яндекс.Диска для вашего приложения:
После чего сервис перенаправит нас по ссылке вида:
https://oauth.yandex.ru/verification_code?dev=True#access_token=<токен>
И на экране будет выведена последовательность букв и цифр:
Это и есть требуемый параметр для работы приложения (консольного клиента).
Сохраняем его в файл /root/.ydcmd.cfg, который должен выглядеть примерно так:
[ydcmd] token = 1234567890
Назначаем ему правильные права доступа:
# chmod 400 /root/.ydcmd.cfg
Проверка резервного копирования на Яндекс.Диск
Выполните в консоли сервера следующую команду:
# /usr/local/vesta/bin/ydcmd put --rsync /home/backup/ disk:/Папка-резервного-копирования
где «Папка-резервного-копирования» — директория на Яндекс.Диске куда будут копироваться файлы.
Внимание!!! Если указанная папка на Яндекс.Диске существует, то все данные в ней пропадут и будут заменены на содержимое директории /home/backup/ вашего сервера.
Настройка резервного копирования по расписанию
Для настройки резервного копирования на Яндекс.Диск по расписанию создайте задание Cron от имени администратора панели VestaCP:
В моем случае каждый день в 5 часов 55 минут файлы из директории сервера /home/backup будут синхронизированы с папкой backups на Яндекс.Диске.
Некоторые недоразумения
Столкнулся с тем, что у меня на Яндекс.Диске архивов всегда на один меньше чем на сервере. Нет самого старого. То есть если на сервере пять копий, то в диске только четыре.
Благодарности
При написании статьи были использованы следующие источники:
Хорошее у вас изложение материала. Респект.
По поводу Я диска и бекапа. Весту не трогаю, обхожусь без нее.
Почему вы не используете возможность монтирования Я диска на свой сервер? Зачем все эти танцы с токенами?
В общем случае я использую очень простой алгоритм: монтирую Я диск -> забрасываю на него бекап -> удаляю старые -> umount Я диск. И все это под непривилегированным пользователем. Используя возможности davfs2
Алексей, ваш способ проще. Но при копировании больших файлов или нестабильности канала davfs копирует медленно, и бывало зависал в самые неожиданные моменты и приходилось перемонтировать заново. Подробнее здесь — https://forum.vestacp.com/viewtopic.php?t=13051
Юрий!
Еще раз огромнейший вам респект. Но, только поймите правильно: дело не в том, что «за что же не боясь греха, кукушка ….» :)))
Дело в том, что достаточно часто действительно нужную, полезную инф-цию в инете, находишь с трудом. Очень много копипаста.
После медитации над вашей статьей, я наконец то увидел, что используете нестандартный консольный клиент Яндекса. ВОТ ЭТО ИМЕННО ТО, что доктор прописал!!!
«Лишние» телодвижения, как я писал перед этим, по получению токена — ни фига не лишние. Мы Синхронизируем Только То, Что Нам Нужно!!! И это здорово. В стандартном консольном Я клиенте мы должны явно указать исключенные из синхронизации папки.
Так что: две vds-ки бэкап и продакшен на DO + private network между ними + sshfs + ydcmd put —rsync = спокойный сон :)))
И еще приятный бонус у меня получился: бэкапы надо отдавать на два Я диска. И как? Очень просто — запускаем ydcmd с опцией —config=»path-to-other-cnf-file». В др. конфиге прописан др. токен.
Я так понимаю старые бэкапы удаляются на ядиске минуя корзину ? Можно как то это исправить ? Или сохраняться в отдельную папку на облаке ?
Я так понимаю данные с облака удаляются при синхронизации минуя корзину ? Можно это как то поправить ? Или переносить их в отдельную папку ?
Описанный способ синхронизации резервных копий подразумевает использование стороннего консольного клиента для Яндекс.Диск — https://github.com/abbat/ydcmd. Действительно, при указанных в статье настройках, старые данные удаляются минуя корзину. Попробуйте использовать опцию —trash. А если она не поможет, то лучше обратиться к автору данного ПО за подсказкой.
—-Можно как то это исправить ?
Да, по умолчанию без параметра —rsync команда put загружает новые файлы, но не удаляет отсутствующие на сервере. Очистку в облаке можно производить отдельным вызовом команды clean указав соответствующее количество дней или количество файлов для хранения в параметрах —keep и —type. Чтобы не удалить случайно лишнего, лучше поэкспериментировать на какой-нибудь тестовой директории.
После ввода команды проверки резервного копирования получаю вот такую ошибку:
Python module dateutil not found.
Please, install «python-dateutil»
установил:
sudo apt update
sudo apt install python3-dateutil
но ошибка сохраняется. Что я делаю не так? (сервер перезагружал)
Здравствуйте.
У меня при проверке резервного копирования, вывалилась ошибка сертификата.
…certificate verify failed>
Что я сделал не так?
HTTP-401: Unauthorized