Систем резервного копіювання безліч, але що робити, якщо сервери, що обслуговуються, розкидані по різних регіонах і клієнтам і потрібно обходитися засобами операційної системи?
Добрий день, Habr!
Мене звати Наталя. Я тимлід групи адміністраторів додатків до НВО «Криста». Ми Ops для групи проектів нашої компанії. У нас досить своєрідна ситуація: ми встановлюємо та супроводжуємо наше ПЗ як на серверах нашої компанії, так і на серверах, розташованих у клієнтів. При цьому бекапит сервер цілком немає необхідності. Важливими є лише «суттєві дані»: СУБД і окремі каталоги файлової системи. Звичайно, клієнти мають (або не мають) свої регламенти резервного копіювання та часто надають якесь зовнішнє сховище для складання туди резервних копій. У цьому випадку після створення бекапу ми забезпечуємо відправлення до зовнішнього сховища.
Якийсь час для цілей бекапу ми обходилися bash-скриптом, але в міру розростання варіантів налаштувань пропорційно зростала і заплутаність цього скрипта, і одного разу ми дійшли необхідності його «зруйнувати вщент, а потім…».
Готові рішення не підійшли з різних причин: через необхідність децентралізації бекапів, обов'язковість зберігання бекапів локально у клієнта, складність налаштування, імпортозаміщення, обмеження доступу.
Нам здалося, що простіше щось написати. При цьому хотілося отримати щось таке, чого вистачить для нашої ситуації на наступні N років, але з можливістю потенційного розширення сфери застосування.
Умови завдання були такі:
- базовий інстанс бекапу автономен, працює локально
- зберігання резервних копій та логів завжди в межах мережі клієнта
- інстанс складається з модулів – такий своєрідний «конструктор»
- необхідна сумісність із використовуваними дистрибутивами Linux, включаючи застарілі, бажана потенційна кросплатформність
- для роботи з інстансом достатньо доступу по ssh, відкриття додаткових портів необов'язкове
- максимальна простота налаштування та експлуатації
- можливе (але не обов'язково) існування окремого інстансу, що дозволяє централізовано переглянути стан бекапів з різних серверів
Те, що в нас вийшло, можна побачити тут:
ПЗ написано на 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, викочуючи спочатку на частину найменш важливих серверів, а після тестування на решту.
У результаті ми отримали компактну автономну утиліту копіювання, що піддається автоматизації та придатну для експлуатації навіть малодосвідченими адміністраторами. Нам зручно - може, знадобиться і вам?
Джерело: habr.com