Eще один бэкап — больше, чем скрипт, проще, чем система

Систем резервного копирования множество, но что делать, если обслуживаемые сервера разбросаны по разным регионам и клиентам и нужно обходиться средствами операционной системы?

Добрый день, 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 через pg_dump, бэкап каталога файловой системы через 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, выкатывая сначала на часть наименее важных серверов, а после тестирования на все остальные.

В итоге мы получили компактную автономную утилиту копирования, поддающуюся автоматизации и пригодную для эксплуатации даже малоопытными администраторами. Нам удобно – может, пригодится и вам?