Paano ka tinutulungan ng GitLab na mag-backup ng malalaking imbakan ng NextCloud

Hoy Habr!

Ngayon gusto kong pag-usapan ang aming karanasan sa pag-automate ng backup ng malaking data mula sa mga storage ng Nextcloud sa iba't ibang mga configuration. Nagtatrabaho ako bilang isang istasyon ng serbisyo sa Molniya AK, kung saan ginagawa namin ang pamamahala ng pagsasaayos ng mga IT system; Ang Nextcloud ay ginagamit para sa pag-iimbak ng data. Kasama, na may distributed structure, na may redundancy.

Ang mga problema na nagmumula sa mga tampok ng mga pag-install ay mayroong maraming data. Ang pag-bersyon na ibinigay ng Nextcloud, redundancy, mga pansariling dahilan, at higit pa ay lumilikha ng maraming duplicate.

prehistory

Kapag pinangangasiwaan ang Nextcloud, ang problema sa pag-aayos ng isang epektibong backup ay lumitaw, na dapat na naka-encrypt, dahil ang data ay mahalaga.

Nag-aalok kami ng mga opsyon para sa pag-iimbak ng mga backup sa aming lugar o sa customer sa hiwalay na mga makina mula sa Nextcloud, na nangangailangan ng isang flexible na awtomatikong diskarte sa pangangasiwa.

Mayroong maraming mga kliyente, lahat sila ay may iba't ibang mga pagsasaayos, at lahat sa kanilang sariling mga site at may kanilang sariling mga katangian. Ito ay isang karaniwang pamamaraan kapag ang buong site ay pagmamay-ari mo, at ang mga backup ay ginawa mula sa mga korona; hindi ito magkasya nang maayos.

Una, tingnan natin ang data ng pag-input. Kailangan namin:

• Scalability sa mga tuntunin ng isang node o ilang. Para sa malalaking pag-install ginagamit namin ang minio bilang imbakan.
• Alamin ang tungkol sa mga problema sa pagsasagawa ng mga backup.
• Kailangan mong magtago ng backup sa iyong mga kliyente at/o sa amin.
• Haharapin ang mga problema nang mabilis at madali.
• Ang mga kliyente at pag-install ay ibang-iba sa isa't isa - hindi makakamit ang pagkakapareho.
• Ang bilis ng pagbawi ay dapat na minimal sa dalawang senaryo: ganap na pagbawi (disaster), isang folder na nabura nang hindi sinasadya.
• Kinakailangan ang pagpapaandar ng deduplication.

Upang malutas ang problema sa pamamahala ng mga backup, nag-install kami ng GitLab. Higit pang mga detalye sa pamamagitan ng tackle.

Siyempre, hindi kami ang unang lumutas ng gayong problema, ngunit tila sa amin na ang aming praktikal, pinaghirapang karanasan ay maaaring maging kawili-wili at handa kaming ibahagi ito.

Dahil may open source policy ang aming kumpanya, naghahanap kami ng open source na solusyon. Sa turn, ibinabahagi namin ang aming mga pag-unlad at nai-post ang mga ito. Halimbawa, sa GitHub mayroong ang aming plugin para sa Nextcloud, na ibinibigay namin sa mga kliyente, na nagpapahusay sa seguridad ng data sa kaso ng aksidente o sinadyang pagtanggal.

Mga tool sa pag-backup

Sinimulan namin ang aming paghahanap para sa mga paraan ng solusyon sa pamamagitan ng pagpili ng backup na tool sa paglikha.

Ang regular na tar + gzip ay hindi gumagana nang maayos - ang data ay nadoble. Ang isang pagtaas ay kadalasang naglalaman ng napakakaunting mga aktwal na pagbabago, at karamihan sa data sa loob ng isang file ay inuulit.
May isa pang problema - kalabisan ng ibinahagi na imbakan ng data. Gumagamit kami ng minio at ang data nito ay karaniwang kalabisan. O kailangan mong gumawa ng isang backup sa pamamagitan ng minio mismo - i-load ito at gamitin ang lahat ng mga spacer sa pagitan ng file system, at, hindi gaanong mahalaga, may panganib na makalimutan ang tungkol sa ilan sa mga bucket at meta-impormasyon. O gumamit ng deduplication.

Ang mga backup na tool na may duplikasyon ay magagamit sa open source (sa Habré mayroong Artikulo tungkol sa temang ito) at ang aming mga finalist ay Borg и Nagpahinga. Ang aming paghahambing ng dalawang application ay nasa ibaba, ngunit sa ngayon ay sasabihin namin sa iyo kung paano namin inayos ang buong scheme.

Pamamahala ng mga backup

Maganda ang Borg at Restic, ngunit wala sa alinmang produkto ang may sentralisadong mekanismo ng kontrol. Para sa layunin ng pamamahala at kontrol, pumili kami ng isang tool na naipatupad na namin, kung wala ito ay hindi namin maiisip ang aming trabaho, kabilang ang automation - ito ang kilalang CI/CD - GitLab.

Ang ideya ay ang mga sumusunod: naka-install ang gitlab-runner sa bawat node na nag-iimbak ng data ng Nextcloud. Ang runner ay nagpapatakbo ng script sa isang iskedyul na sinusubaybayan ang proseso ng pag-backup, at inilulunsad nito ang Borg o Restic.

Ano ang nakuha namin? Feedback mula sa pagpapatupad, maginhawang kontrol sa mga pagbabago, mga detalye sa kaso ng isang error.

Dito dito sa GitHub nag-post kami ng mga halimbawa ng script para sa iba't ibang mga gawain, at natapos namin itong ilakip sa backup ng hindi lamang Nextcloud, kundi pati na rin ng maraming iba pang mga serbisyo. Mayroon ding scheduler doon kung ayaw mong i-configure ito nang manu-mano (at ayaw namin) at .gitlab-ci.yml

Wala pang paraan para baguhin ang CI/CD timeout sa Gitlab API, ngunit maliit lang ito. Kailangang dagdagan, sabi sa 1d.

Ang GitLab, sa kabutihang palad, ay maaaring maglunsad hindi lamang ayon sa isang pangako, ngunit ayon lamang sa isang iskedyul, ito mismo ang kailangan natin.

Ngayon tungkol sa script ng wrapper.

Itinakda namin ang mga sumusunod na kundisyon para sa script na ito:

• Dapat itong ilunsad kapwa ng runner at sa pamamagitan ng kamay mula sa console na may parehong pag-andar.
• Dapat mayroong mga tagapangasiwa ng error:
• ibalik ang code.
• maghanap ng string sa log. Halimbawa, para sa amin, ang isang error ay maaaring isang mensahe na hindi itinuturing ng program na nakamamatay.
• Pagproseso ng timeout. Ang lead time ay dapat na makatwiran.
• Kailangan namin ng isang napaka detalyadong log. Ngunit lamang sa kaso ng isang error.
• Ang ilang mga pagsubok ay isinasagawa din bago magsimula.
• Maliit na bonus para sa kaginhawahan na nakita naming kapaki-pakinabang sa proseso ng suporta:
• Ang simula at pagtatapos ay naitala sa syslog ng lokal na makina. Nakakatulong ito upang ikonekta ang mga error sa system at backup na operasyon.
• Bahagi ng log ng error, kung mayroon man, ay output sa stdout, ang buong log ay nakasulat sa isang hiwalay na file. Ito ay maginhawa upang agad na tumingin sa CI at suriin ang error kung ito ay walang halaga.
• Mga mode ng pag-debug.

Ang buong log ay nai-save bilang isang artifact sa GitLab; kung walang error, ang log ay tatanggalin. Sinusulat namin ang script sa bash.

Ikalulugod naming isaalang-alang ang anumang mga mungkahi at komento tungkol sa open source - maligayang pagdating.

Как это работает

Ang isang runner na may Bash executor ay inilunsad sa backup node. Ayon sa scheduler, ang trabaho CI/CD ay inilunsad sa isang espesyal na singkamas. Ang runner ay naglulunsad ng isang unibersal na script ng wrapper para sa mga naturang gawain, sinusuri nito ang bisa ng backup na repository, mga mount point at lahat ng gusto natin, pagkatapos ay i-back up at linisin ang luma. Ang natapos na backup mismo ay ipinadala sa S3.

Nagtatrabaho kami ayon sa scheme na ito - isa itong external na provider ng AWS o katumbas ng Russian (mas mabilis ito at hindi umaalis sa Russian Federation ang data). O nag-i-install kami ng hiwalay na minio cluster para sa kliyente sa kanyang site para sa mga layuning ito. Karaniwan naming ginagawa ito para sa mga kadahilanang pangseguridad, kapag ayaw ng kliyente na umalis ang data sa kanilang circuit.

Hindi namin ginamit ang tampok na pagpapadala ng backup sa pamamagitan ng ssh. Hindi ito nagdaragdag ng seguridad, at ang mga kakayahan ng network ng S3 provider ay mas mataas kaysa sa aming isang ssh machine.

Upang maprotektahan ang iyong lokal na makina mula sa isang hacker, dahil maaari niyang burahin ang data sa S3, dapat mong paganahin ang bersyon.
Palaging ine-encrypt ng backup ang backup.

May unencrypted mode si Borg none, ngunit lubos naming hindi inirerekomenda na i-on ito. Sa mode na ito, hindi lamang magkakaroon ng pag-encrypt, ngunit ang checksum ng kung ano ang nakasulat ay hindi kinakalkula, na nangangahulugang ang integridad ay maaari lamang suriin nang hindi direkta, gamit ang mga index.

Sinusuri ng hiwalay na scheduler ang mga backup para sa integridad ng mga index at nilalaman. Mabagal at mahaba ang tseke, kaya hiwalay kaming nagpapatakbo nito minsan sa isang buwan. Maaaring tumagal ng ilang araw.

Readme sa Russian

Pangunahing pag-andar

• prepare pagsasanay
• testcheck pagsusuri ng kahandaan
• maincommand pangunahing koponan
• forcepostscript isang function na naisakatuparan sa dulo o sa pamamagitan ng error. Ginagamit namin ito para i-unmount ang partition.

Mga function ng serbisyo

• cleanup Nagtatala kami ng mga error o binubura ang log file.
• checklog i-parse ang log para sa paglitaw ng isang linya na may error.
• ret exit handler.
• checktimeout tingnan kung may timeout.

kapaligiran

• VERBOSE=1 Nagpapakita kami ng mga error sa screen kaagad (stdout).
• SAVELOGSONSUCCES=1 i-save ang log sa tagumpay.
• INIT_REPO_IF_NOT_EXIST=1 Gumawa ng repository kung wala ito. Hindi pinagana bilang default.
• TIMEOUT maximum na oras para sa pangunahing operasyon. Maaari mo itong itakda bilang 'm', 'h' o 'd' sa dulo.

Storage mode para sa mga lumang kopya. Default:

• KEEP_DAILY=7
• KEEP_WEEKLY=4
• KEEP_MONTHLY=6

Mga variable sa loob ng script

• ERROR_STRING — string para sa check in log para sa error.
• EXTRACT_ERROR_STRING — expression para sa show string if error.
• KILL_TIMEOUT_SIGNAL — hudyat para sa pagpatay kung timeout.
• TAIL — kung gaano karaming mga string ang may mga error sa screen.
• COLORMSG — kulay ng mensahe (default na dilaw).

Ang script na iyon, na kung saan ay tinatawag na wordpress, ay may isang kondisyon na pangalan, ang trick nito ay na-back up din nito ang mysql database. Nangangahulugan ito na maaari itong magamit para sa mga single-node na pag-install ng Nexcloud, kung saan maaari mo ring i-back up ang database. Ang kaginhawahan ay hindi lamang na ang lahat ay nasa isang lugar, kundi pati na rin ang mga nilalaman ng database ay malapit sa mga nilalaman ng mga file, dahil ang pagkakaiba sa oras ay minimal.

Restic vs Borg

Mayroon ding mga paghahambing sa pagitan ng Borg at Restic dito sa Habré, at wala kaming gawaing gumawa ng isa pa, ngunit sa amin. Mahalaga sa amin kung ano ang magiging hitsura nito sa aming data, kasama ang aming mga detalye. Dinadala namin sila.

Ang aming pamantayan sa pagpili, bilang karagdagan sa mga nabanggit na (deduplication, mabilis na pagbawi, atbp.):

• Paglaban sa hindi natapos na trabaho. Suriin kung may pumatay -9.
• Sukat sa disk.
• Kinakailangan para sa mga mapagkukunan (CPU, memorya).
• Sukat ng mga nakaimbak na patak.
• Nagtatrabaho sa S3.
• Pagsusuri ng integridad.

Para sa pagsubok, kumuha kami ng isang kliyente na may totoong data at kabuuang sukat na 1,6 TB.
Kundisyon.

Hindi alam ni Borg kung paano direktang gumana sa S3, at ini-mount namin ang disk bilang isang fuse, sa pamamagitan ng mga maloko. Ipinadala ito ni Restic sa S3 mismo.

Gumagana nang napakabilis at mahusay ang Goofys, at mayroon module ng cache ng disk, na mas nagpapabilis sa gawain. Nasa beta stage na ito, at, sa totoo lang, nag-crash kami sa pagkawala ng data sa panahon ng mga pagsubok (iba pa). Ngunit ang kaginhawahan ay ang backup na pamamaraan mismo ay hindi nangangailangan ng maraming pagbabasa, ngunit karamihan sa pagsulat, kaya ginagamit lamang namin ang cache sa panahon ng mga pagsusuri sa integridad.

Upang mabawasan ang impluwensya ng network, gumamit kami ng lokal na provider - Yandex Cloud.

Mga resulta ng pagsubok sa paghahambing.

• Ang Kill -9 na may karagdagang pag-restart ay parehong matagumpay.
• Sukat sa disk. Maaaring mag-compress si Borg, kaya ang mga resulta ay tulad ng inaasahan.

Backuper
Laki

Borg
562Gb

Nagpahinga
628Gb

• Sa pamamagitan ng CPU
  Ang Borg mismo ay kumonsumo ng kaunti, na may default na compression, ngunit dapat itong suriin kasama ng proseso ng mga maloko. Sa kabuuan, maihahambing ang mga ito at gumagamit ng humigit-kumulang 1,2 core sa parehong pagsubok na virtual machine.
• Alaala. Ang restic ay humigit-kumulang 0,5GB, ang Borg ay humigit-kumulang 200MB. Ngunit ang lahat ng ito ay hindi gaanong mahalaga kumpara sa cache ng system file. Kaya ipinapayong maglaan ng mas maraming memorya.
• Kapansin-pansin ang pagkakaiba sa laki ng patak.

Backuper
Laki

Borg
mga 500MB

Nagpahinga
mga 5MB

• Ang karanasan ni Restic sa S3 ay mahusay. Ang pakikipagtulungan sa Borg sa pamamagitan ng goofys ay hindi nagtataas ng anumang mga katanungan, ngunit ito ay nabanggit na ito ay ipinapayong gawin umount pagkatapos makumpleto ang backup upang ganap na i-reset ang cache. Ang kakaiba ng S3 ay hindi na ipapadala sa bucket ang mga under-pumped chunks, na nangangahulugang ang hindi kumpletong napunan na data ay humahantong sa malaking pinsala.
• Ang integrity check ay gumagana nang maayos sa parehong mga kaso, ngunit ang bilis ay naiiba nang malaki.
  Nagpahinga 3,5 oras.
  Borg, na may 100GB SSD file cache – 5 oras.Humigit-kumulang sa parehong bilis ng resulta kung ang data ay nasa isang lokal na disk.
  Direktang nagbabasa si Borg mula sa S3 nang walang cache 33 oras. Isang napakahabang panahon.

Ang bottom line ay ang Borg ay maaaring mag-compress at may mas malalaking blobs - na ginagawang mas mura ang storage at GET/PUT operations sa S3. Ngunit ito ay dumating sa halaga ng mas kumplikado at mas mabagal na pag-verify. Tulad ng para sa bilis ng pagbawi, wala kaming napansin na pagkakaiba. Ang Restic ay tumatagal ng kasunod na pag-backup (pagkatapos ng una) nang kaunti pa, ngunit hindi gaanong mahalaga.

Ang huli ngunit hindi bababa sa napili ay ang laki ng komunidad.

At pinili namin si borg.

Ang ilang mga salita tungkol sa compression

Ang Borg ay may mahusay na bagong compression algorithm sa arsenal nito - zstd. Ang kalidad ng compression ay hindi mas masama kaysa sa gzip, ngunit mas mabilis. At maihahambing sa bilis sa default na lz4.

Halimbawa, ang MySQL database dump ay na-compress ng dalawang beses na mas mahusay kaysa sa lz4 sa parehong bilis. Gayunpaman, ang karanasan sa totoong data ay nagpapakita na mayroong napakaliit na pagkakaiba sa compression ratio ng Nextcloud node.

Ang Borg ay may isang halip na bonus compression mode - kung ang file ay may mataas na entropy, kung gayon ang compression ay hindi inilapat sa lahat, na nagpapataas ng bilis. Pinagana ng opsyon kapag gumagawa
-C auto,zstd
para sa zstd algorithm
Kaya sa pagpipiliang ito, kung ihahambing sa default na compression, nakuha namin
560Gb at 562Gb ayon sa pagkakabanggit. Ang data mula sa halimbawa sa itaas, hayaan mo akong ipaalala sa iyo, nang walang compression ang resulta ay 628Gb. Ang resulta ng 2GB na pagkakaiba ay medyo nagulat sa amin, ngunit naisip namin na pipiliin namin ito pagkatapos ng lahat. auto,zstd.

Paraan ng pag-verify ng backup

Ayon sa scheduler, ang virtual machine ay direktang inilunsad mula sa provider o mula sa kliyente, na lubos na binabawasan ang network load. Hindi bababa sa ito ay mas mura kaysa sa pagtataas nito sa iyong sarili at pagmamaneho ng trapiko.

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

Gamit ang parehong pamamaraan, sinusuri namin ang mga file gamit ang isang antivirus (pagkatapos ng katotohanan). Pagkatapos ng lahat, ang mga gumagamit ay nag-a-upload ng iba't ibang mga bagay sa Nextcloud at hindi lahat ay may antivirus. Ang pagsasagawa ng mga inspeksyon sa oras ng pagbuhos ay tumatagal ng masyadong maraming oras at nakakasagabal sa negosyo.

Ang scalability ay nakakamit sa pamamagitan ng pagpapatakbo ng mga runner sa iba't ibang mga node na may iba't ibang mga tag.
Ang aming pagsubaybay ay nangongolekta ng mga backup na katayuan sa pamamagitan ng GitLab API sa isang window; kung kinakailangan, ang mga problema ay madaling mapansin at madaling ma-localize.

Konklusyon

Bilang resulta, alam naming sigurado na gumagawa kami ng mga backup, na ang aming mga backup ay wasto, ang mga problema na lumitaw sa kanila ay tumatagal ng kaunting oras at nalutas sa antas ng tagapangasiwa ng tungkulin. Ang mga pag-backup ay talagang maliit na espasyo kumpara sa tar.gz o Bacula.

Pinagmulan: www.habr.com