Существует много консольных инструментов для настройки бэкапов. Наиболее популярные и функциональные restic и borg. Сегодня я расскажу про ещё один, который я недавно внедрил на один веб сервер, так что в конце приведу полные конфиги для полноценного использования.
Речь пойдёт про старый и относительно известный инструмент nxs-backup от компании Nixys. Я знаю его давно. Если не ошибаюсь, то сначала это был просто bash скрипт, потом его упаковали в пакеты. А где-то год назад его полностью переписали и теперь это бинарник на Go.
📌 Основные возможности nxs-backup:
🔹Полные и инкрементные бэкапы на уровне файлов.
🔹Бэкапы СУБД MySQL/PostgreSQL как дампом, так и бинарные.
🔹Бэкапы MongoDB и Redis.
🔹В качестве бэкенда для передачи и хранения может использоваться: S3, SSH (SFTP), FTP, CIFS (SMB), NFS, WebDAV.
🔹Уведомления по email, Telegram, Slack или любой webhook.
Теперь отдельно расскажу, что хорошего и полезного есть конкретно в этой программе, так как список возможностей типичный для подобных программ.
➕Простые конфиги в формате yaml для заданий + одиночный бинарник. Удобно масштабировать и использовать одни и те же настройки на различных проектах. Работает одинаково без зависимостей и пересборки практически на всех Linux.
➕Из предыдущего пункта вытекает удобство использования в контейнерах. В конфиги можно передавать переменные, что упрощает настройку и позволяет не хранить секреты в конфигах. Бонусом будет очень маленький образ с самим nxs-backup, если он будет запускаться отдельно.
➕Возможность гибкой настройки логов и уведомлений. Я сделал хранение полного лога в текстовом файле локально, который легко анализировать и куда-то в общее хранилище передавать. А оповещения об ошибках и предупреждениях отдельно отправляю в Telegram.
➕Бэкап на уровне файлов делается простым tar. На базе его же возможностей организованы инкрементные бэкапы. То есть файлы хранятся в исходном виде, а восстановление возможно самостоятельно без использования nxs-backup. Кому-то это покажется минусом, но лично я больше люблю хранение в таком виде. Да, нет дедупликации, но меньше шансов получить поврежденные данные в случае каких-то проблем.
➕В едином формате конфигов описываются задания для бэкапа файлов и баз. Закрываются базовые потребности одной программой. Не надо дампить или делать бинарные бэкапы каким-то отдельным инструментом.
➕Удобно настроить одновременно локальное хранение бэкапов и отправку в S3. Я обычно это сам костылю скриптами.
➕Есть Helm чарт для использования в Kubernetes.
☝ Сразу отмечу явные минусы:
➖Нет встроенного шифрования.
➖Не очень удобно мониторить. По сути есть только логи и уведомления.
➖Документация так себе. Пришлось поковыряться, хоть в итоге всё и получилось, как задумал.
В целом, получилось неплохо. Я потратил время и создал для себя универсальные конфиги, которые буду использовать. Для интегратора или аутсорсера, кто занимается поддержкой серверов, это удобное решение. Собственно, оно для этих целей и писалось, чтобы закрыть внутренние потребности.
Установка:# curl -L https://github.com/nixys/nxs-backup/releases/latest/download/nxs-backup-amd64.tar.gz -o /tmp/nxs-backup.tar.gz# tar xf /tmp/nxs-backup.tar.gz -C /tmp# mv /tmp/nxs-backup /usr/sbin/nxs-backup
Подготовка основного конфига в /etc/nxs-backup/nxs-backup.conf:
⇨ nxs-backup.conf
Конфиг с заданием для бэкапа файлов /etc/nxs-backup/conf.d/site01-files.conf:
⇨ site01-files.conf
Конфиг с заданием для бэкапа БД /etc/nxs-backup/conf.d/site01-mysql.conf:
⇨ site01-mysql.conf
Проверяем конфигурацию:# nxs-backup -t
Если есть ошибки, увидите их. Если нет, то запускаем бэкап:# nxs-backup start all
У меня успешно создаётся локальный бэкап и одновременно с ним отправляется в S3 Селектела. Соответственно, политика хранения бэкапов указана. Nxs-backup будет автоматически складывать по указанной структуре бэкапы и удалять старые.
Продукт интересный. Кто занимается подобными вещами, рекомендую обратить внимание.
⇨ Сайт / Исходники
#backup
>>Click here to continue<<
