Maraming backup system, ngunit ano ang gagawin kung ang mga server na inihatid ay nakakalat sa iba't ibang rehiyon at mga kliyente at kailangan mong gawin ang operating system?
Magandang hapon, Habr!
Ang pangalan ko ay Natalya. Ako ang pinuno ng pangkat ng grupo ng mga administrator ng aplikasyon sa NPO Krista. Kami ay Ops para sa grupo ng proyekto ng aming kumpanya. Mayroon kaming kakaibang sitwasyon: ini-install at pinapanatili namin ang aming software sa mga server ng aming kumpanya at sa mga server na matatagpuan sa mga site ng mga kliyente. Sa kasong ito, hindi na kailangang i-backup ang buong server. Tanging ang "mahahalagang data" ang mahalaga: ang DBMS at mga indibidwal na direktoryo ng file system. Siyempre, ang mga kliyente ay may (o wala) ng kanilang sariling mga regulasyon sa pag-backup at kadalasang nagbibigay ng ilang uri ng panlabas na imbakan para sa pag-iimbak ng mga backup doon. Sa kasong ito, pagkatapos gumawa ng backup, tinitiyak namin ang pagpapadala sa panlabas na storage.
Sa loob ng ilang panahon, para sa mga layunin ng pag-backup, gumawa kami ng isang bash script, ngunit habang lumalaki ang mga pagpipilian sa pagsasaayos, ang pagiging kumplikado ng script na ito ay lumago nang proporsyonal, at sa isang punto ay dumating kami sa pangangailangan na "sirain ito sa lupa, at pagkatapos ...".
Ang mga handa na solusyon ay hindi angkop para sa iba't ibang mga kadahilanan: dahil sa pangangailangan na i-desentralisa ang mga backup, ang pangangailangan na mag-imbak ng mga backup nang lokal sa kliyente, pagiging kumplikado ng pag-setup, pagpapalit ng pag-import, mga paghihigpit sa pag-access.
Para sa amin ay mas madaling magsulat ng sarili naming bagay. Kasabay nito, nais kong makakuha ng isang bagay na magiging sapat para sa aming sitwasyon para sa susunod na N taon, ngunit may posibilidad na potensyal na mapalawak ang saklaw.
Ang mga kondisyon ng gawain ay ang mga sumusunod:
- ang pangunahing backup na halimbawa ay nagsasarili at tumatakbo nang lokal
- Ang imbakan ng mga backup at log ay palaging nasa network ng kliyente
- isang instance ay binubuo ng mga module - isang uri ng "constructor"
- ang pagiging tugma sa kasalukuyang mga pamamahagi ng Linux ay kinakailangan, kabilang ang mga luma na, ang potensyal na cross-platform ay kanais-nais
- Upang gumana sa halimbawa, ang pag-access sa pamamagitan ng ssh ay sapat; hindi kinakailangan ang pagbubukas ng mga karagdagang port
- maximum na kadalian ng pag-setup at pagpapatakbo
- posible (ngunit hindi kinakailangan) na magkaroon ng isang hiwalay na instance na nagbibigay-daan sa iyong sentral na tingnan ang katayuan ng mga backup mula sa iba't ibang mga server
Makikita mo kung ano ang naisip namin dito:
Ang software ay nakasulat sa python3; gumagana sa Debian, Ubuntu, CentOS, AstraLinux 1.6.
Ang dokumentasyon ay nai-post sa direktoryo ng docs ng repositoryo.
Mga pangunahing konsepto na pinapatakbo ng system:
aksyon β isang aksyon na nagpapatupad ng isang atomic na operasyon (backup ng database, backup ng direktoryo, paglipat mula sa direktoryo A patungo sa direktoryo B, atbp.). Ang mga kasalukuyang aksyon ay matatagpuan sa core/actions directory
gawain - gawain, isang hanay ng mga aksyon na naglalarawan ng isang lohikal na "backup na gawain"
iskedyul β iskedyul, isang hanay ng mga gawain na may opsyonal na indikasyon ng oras ng pagsasagawa ng gawain
Ang backup na configuration ay naka-imbak sa isang yaml file; pangkalahatang istraktura ng config:
- Pangkalahatang mga Setting
- seksyon ng mga aksyon: paglalarawan ng mga pagkilos na ginamit sa server na ito
- seksyon ng iskedyul: paglalarawan ng lahat ng mga gawain (mga hanay ng mga aksyon) at iskedyul para sa kanilang paglulunsad sa pamamagitan ng cron, kung kinakailangan ang naturang paglulunsad
Ano ang kasalukuyang magagawa ng application:
- Ang mga pangunahing operasyon para sa amin ay suportado: PostgreSQL backup sa pamamagitan ng pg_dump, file system directory backup sa pamamagitan ng tar; mga operasyon na may panlabas na imbakan; rsync sa pagitan ng mga direktoryo; backup rotation (pagtanggal ng mga lumang kopya)
- pagtawag ng panlabas na script
- manu-manong pagpapatupad ng isang hiwalay na gawain
/opt/KristaBackup/KristaBackup.py run make_full_dump - maaari kang magdagdag (o mag-alis) ng isang gawain o ang buong iskedyul sa crontab
/opt/KristaBackup/KristaBackup.py enable all - pagbuo ng trigger file batay sa mga backup na resulta. Ang function na ito ay kapaki-pakinabang kasabay ng Zabbix para sa pagsubaybay sa mga backup
- maaaring gumana sa background sa webapi o web mode
/opt/KristaBackup/KristaBackup.py web start [--api]
Ang pagkakaiba sa pagitan ng mga mode: ang webapi ay walang web interface mismo, ngunit ang application ay tumutugon sa mga kahilingan mula sa isa pang pagkakataon. Para sa web mode, kailangan mong mag-install ng flask at ilang karagdagang mga pakete, at hindi ito katanggap-tanggap sa lahat ng dako, halimbawa sa sertipikadong AstraLinux SE.
Sa pamamagitan ng web interface, maaari mong tingnan ang status at mga log ng mga backup ng mga konektadong server: humihiling ang βweb instanceβ ng data mula sa βbackup instanceβ sa pamamagitan ng API. Ang pag-access sa web ay nangangailangan ng pahintulot, ang pag-access sa webapi ay hindi.
Ang mga log ng mga maling backup ay minarkahan ng kulay: babala β dilaw, error β pula.
Kung ang administrator ay hindi nangangailangan ng cheat sheet sa mga parameter at ang mga operating system ng server ay homogenous, maaari mong i-compile ang file at ipamahagi ang handa na pakete.
Ibinabahagi namin ang utility na ito pangunahin sa pamamagitan ng Ansible, inilalabas muna ito sa ilan sa hindi gaanong mahalagang mga server, at pagkatapos ng pagsubok sa lahat ng iba pa.
Bilang resulta, nakatanggap kami ng compact, stand-alone na copy utility na maaaring i-automate at magagamit kahit ng mga walang karanasan na mga administrator. Ito ay maginhawa para sa amin - marahil ito ay magiging kapaki-pakinabang din para sa iyo?
Pinagmulan: www.habr.com