Систем резервного копирования множество, но что делать, если обслуживаемые сервера разбросаны по разным регионам и клиентам и нужно обходиться средствами операционной системы?
Добрый день, 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, выкатывая сначала на часть наименее важных серверов, а после тестирования на все остальные.
В итоге мы получили компактную автономную утилиту копирования, поддающуюся автоматизации и пригодную для эксплуатации даже малоопытными администраторами. Нам удобно – может, пригодится и вам?
KorP
Ну вы бы хоть написали пару слов — чем ваше решение лучше, чем имеющиеся именитые конкуренты (как платные, так и бесплатные) на рынке.
Loxmatiymamont
… и в чём заключается бекап =)
anonymous Автор
Ну в двух словах я и написала — почему нам не подошли готовые решения.
Нельзя поставить платный софт клиенту, который его не покупал — так что платные «именитые конкуренты» отпадают сразу.
Бесплатные именитые — если говорить про Bacula/BareOs, Amanda и подобные — то они: а) клиент-серверные; б) сложные в настройке.
Клиент-серверные для нас непригодны в принципе — мы не можем хранить бэкапы в некотором центральном хранилище, и как правило, не можем раскрывать много портов для взаимодействия клиента и центрального сервера.
Про сложность настройки — очень для меня показательны комментарии автора (под спойлерами в начале статьи) вот здесь wiki.astralinux.ru/display/doc/BACULA
Наша утилита — у меня даже язык не поворачивается назвать ее «решением» — это немного сложнее и немного функциональнее, чем простой bash-скрипт, которым, я думаю, многие пользуются до сих пор. Но при этом гораздо, гораздо проще именитых конкурентов — скопировал каталог, скопировал/подкорректировал конфиг, запустил. Мне не страшно отдать эту утилиту для расстановки даже новичку, и ему не требуется проникновения в тайны настройки решения, чтобы корректно настроить тот маленький бэкап, который необходим для восстановления в случае сбоя.
KorP
Veeam Agent Linux есть бесплатной версии, прост до безумия и поддерживает бекап без сервера… Это просто один из примеров.
anonymous Автор
Спасибо, посмотрим.
Судя по «проспекту», нам может быть интересно использовать его как один из «кубиков».
Tangeman
Borg или Restic — безсерверные и простые как tar/rsync, с дедупликацией, компрессией, шифрованием, гибкими настройками retention. Для них даже GUI есть. И да, оба удовлетворяют всем вашим требованиями "из коробки".
Corpsee
Restic не умеет компрессию. Пруф: github.com/restic/restic/issues/21.