Още едно архивиране - повече от скрипт, по-просто от система

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

Добър ден, Хабр!
Казвам се Наталия. Аз съм ръководител на групата администратори на приложения в НПО Криста. Ние сме 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 на хранилището.

Основни концепции, с които работи системата:
действие – действие, което изпълнява една атомарна операция (архивиране на база данни, архивиране на директория, прехвърляне от директория A към директория B и т.н.). Съществуващите действия се намират в директорията core/actions
задача – задача, набор от действия, описващи една логическа „задача за архивиране“
график – график, набор от задачи с незадължително посочване на времето за изпълнение на задачата

Резервната конфигурация се съхранява в yaml файл; обща структура на конфигурацията:

• Основни настройки
• раздел за действия: описание на действията, използвани на този сървър
• раздел график: описание на всички задачи (набори от действия) и график за стартирането им от cron, ако се изисква такова стартиране

Примерна конфигурация може да бъде намерена тук

Какво може приложението в момента:

• Поддържат се основните операции за нас: архивиране на PostgreSQL чрез pg_dump, архивиране на директория на файловата система чрез tar; операции с външна памет; rsync между директории; ротация на архивиране (изтриване на стари копия)
• извикване на външен скрипт
• ръчно изпълнение на отделна задача

  /opt/KristaBackup/KristaBackup.py run make_full_dump

• можете да добавите (или премахнете) отделна задача или целия график към crontab

  /opt/KristaBackup/KristaBackup.py enable all

• генериране на задействащ файл въз основа на резултатите от архивирането. Тази функция е полезна във връзка със Zabbix за наблюдение на архиви
• може да работи във фонов режим в webapi или уеб режим

  /opt/KristaBackup/KristaBackup.py web start [--api]

Разликата между режимите: webapi няма собствен уеб интерфейс, но приложението отговаря на заявки от друг екземпляр. За уеб режим трябва да инсталирате колба и няколко допълнителни пакета и това не е приемливо навсякъде, например в сертифициран AstraLinux SE.

Чрез уеб интерфейса можете да видите състоянието и регистрационните файлове на архивите на свързаните сървъри: „уеб екземплярът“ изисква данни от „резервните екземпляри“ чрез API. Достъпът до мрежата изисква оторизация, достъпът до webapi не.

Логовете на неправилни архиви са маркирани с цвят: предупреждение – жълто, грешка – червено.

Ако администраторът не се нуждае от измамен лист за параметрите и сървърните операционни системи са хомогенни, можете да компилирате файла и да разпространите готовия пакет.

Ние разпространяваме тази помощна програма главно чрез Ansible, като я пускаме първо на някои от най-малко важните сървъри и след тестване на всички останали.

В резултат на това получихме компактна, самостоятелна помощна програма за копиране, която може да бъде автоматизирана и може да се използва дори от неопитни администратори. Удобно е за нас - може би ще бъде полезно и за вас?

Източник: www.habr.com