Систем резервного копирования множество, но что делать, если обслуживаемые сервера разбросаны по разным регионам и клиентам и нужно обходиться средствами операционной системы?
Добрый день, Habr!
Меня зовут Наталья. Я тимлид группы администраторов приложений в НПО «Криста». Мы Ops для группы проектов нашей компании. У нас довольно своеобразная ситуация: мы устанавливаем и сопровождаем наше ПО как на серверах нашей компании, так и на серверах, расположенных у клиентов. При этом бэкапить сервер целиком нет необходимости. Важны лишь «существенные данные»: СУБД и отдельные каталоги файловой системы. Конечно, клиенты имеют (или не имеют) свои регламенты резервного копирования и часто предоставляют некое внешнее хранилище для складывания туда резервных копий. В этом случае после создания бэкапа мы обеспечиваем отправку во внешнее хранилище.
Какое-то время для целей бэкапа мы обходились bash-скриптом, но по мере разрастания вариантов настроек пропорционально росла и запутанность этого скрипта, и в один прекрасный момент мы пришли к необходимости его «разрушить до основанья, а затем....».
Готовые решения не подошли по разным причинам: из-за необходимости децентрализации бэкапов, обязательности хранения бэкапов локально у клиента, сложности настройки, импортозамещения, ограничения доступа.
Нам показалось, что проще написать что-то своё. При этом хотелось получить что-то такое, чего хватит для нашей ситуации на следующие N лет, но с возможностью потенциального расширения области применения.
Условия задачи были следующие:
То, что у нас получилось, можно посмотреть здесь: github.com/javister/krista-backup
ПО написано на python3; работает на Debian, Ubuntu, CentOS, AstraLinux 1.6.
Документация выложена в каталоге docs репозитария.
Основные понятия, которыми оперирует система:
action – действие, реализующее одну атомарную операцию (бэкап БД, бэкап каталога, перенос из каталога А в каталог Б и т. д.). Существующие actions лежат в каталоге core/actions
task – задание, набор actions, описывающий одну логическую «задачу бэкапа»
schedule – расписание, набор task с опциональным указанием времени выполнения задачи
Конфигурация бэкапа хранится в yaml-файле; общая структура конфига:
Пример конфига можно посмотреть здесь
Что умеет приложение на текущий момент:
Разница между режимами: в webapi нет собственно веб-интерфейса, но приложение отвечает на запросы другого инстанса. Для режима web нужно установить flask и несколько дополнительных пакетов, а это не везде приемлемо, например в сертифицированной AstraLinux SE.
Через веб-интерфейс можно посмотреть состояние и логи бэкапов подключенных серверов: «веб-инстанс» запрашивает данные с «бэкап-инстансов» через API. Доступ к web требует авторизации, доступ к webapi – нет.
Логи некорректно прошедших бэкапов размечаются цветом: warning – желтым, error – красным.
Если администратору не нужна шпаргалка по параметрам и серверные ОС однородны, можно скомпилировать файл и распространять уже готовый пакет.
Распространяем мы эту утилиту в основном через Ansible, выкатывая сначала на часть наименее важных серверов, а после тестирования на все остальные.
В итоге мы получили компактную автономную утилиту копирования, поддающуюся автоматизации и пригодную для эксплуатации даже малоопытными администраторами. Нам удобно – может, пригодится и вам?
Добрый день, Habr!
Меня зовут Наталья. Я тимлид группы администраторов приложений в НПО «Криста». Мы Ops для группы проектов нашей компании. У нас довольно своеобразная ситуация: мы устанавливаем и сопровождаем наше ПО как на серверах нашей компании, так и на серверах, расположенных у клиентов. При этом бэкапить сервер целиком нет необходимости. Важны лишь «существенные данные»: СУБД и отдельные каталоги файловой системы. Конечно, клиенты имеют (или не имеют) свои регламенты резервного копирования и часто предоставляют некое внешнее хранилище для складывания туда резервных копий. В этом случае после создания бэкапа мы обеспечиваем отправку во внешнее хранилище.
Какое-то время для целей бэкапа мы обходились bash-скриптом, но по мере разрастания вариантов настроек пропорционально росла и запутанность этого скрипта, и в один прекрасный момент мы пришли к необходимости его «разрушить до основанья, а затем....».
Готовые решения не подошли по разным причинам: из-за необходимости децентрализации бэкапов, обязательности хранения бэкапов локально у клиента, сложности настройки, импортозамещения, ограничения доступа.
Нам показалось, что проще написать что-то своё. При этом хотелось получить что-то такое, чего хватит для нашей ситуации на следующие N лет, но с возможностью потенциального расширения области применения.
Условия задачи были следующие:
- базовый инстанс бэкапа автономен, работает локально
- хранение резервных копий и логов всегда в пределах сети клиента
- инстанс состоит из модулей – такой своеобразный «конструктор»
- необходима совместимость с используемыми дистрибутивами Linux, включая устаревшие, желательна потенциальная кроссплатформенность
- для работы с инстансом достаточно доступа по ssh, открытие дополнительных портов необязательно
- максимальная простота настройки и эксплуатации
- возможно (но не обязательно) существование отдельного инстанса, позволяющего централизованно просмотреть состояние бэкапов с разных серверов
То, что у нас получилось, можно посмотреть здесь: github.com/javister/krista-backup
ПО написано на python3; работает на Debian, Ubuntu, CentOS, AstraLinux 1.6.
Документация выложена в каталоге docs репозитария.
Основные понятия, которыми оперирует система:
action – действие, реализующее одну атомарную операцию (бэкап БД, бэкап каталога, перенос из каталога А в каталог Б и т. д.). Существующие actions лежат в каталоге core/actions
task – задание, набор actions, описывающий одну логическую «задачу бэкапа»
schedule – расписание, набор task с опциональным указанием времени выполнения задачи
Конфигурация бэкапа хранится в yaml-файле; общая структура конфига:
- общие настройки
- раздел actions: описание действий, используемых на этом сервере
- раздел schedule: описание всех заданий (наборов действий) и расписание их запуска по крону, если такой запуск требуется
Пример конфига можно посмотреть здесь
Что умеет приложение на текущий момент:
- поддерживаются основные для нас операции: бэкап 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, выкатывая сначала на часть наименее важных серверов, а после тестирования на все остальные.
В итоге мы получили компактную автономную утилиту копирования, поддающуюся автоматизации и пригодную для эксплуатации даже малоопытными администраторами. Нам удобно – может, пригодится и вам?