Системите за резервно копиране са много, но какво да правим, ако обслужваните сървъри са разпръснати в различни региони и на различни клиенти, и трябва да разчитаме на операционната система?
Добър ден, 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: описание на всички задания (набори от действия) и график на тяхното изпълнение по cron, ако се изисква такова изпълнение
Какво умее приложението в момента:
- поддържат се основните операции: бекап на PostgreSQL чрез pg_dump, бекап на директорията на файловата система чрез tar; операции с външно хранилище; rsync между директории; ротация на бекапите (изтриване на стари копия)
- извикване на външен скрипт
- изпълнение на отделна задача ръчно
/opt/KristaBackup/KristaBackup.py run make_full_dump - може да се добави (или премахне) отделна задача или целия график в crontab
/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
