[*nix, Резервное копирование] Eще один бэкап — больше, чем скрипт, проще, чем система
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Систем резервного копирования множество, но что делать, если обслуживаемые сервера разбросаны по разным регионам и клиентам и нужно обходиться средствами операционной системы?
Добрый день, 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, выкатывая сначала на часть наименее важных серверов, а после тестирования на все остальные.
В итоге мы получили компактную автономную утилиту копирования, поддающуюся автоматизации и пригодную для эксплуатации даже малоопытными администраторами. Нам удобно – может, пригодится и вам?
===========
Источник:
habr.com
===========
Похожие новости:
- [*nix, Open source] FOSS News №26 – обзор новостей свободного и открытого ПО за 20–26 июля 2020 года
- [*nix] Кризис дистрибутивостроения или «о Gentoo в последний раз»
- [*nix, Бизнес-модели, Венчурные инвестиции, Транспорт] Tesla — ожидания и прогнозы. Чего ждать от Маска и его конкурентов до конца 2020 года?
- [IT-инфраструктура, Облачные сервисы, Резервное копирование] Почтовый переезд: как мы меняли бэкап электронной почты с Acronis на Veeam
- [Java] IntelliJ IDEA: Structural Search and Replace (перевод)
- [Хранение данных, Компьютерное железо, Настольные компьютеры, Ноутбуки] Kingston DataTraveler: новое поколение защищенных флешек
- [DevOps, Тестирование веб-сервисов] Как восстановить Sentry после не удачного обновления
- [Резервное копирование, Хранение данных, Хранилища данных, Накопители] Практические кейсы по созданию IT-инфраструктуры на базе дисковых полок Western Digital Ultrastar
- [*nix, Анализ и проектирование систем, Серверное администрирование, Системное администрирование] Разрабатываем самый удобный в мире* интерфейс для просмотра логов
- [IT-инфраструктура, Системы обмена сообщениями] Платформа «Mail.ru для бизнеса» проведет вебинар по корпоративным сервисам коммуникаций
Теги для поиска: #_*nix, #_rezervnoe_kopirovanie (Резервное копирование), #_backup, #_bekap (бэкап), #_rezervnoe_kopirovanie (резервное копирование), #_skripty (скрипты), #_importozameschenie (импортозамещение), #_blog_kompanii_npo_krista (
Блог компании НПО Криста
), #_*nix, #_rezervnoe_kopirovanie (
Резервное копирование
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 22:13
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Систем резервного копирования множество, но что делать, если обслуживаемые сервера разбросаны по разным регионам и клиентам и нужно обходиться средствами операционной системы?  Добрый день, 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, выкатывая сначала на часть наименее важных серверов, а после тестирования на все остальные. В итоге мы получили компактную автономную утилиту копирования, поддающуюся автоматизации и пригодную для эксплуатации даже малоопытными администраторами. Нам удобно – может, пригодится и вам? =========== Источник: habr.com =========== Похожие новости:
Блог компании НПО Криста ), #_*nix, #_rezervnoe_kopirovanie ( Резервное копирование ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 22:13
Часовой пояс: UTC + 5