Добрый день, Habr!
Меня зовут Наталья. Я тимлид группы администраторов приложений в НПО Криста. Мы Ops для группы проектов нашей компании. У нас довольно своеобразная ситуация: мы устанавливаем и сопровождаем наше ПО как на серверах нашей компании, так и на серверах, расположенных у клиентов. При этом бэкапить сервер целиком нет необходимости. Важны лишь существенные данные: СУБД и отдельные каталоги файловой системы. Конечно, клиенты имеют (или не имеют) свои регламенты резервного копирования и часто предоставляют некое внешнее хранилище для складывания туда резервных копий. В этом случае после создания бэкапа мы обеспечиваем отправку во внешнее хранилище.
Какое-то время для целей бэкапа мы обходились bash-скриптом, но по мере разрастания вариантов настроек пропорционально росла и запутанность этого скрипта, и в один прекрасный момент мы пришли к необходимости его разрушить до основанья, а затем.....
Готовые решения не подошли по разным причинам: из-за необходимости децентрализации бэкапов, обязательности хранения бэкапов локально у клиента, сложности настройки, импортозамещения, ограничения доступа.
Нам показалось, что проще написать что-то своё. При этом хотелось получить что-то такое, чего хватит для нашей ситуации на следующие N лет, но с возможностью потенциального расширения области применения.
Условия задачи были следующие:
1. базовый инстанс бэкапа автономен, работает локально
2. хранение резервных копий и логов всегда в пределах сети клиента
3. инстанс состоит из модулей такой своеобразный конструктор
4. необходима совместимость с используемыми дистрибутивами Linux, включая устаревшие, желательна потенциальная кроссплатформенность
5. для работы с инстансом достаточно доступа по ssh, открытие дополнительных портов необязательно
6. максимальная простота настройки и эксплуатации
7. возможно (но не обязательно) существование отдельного инстанса, позволяющего централизованно просмотреть состояние бэкапов с разных серверов
То, что у нас получилось, можно посмотреть здесь: github.com/javister/krista-backup
ПО написано на python3; работает на Debian, Ubuntu, CentOS, AstraLinux 1.6.
Документация выложена в каталоге docs репозитария.
Основные понятия, которыми оперирует система:
action действие, реализующее одну атомарную операцию (бэкап БД, бэкап каталога, перенос из каталога А в каталог Б и т. д.). Существующие actions лежат в каталоге core/actions
task задание, набор actions, описывающий одну логическую задачу бэкапа
schedule расписание, набор task с опциональным указанием времени выполнения задачи
Конфигурация бэкапа хранится в yaml-файле; общая структура конфига:
общие настройки
раздел actions: описание действий, используемых на этом сервере
раздел schedule: описание всех заданий (наборов действий) и расписание их запуска по крону, если такой запуск требуется
Пример конфига можно посмотреть здесь: github.com/javister/krista-backup/blob/master/KristaBackup/config.yaml.example
Что умеет приложение на текущий момент:
поддерживаются основные для нас операции: бэкап PostgreSQL, бэкап каталога файловой системы через tar; операции с внешним хранилищем; rsync между каталогами; ротация бэкапов (удаление старых копий)
вызов внешнего скрипта
выполнение вручную отдельного задания
/opt/KristaBackup/KristaBackup.py run make_full_dump
можно добавить (или убрать) в кронтабе отдельное задание или все расписание
/opt/KristaBackup/KristaBackup.py enable all
генерация триггер-файла по результатам бэкапа. Эта функция полезна в связке с Zabbix для мониторинга бэкапов
может работать в фоне в режиме webapi или web
/opt/KristaBackup/KristaBackup.py web start [--api]
Разница между режимами: в webapi нет собственно веб-интерфейса, но приложение отвечает на запросы другого инстанса. Для режима web нужно установить flask и несколько дополнительных пакетов, а это не везде приемлемо, например в сертифицированной AstraLinux SE.
Через веб-интерфейс можно посмотреть состояние и логи бэкапов подключенных серверов: веб-инстанс запрашивает данные с бэкап-инстансов через API. Доступ к web требует авторизации, доступ к webapi нет.
Логи некорректно прошедших бэкапов размечаются цветом: warning желтым, error красным.
Если администратору не нужна шпаргалка по параметрам и серверные ОС однородны, можно скомпилировать файл и распространять уже готовый пакет.
Распространяем мы эту утилиту в основном через Ansible, выкатывая сначала на часть наименее важных серверов, а после тестирования на все остальные.
В итоге мы получили компактную автономную утилиту копирования, поддающуюся автоматизации и пригодную для эксплуатации даже малоопытными администраторами. Нам удобно может, пригодится и вам?
