Још једна резервна копија - више од скрипте, једноставније од система

Постоји много система резервних копија, али шта учинити ако су сервери раштркани по различитим регионима и клијентима и морате да се задовољите оперативним системом?

Још једна резервна копија - више од скрипте, једноставније од система

Добар дан, Хабр!
Моје име је Наталија. Ја сам вођа тима групе администратора апликација у НПО Криста. Ми смо оперативни за пројектну групу наше компаније. Имамо прилично јединствену ситуацију: инсталирамо и одржавамо наш софтвер и на серверима наше компаније и на серверима који се налазе на локацијама клијената. У овом случају, нема потребе да правите резервну копију целог сервера. Важни су само „основни подаци“: ДБМС и појединачни директоријуми система датотека. Наравно, клијенти имају (или немају) сопствене прописе за прављење резервних копија и често обезбеђују неку врсту спољне меморије за складиштење резервних копија тамо. У овом случају, након креирања резервне копије, обезбеђујемо слање на спољну меморију.

Неко време, ради резервних копија, радили смо са басх скриптом, али како су опције конфигурације расле, сложеност ове скрипте је пропорционално расла и у једном тренутку смо дошли до потребе да је „уништимо до темеља, а затим ...”.

Готова решења нису била погодна из разних разлога: због потребе за децентрализацијом резервних копија, захтева да се резервне копије чувају локално код клијента, сложености подешавања, замене увоза, ограничења приступа.

Чинило нам се да је лакше написати нешто своје. Истовремено, желео сам да добијем нешто што би за нашу ситуацију било довољно за наредних Н година, али са могућношћу потенцијалног проширења обима.

Услови задатка су били следећи:

  1. основна резервна инстанца је аутономна и ради се локално
  2. складиштење резервних копија и евиденција је увек унутар мреже клијента
  3. инстанца се састоји од модула - нека врста "конструктора"
  4. потребна је компатибилност са тренутним дистрибуцијама Линука, укључујући застареле, пожељна је потенцијална унакрсна платформа
  5. За рад са инстанцом довољан је приступ преко ссх; отварање додатних портова није неопходно
  6. максимална лакоћа подешавања и рада
  7. могуће је (али није неопходно) имати засебну инстанцу која вам омогућава да централно видите статус резервних копија са различитих сервера

Овде можете видети шта смо смислили: гитхуб.цом/јавистер/криста-бацкуп
Софтвер је написан у питхон3; ради на Дебиану, Убунту, ЦентОС, АстраЛинук 1.6.

Документација се поставља у директоријум докумената спремишта.

Основни концепти којима систем функционише:
акција – акција која имплементира једну атомску операцију (резервна копија базе података, резервна копија директоријума, пренос из директоријума А у директоријум Б, итд.). Постојеће акције се налазе у директоријуму цоре/ацтионс
задатак – задатак, скуп радњи које описују један логички „резервни задатак“
распоред – распоред, скуп задатака са опционом индикацијом времена извршења задатка

Конфигурација резервне копије се чува у иамл датотеци; општа структура конфигурације:

  • Општа подешавања
  • одељак акција: опис акција које се користе на овом серверу
  • одељак распореда: опис свих задатака (скупова акција) и распоред за њихово покретање црон-ом, ако је такво покретање потребно

Пример конфигурације можете пронаћи овде

Шта апликација тренутно може да уради:

  • Подржане су главне операције за нас: ПостгреСКЛ резервна копија преко пг_думп, резервна копија директоријума система датотека преко тар; операције са екстерним складиштем; рсинц између директоријума; ротација резервних копија (брисање старих копија)
  • позивање спољне скрипте
  • ручно извршење посебног задатка
    /opt/KristaBackup/KristaBackup.py run make_full_dump
  • можете додати (или уклонити) један задатак или цео распоред у цронтаб
    /opt/KristaBackup/KristaBackup.py enable all
  • генерисање датотеке окидача на основу резултата резервне копије. Ова функција је корисна у комбинацији са Заббик-ом за праћење резервних копија
  • може да ради у позадини у вебапи или веб режиму
    /opt/KristaBackup/KristaBackup.py web start [--api]

Разлика између режима: вебапи нема сам веб интерфејс, али апликација одговара на захтеве друге инстанце. За веб режим, потребно је да инсталирате фласк и неколико додатних пакета, а то није свуда прихватљиво, на пример у сертификованом АстраЛинук СЕ.

Преко веб интерфејса можете да видите статус и евиденцију резервних копија повезаних сервера: „веб инстанца“ захтева податке од „резервних инстанци“ преко АПИ-ја. Приступ вебу захтева ауторизацију, а приступ вебапи не.

Још једна резервна копија - више од скрипте, једноставније од система

Дневници нетачних резервних копија су означени бојом: упозорење – жуто, грешка – црвено.

Још једна резервна копија - више од скрипте, једноставније од система

Још једна резервна копија - више од скрипте, једноставније од система

Ако администратору није потребна варалица о параметрима, а оперативни системи сервера су хомогени, можете саставити датотеку и дистрибуирати готов пакет.

Овај услужни програм дистрибуирамо углавном преко Ансибле-а, пуштајући га прво на неке од најмање важних сервера, а након тестирања на све остале.

Као резултат тога, добили смо компактан, самосталан услужни програм за копирање који се може аутоматизовати и може га користити чак и неискусни администратори. То је згодно за нас - можда ће бити корисно и за вас?

Извор: ввв.хабр.цом

Додај коментар