Kumaha GitLab ngabantosan anjeun nyadangkeun panyimpenan NextCloud anu ageung

Héy Habr!

Dinten ieu abdi hoyong ngobrol ngeunaan pangalaman urang di automating cadangan data badag ti storages Nextcloud dina konfigurasi béda. Abdi damel salaku stasiun jasa di Molniya AK, dimana urang ngalakukeun manajemén konfigurasi sistem IT; Nextcloud dianggo pikeun neundeun data. Kaasup, kalawan struktur disebarkeun, kalawan redundancy.

Masalah anu timbul tina fitur pamasangan nyaéta seueur data. Versi anu disayogikeun ku Nextcloud, redundansi, alesan subjektif, sareng seueur deui nyiptakeun seueur duplikat.

prasajarah

Nalika ngokolakeun Nextcloud, masalah pikeun ngatur cadangan anu épéktip, anu kedah énkripsi, sabab datana berharga.

Kami nawiskeun pilihan pikeun nyimpen cadangan di tempat kami atanapi di palanggan dina mesin anu misah ti Nextcloud, anu peryogi pendekatan otomatis anu fleksibel pikeun administrasi.

Aya seueur klien, sadayana kalayan konfigurasi anu béda-béda, sareng sadayana dina situs sorangan sareng cirina sorangan. Ieu mangrupikeun téknik standar nalika sadaya situs milik anjeun, sareng cadangan didamel tina makuta; éta henteu pas.

Kahiji, hayu urang nempo data input. Urang butuh:

• Skalabilitas dina watesan hiji titik atanapi sababaraha. Pikeun pamasangan ageung kami nganggo minio salaku panyimpen.
• Panggihan ngeunaan masalah sareng ngalakukeun cadangan.
• Anjeun kedah nyimpen cadangan sareng klien anjeun sareng / atanapi sareng kami.
• Nungkulan masalah gancang sarta gampang.
• Klién sareng pamasangan béda-béda pisan - kaseragaman teu tiasa dihontal.
• Laju pamulihan kedah minimal dina dua skenario: pamulihan pinuh (musibah), hiji folder dihapus ku kasalahan.
• fungsi deduplication diperlukeun.

Pikeun ngajawab masalah ngatur cadangan, kami dipasang GitLab. Langkung rinci ku tackle.

Tangtosna, urang sanés anu munggaran pikeun ngabéréskeun masalah sapertos kitu, tapi sigana urang yén pangalaman praktis, susah-payah urang tiasa pikaresepeun sareng kami siap ngabagikeunana.

Kusabab perusahaan kami gaduh kawijakan open source, kami milarian solusi open source. Sabalikna, urang bagikeun kamajuan urang sareng pasangkeunana. Contona, dina GitHub aya plugin kami pikeun Nextcloud, anu kami nyayogikeun ka klien, ningkatkeun kaamanan data upami ngahapus teu kahaja atanapi ngahaja.

Alat cadangan

Urang ngamimitian milarian metode solusi ku milih alat nyiptakeun cadangan.

Tar biasa + gzip henteu jalan saé - datana duplikat. Naékna sering ngandung saeutik pisan parobahan sabenerna, sarta loba data dina file tunggal diulang.
Aya masalah sejen - redundancy gudang data disebarkeun. Kami nganggo minio sareng datana dasarna kaleuleuwihan. Atawa anjeun kudu nyieun cadangan ngaliwatan minio sorangan - beban eta sarta ngagunakeun sagala spacers antara sistem file, sarta, teu kurang pentingna, aya résiko poho ngeunaan sababaraha ember na meta-informasi. Atawa ngagunakeun deduplikasi.

Alat cadangan sareng duplikasi sayogi dina open source (dina Habré aya tulisan ngeunaan téma ieu) jeung finalis urang éta Borg и Réstik. Perbandingan kami tina dua aplikasi ieu di handap, tapi ayeuna kami bakal nyarioskeun ka anjeun kumaha urang ngatur sadayana skéma.

Ngatur cadangan

Borg na Restic anu alus, tapi teu produk boga mékanisme kontrol terpusat. Pikeun tujuan manajemén sareng kontrol, kami milih alat anu parantos kami laksanakeun, tanpa éta kami henteu tiasa ngabayangkeun padamelan urang, kalebet automation - ieu mangrupikeun CI / CD anu terkenal - GitLab.

Gagasanna nyaéta kieu: gitlab-runner dipasang dina unggal titik anu nyimpen data Nextcloud. runner ngajalankeun hiji naskah dina jadwal nu ngawas prosés cadangan, sarta eta ngajalankeun Borg atanapi Restic.

Naon anu urang meunang? Eupan balik ti palaksanaan, kontrol merenah leuwih parobahan, rinci bisi aya kasalahan.

di dieu didieu on GitHub kami dipasang conto naskah pikeun sagala rupa tugas, sarta kami réngsé nepi ngalampirkeun kana cadangan teu ukur Nextcloud, tapi ogé loba jasa lianna. Aya ogé scheduler a aya lamun teu hayang ngonpigurasikeun sacara manual (jeung urang teu hayang) jeung .gitlab-ci.yml

Teu aya deui jalan pikeun ngarobih waktos waktos CI / CD dina API Gitlab, tapi éta alit. Perlu ditingkatkeun, sebutkeun ka 1d.

GitLab, untungna, tiasa ngaluncurkeun henteu ngan ukur dumasar kana komitmen, tapi ngan ukur dumasar kana jadwal, ieu mangrupikeun anu urang peryogikeun.

Ayeuna ngeunaan naskah wrapper.

Kami netepkeun kaayaan di handap pikeun naskah ieu:

• Éta kedah diluncurkeun ku runner sareng ku panangan tina konsol anu gaduh fungsi anu sami.
• Kedah aya panangan kasalahan:
• kode balik.
• milarian string dina log. Contona, pikeun urang kasalahan bisa jadi pesen yén program teu nganggap fatal.
• Ngolah waktosna. Waktos kalungguhan kedah wajar.
• Urang peryogi log anu lengkep pisan. Tapi ngan bisi aya kasalahan.
• Sajumlah tés ogé dilaksanakeun sateuacan ngamimitian.
• Bonus leutik pikeun genah anu kami mendakan mangpaat nalika prosés ngadukung:
• Mimiti sareng akhir kacatet dina syslog mesin lokal. Ieu ngabantuan pikeun nyambungkeun kasalahan sistem sareng operasi cadangan.
• Bagian tina log kasalahan, upami aya, kaluaran pikeun stdout, sadayana log ditulis kana file anu misah. Éta merenah pikeun geuwat nempo CI jeung evaluate kasalahan lamun éta trivial.
• Modeu debugging.

Log lengkep disimpen salaku artefak di GitLab; upami teu aya kasalahan, logna dihapus. Urang nulis naskah dina bash.

Kami bakal resep nimbangkeun saran sareng koméntar ngeunaan open source - wilujeng sumping.

Kumaha teu karya ieu

A runner sareng pelaksana Bash diluncurkeun dina titik cadangan. Numutkeun scheduler nu, pakasaban CI / CD dibuka dina turnip husus. Runner ngaluncurkeun skrip wrapper universal pikeun tugas-tugas sapertos kitu, éta pariksa validitas gudang cadangan, pasang titik sareng sadayana anu urang pikahoyong, teras nyadangkeun sareng ngabersihkeun anu lami. Cadangan rengse sorangan dikirim ka S3.

Kami damel dumasar kana skéma ieu - éta mangrupikeun panyadia AWS éksternal atanapi sarimbag Rusia (langkung gancang sareng datana henteu ngantunkeun Féderasi Rusia). Atanapi urang pasang klaster minio anu misah pikeun klien dina situsna pikeun tujuan ieu. Urang biasana ngalakukeun ieu alesan kaamanan, nalika klien nu teu hayang data ninggalkeun sirkuit maranéhanana pisan.

Kami henteu nganggo fitur ngirim cadangan via ssh. Ieu henteu nambihan kaamanan, sareng kamampuan jaringan panyadia S3 langkung luhur tibatan hiji mesin ssh urang.

Dina raraga ngajaga mesin lokal anjeun ti hacker a, saprak anjeunna tiasa mupus data dina S3, anjeun kudu ngaktipkeun versioning.
Cadangan sok énkripsi cadangan.

Borg boga mode unencrypted none, tapi kami henteu nyarankeun pisan pikeun ngaktipkeunana. Dina modeu ieu, teu ngan bakal aya euweuh enkripsi, tapi checksum tina naon keur ditulis teu diitung, nu hartina integritas ngan bisa dipariksa teu langsung, ngagunakeun indéks.

A scheduler misah mariksa cadangan pikeun integritas indéks jeung eusi. cék téh slow sarta panjang, jadi urang ngajalankeun eta misah sabulan sakali. Butuh waktu sababaraha poé.

Readme dina basa Rusia

Fungsi utama

• prepare palatihan
• testcheck cek kasiapan
• maincommand tim inti
• forcepostscript fungsi anu dieksekusi dina tungtungna atawa ku kasalahan. Kami nganggo éta pikeun ngahapus partisi.

fungsi palayanan

• cleanup Urang ngarekam kasalahan atawa mupus file log.
• checklog parse log pikeun lumangsungna garis kalawan kasalahan.
• ret kaluar panangan.
• checktimeout pariksa keur timeout.

lingkungan

• VERBOSE=1 Urang nembongkeun kasalahan dina layar geuwat (stdout).
• SAVELOGSONSUCCES=1 simpen log kana kasuksésan.
• INIT_REPO_IF_NOT_EXIST=1 Jieun gudang lamun teu aya. Ditumpurkeun sacara standar.
• TIMEOUT waktos maksimum pikeun operasi utama. Anjeun tiasa nyetél éta salaku 'm', 'h' atanapi 'd' dina tungtungna.

Modeu gudang pikeun salinan heubeul. standar:

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

Variabel jero naskah

• ERROR_STRING - string pikeun log dipariksa pikeun kasalahan.
• EXTRACT_ERROR_STRING - ekspresi pikeun nembongkeun string lamun kasalahan.
• KILL_TIMEOUT_SIGNAL - sinyal pikeun maéhan lamun timeout.
• TAIL - sabaraha string kalawan kasalahan dina layar.
• COLORMSG - warna pesen (konéng standar).

Éta naskah, anu disebut wordpress, ngagaduhan nami kondisional, trikna nyaéta yén éta ogé nyadangkeun database mysql. Ieu hartosna tiasa dianggo pikeun pamasangan Nexcloud-titik tunggal, dimana anjeun ogé tiasa nyadangkeun pangkalan data. Genahna henteu ngan ukur sadayana aya dina hiji tempat, tapi ogé eusi pangkalan data caket kana eusi file, sabab bédana waktosna minimal.

Restic vs Borg

Aya ogé babandingan antara Borg na Restic dieu on Habré, sarta kami teu boga tugas nyieun ngan hiji sejen, tapi urang sorangan. Penting pikeun urang kumaha éta bakal katingali dina data urang, kalayan spésifik urang. Kami bawa aranjeunna.

Kriteria pilihan kami, salian ti anu parantos disebatkeun (deduplikasi, pamulihan gancang, jsb.):

• Résistansi kana padamelan anu teu acan réngsé. Pariksa pikeun maéhan -9.
• Ukuran dina disk.
• Sarat pikeun sumberdaya (CPU, mémori).
• Ukuran blobs disimpen.
• Gawe sareng S3.
• Cék integritas.

Pikeun nguji, kami nyandak hiji klien kalayan data nyata sareng ukuran total 1,6 TB.
Kaayaan.

Borg teu nyaho kumaha carana dianggo langsung kalayan S3, sarta kami dipasang disk salaku sekering a, via goofys. Restic dikirim ka S3 sorangan.

Goofys jalan pisan gancang sarta ogé, tur aya modul cache disk, nu speeds up karya malah leuwih. Ieu dina tahap béta, sarta, terus terang, urang nabrak jeung leungitna data salila tés (batur). Tapi genah teh nya eta prosedur cadangan sorangan teu merlukeun loba bacaan, tapi lolobana nulis, jadi kami nganggo cache ngan salila cék integritas.

Pikeun ngirangan pangaruh jaringan, kami nganggo panyadia lokal - Yandex Cloud.

Hasil tés ngabandingkeun.

• Maéhan -9 kalawan balikan deui salajengna éta duanana suksés.
• Ukuran dina disk. Borg tiasa ngompres, janten hasilna sapertos anu diharapkeun.

Cadangan
ukuran

Borg
562GB

Réstik
628GB

• Ku CPU
  Borg sorangan meakeun saeutik, kalawan komprési standar, tapi kudu dievaluasi babarengan jeung prosés goofys. Dina total, aranjeunna comparable sarta ngagunakeun ngeunaan 1,2 cores dina mesin virtual test sarua.
• Mémori. Restic kirang langkung 0,5GB, Borg kirang langkung 200MB. Tapi ieu sadayana teu pati penting dibandingkeun sareng cache file sistem. Ku kituna éta sasaena pikeun allocate leuwih memori.
• Beda dina ukuran gumpalan éta ngahalangan.

Cadangan
ukuran

Borg
ngeunaan 500MB

Réstik
ngeunaan 5MB

• Pangalaman sareng Restic's S3 saé pisan. Gawe sareng Borg ngaliwatan goofys teu ngangkat patarosan wae, tapi geus dicatet yén éta sasaena ngalakukeun umount sanggeus cadangan geus réngsé pikeun sakabéhna ngareset cache. The peculiarity of S3 nyaeta sakumpulan handapeun-ngompa moal pernah dikirim ka LIPI, nu hartina data incompletely dieusian ngabalukarkeun karuksakan utama.
• Pamariksaan integritas tiasa dianggo saé dina dua kasus, tapi lajuna béda sacara signifikan.
  Restic jam 3,5.
  Borg, kalayan cache file SSD 100GB - jam 5.Kira-kira hasil speed sarua lamun data dina disk lokal.
  Borg maca langsung ti S3 tanpa cache jam 33. Panjang pisan.

Garis handap nyaéta yén Borg tiasa niiskeun sareng gaduh gumpalan anu langkung ageung - anu ngajantenkeun neundeun sareng GET / PUT operasi di S3 langkung mirah. Tapi ieu asalna tina biaya verifikasi anu langkung rumit sareng laun. Sedengkeun pikeun speed recovery, urang teu aya bewara bédana nanaon. Restic nyandak cadangan salajengna (sanggeus anu kahiji) sakedik deui, tapi henteu sacara signifikan.

Panungtungan tapi teu saeutik dina pilihan éta ukuran masarakat.

Sarta kami milih borg.

Sababaraha kecap ngeunaan komprési

Borg boga algoritma komprési anyar alus teuing di arsenal na - zstd. Kualitas komprési henteu langkung goreng tibatan gzip, tapi langkung gancang. Sarta comparable dina speed ka standar lz4.

Contona, hiji dump database MySQL dikomprés dua kali leuwih hade tinimbang lz4 dina speed sarua. Nanging, pangalaman sareng data nyata nunjukkeun yén aya sakedik bédana dina rasio komprési titik Nextcloud.

Borg gaduh mode komprési anu rada bonus - upami filena ngagaduhan éntropi anu luhur, maka komprési henteu diterapkeun pisan, anu ningkatkeun kagancangan. Diaktipkeun ku pilihan nalika nyieun
-C auto,zstd
pikeun algoritma zstd
Janten sareng pilihan ieu, dibandingkeun sareng komprési standar, kami ngagaduhan
560Gb sareng 562Gb masing-masing. Data tina conto di luhur, hayu atuh ngingetkeun anjeun, tanpa komprési hasilna nyaeta 628Gb. Hasil tina bédana 2GB rada kaget kami, tapi urang ngira yén urang bakal milih eta sanggeus kabeh. auto,zstd.

Métode verifikasi cadangan

Numutkeun jadwal, mesin virtual diluncurkeun langsung ti panyadia atanapi ti klien, anu ngirangan beban jaringan. Sahenteuna éta langkung mirah ti ngangkat éta sorangan sareng nyetir lalu lintas.

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/

Nganggo skéma anu sami, urang pariksa file nganggo antipirus (sanggeus kanyataan). Barina ogé, pangguna unggah sababaraha hal anu béda ka Nextcloud sareng henteu sadayana gaduh antipirus. Ngalaksanakeun pamariksaan dina waktos tuang butuh teuing waktos sareng ngaganggu bisnis.

Skalabilitas kahontal ku ngajalankeun runners dina titik béda jeung tag béda.
Pemantauan kami ngumpulkeun status cadangan liwat API GitLab dina hiji jandela; upami perlu, masalah gampang ditingali sareng gampang dilokalkeun.

kacindekan

Hasilna, urang terang pasti yén urang nyieun cadangan, yén cadangan urang téh sah, masalah anu timbul kalayan aranjeunna nyandak saeutik waktu sarta direngsekeun dina tingkat administrator tugas. Nyadangkeun nyandak sakedik rohangan dibandingkeun tar.gz atanapi Bacula.

sumber: www.habr.com