Cumu GitLab vi aiuta à fà una copia di salvezza di grandi magazzini NextCloud

Ehi Habr!

Oghje vogliu parlà di a nostra sperienza in l'automatizazione di a copia di salvezza di big data da i magazzini Nextcloud in diverse cunfigurazioni. U travagliu cum'è stazione di serviziu in Molniya AK, induve facemu a gestione di cunfigurazione di i sistemi IT; Nextcloud hè adupratu per u almacenamentu di dati. Includendu, cù una struttura distribuita, cù redundancy.

I prublemi chì nascenu da e caratteristiche di l'installazione sò chì ci sò assai dati. Versioning furnita da Nextcloud, redundancy, motivi subjectivi, è più crea parechji duplicati.

Pristoria

Quandu amministra Nextcloud, u prublema di urganizà una copia di salvezza efficace, chì deve esse criptata, postu chì i dati sò preziosi.

Offriamu opzioni per almacenà e copie di salvezza in u nostru locu o à u cliente nantu à e macchine separate da Nextcloud, chì richiede un approcciu automatizatu flexible à l'amministrazione.

Ci sò parechji clienti, tutti cù cunfigurazioni diffirenti, è tutti nantu à i so siti è cù e so caratteristiche. Questa hè una tecnica standard quandu u situ sanu appartene à voi, è e copie di salvezza sò fatta da corone; ùn hè micca bè.

Prima, fighjemu i dati di input. Avemu bisognu:

• Scalabilità in termini di un node o parechji. Per grandi installazioni usemu minio cum'è almacenamiento.
• Scuprite i prublemi cù a realizazione di copia di salvezza.
• Avete bisognu di mantene una copia di salvezza cù i vostri clienti è / o cun noi.
• Tratta i prublemi rapidamente è facilmente.
• Clienti è installazioni sò assai diffirenti l'una di l'altru - l'uniformità ùn pò micca esse ottenuta.
• A velocità di ricuperazione deve esse minima in dui scenarii: ricuperazione completa (disastru), un cartulare sguassatu per sbagliu.
• A funzione di deduplicazione hè necessaria.

Per risolve u prublema di gestisce e backups, avemu installatu GitLab. Più dettagli per l'attaccu.

Di sicuru, ùn simu micca i primi à risolve un tali prublema, ma ci pari chì a nostra sperienza pratica, duramente guadagnata pò esse interessante è simu pronti à sparte.

Siccomu a nostra cumpagnia hà una pulitica open source, avemu cercatu una suluzione open source. In turnu, spartemu i nostri sviluppi è li publichi. Per esempiu, in GitHub ci hè u nostru plugin per Nextcloud, chì furnimu à i clienti, rinfurzendu a sicurità di dati in casu di eliminazione accidentale o intenzionale.

Strumenti di salvezza

Avemu principiatu a nostra ricerca di metudi di suluzione scegliendu un strumentu di creazione di salvezza.

Tar + gzip regulare ùn funziona micca bè - i dati sò duplicati. Un incrementu spessu cuntene assai pochi cambiamenti attuali, è assai di e dati in un unicu schedariu sò ripetuti.
Ci hè un altru prublema - redundancy di almacenamiento di dati distribuitu. Avemu aduprà minio è i so dati sò basicamente redundant. O avete avutu à fà una copia di salvezza attraversu u minio stessu - caricate è aduprà tutti i spazii trà u sistema di schedari, è, micca menu impurtante, ci hè u risicu di scurdà di certi buckets è meta-informazioni. O utilizate a deduplicazione.

Strumenti di salvezza cù duplicazione sò dispunibili in open source (su Habré ci era articuli circa stu tema) è i nostri finalisti eranu Borg и Restu. U nostru paragone di e duie applicazioni hè quì sottu, ma per avà vi diceremu cumu avemu urganizatu tuttu u schema.

Gestisce i backups

Borg è Restic sò boni, ma nè u pruduttu hà un mecanismu di cuntrollu centralizatu. Per u scopu di gestione è cuntrollu, avemu sceltu un strumentu chì avemu digià implementatu, senza chì ùn pudemu micca imagine u nostru travagliu, cumpresa l'automatizazione - questu hè u CI / CD ben cunnisciutu - GitLab.

L'idea hè a siguenti: gitlab-runner hè stallatu nantu à ogni node chì almacena dati Nextcloud. U corridore esegue un script in un schedariu chì monitorizza u prucessu di salvezza, è lancia Borg o Restic.

Chì avemu avutu ? Feedback da l'esekzione, cuntrolu còmode di i cambiamenti, dettagli in casu d'errore.

quì quì nantu à GitHub avemu publicatu esempi di u script per diverse attività, è avemu finitu per attaccà à a copia di salvezza micca solu Nextcloud, ma ancu assai altri servizii. Ci hè ancu un pianificatore quì si ùn vulete micca cunfigurà manualmente (è ùn vulemu micca) è .gitlab-ci.yml

Ùn ci hè ancu manera di cambià u CI / CD timeout in l'API Gitlab, ma hè chjucu. Ci vole à esse aumentatu, dì à 1d.

GitLab, per furtuna, pò lancià micca solu secondu un impegnu, ma solu secondu un calendariu, questu hè esattamente ciò chì avemu bisognu.

Avà nantu à u script wrapper.

Avemu stabilitu e seguenti cundizioni per questu script:

• Si deve esse lanciatu da u corridore è da a manu da a cunsola cù a listessa funziunalità.
• Ci deve esse un gestore di errore:
• codice di ritornu.
• cercate una stringa in u logu. Per esempiu, per noi un errore pò esse un missaghju chì u prugramma ùn cunsiderà micca fatale.
• Timeout di prucessu. U tempu di prucedura deve esse ragiunate.
• Avemu bisognu di un logu assai detallatu. Ma solu in casu di errore.
• Una quantità di teste sò ancu realizati prima di inizià.
• Picculi bonus per comodità chì avemu trovu utile durante u prucessu di supportu:
• U principiu è a fine sò registrati in u syslog di a macchina lucale. Questu aiuta à cunnette l'errori di u sistema è l'operazione di salvezza.
• A parte di u logu d'errore, s'ellu ci hè, hè uscita in stdout, u logu tutale hè scrittu in un schedariu separatu. Hè cunvenutu per guardà immediatamente CI è evaluà l'errore s'ellu hè triviale.
• Modi di debugging.

U logu sanu hè salvatu cum'è un artefattu in GitLab; se ùn ci hè micca errore, u logu hè sguassatu. Scrivemu u script in bash.

Saremu felici di cunsiderà qualsiasi suggerimenti è cumenti riguardanti open source - benvenuti.

Cumu serà ch'ella ùn stu travagliu

Un corridore cù un esecutore Bash hè lanciatu nantu à u node di salvezza. Sicondu u pianificatore, u travagliu CI / CD hè lanciatu in un turnip speciale. U corridore lancia un script wrapper universale per tali compiti, verifica a validità di u repositoriu di salvezza, i punti di muntagna è tuttu ciò chì vulemu, poi fa una copia di salvezza è pulisce u vechju. A copia di salvezza finita stessu hè mandata à S3.

Travagliemu secondu questu schema - hè un fornitore AWS esternu o un equivalente russu (hè più veloce è i dati ùn lascianu micca a Federazione Russa). O installemu un cluster minio separatu per u cliente in u so situ per questi scopi. Di solitu facemu questu per ragioni di sicurità, quandu u cliente ùn vole micca chì i dati lascianu u so circuitu.

Ùn avemu micca usatu a funzione di mandà una copia di salvezza via ssh. Questu ùn aghjunghje micca a sicurità, è e capacità di rete di u fornitore S3 sò assai più altu ch'è a nostra una macchina ssh.

In ordine per prutege a vostra macchina lucale da un pirate, postu ch'ellu pò sguassà dati in S3, vi tocca à attivà versioning.
A copia di salvezza sempre cripta a copia di salvezza.

Borg hà un modu micca criptatu none, ma ùn ricumandemu fermamente di accendelu. In questu modu, ùn solu ùn ci sarà micca criptografia, ma u checksum di ciò chì hè scrittu ùn hè micca calculatu, chì significa chì l'integrità pò esse verificata solu indirettu, usendu indici.

Un pianificatore separatu verifica e copie di salvezza per l'integrità di l'indici è u cuntenutu. U cuntrollu hè lentu è longu, cusì u corremu separatamente una volta à u mese. Si pò piglià parechji ghjorni.

Readme in Russian

Funzioni principali

• prepare preparazione
• testcheck verificazione di prontezza
• maincommand squadra core
• forcepostscript una funzione chì hè eseguita à a fine o per errore. Avemu aduprà per unmount the partition.

Funzioni di serviziu

• cleanup Scrivemu errori o sguassate u schedariu di log.
• checklog analizà u logu per l'occurrence di una linea cù un errore.
• ret gestore di uscita.
• checktimeout verificate u timeout.

Environment

• VERBOSE=1 Mostramu l'errori nantu à u screnu immediatamente (stdout).
• SAVELOGSONSUCCES=1 salvà u logu dopu successu.
• INIT_REPO_IF_NOT_EXIST=1 Crea un repository s'ellu ùn esiste micca. Disabilitatu per difettu.
• TIMEOUT tempu massimu per l'operazione principale. Pudete stabilisce cum'è "m", "h" o "d" à a fine.

Modu di almacenamiento per i vechji copie. Default:

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

Variabili in u script

• ERROR_STRING - stringa per u logu di check in per errore.
• EXTRACT_ERROR_STRING - espressione per mostra a stringa se errore.
• KILL_TIMEOUT_SIGNAL - signale per tumbà se timeout.
• TAIL - quante stringhe cù errori nantu à u screnu.
• COLORMSG - culore di u messagiu (giallu predeterminatu).

Ddu script, chì hè chjamatu wordpress, hà un nome cundizionale, u so truccu hè chì ancu sustene a basa di dati mysql. Questu significa chì pò esse usatu per installazioni Nexcloud à un node, induve pudete ancu fà una copia di salvezza di a basa di dati. A cunvenzione ùn hè micca solu chì tuttu hè in un locu, ma ancu u cuntenutu di a basa di dati sò vicinu à u cuntenutu di i schedari, postu chì a diferenza di tempu hè minima.

Restic vs Borg

Ci sò ancu paraguni trà Borg è Restic quì nantu à Habré, è ùn avemu micca u compitu di fà solu un altru, ma u nostru. Era impurtante per noi cumu si vede nantu à i nostri dati, cù i nostri specifichi. I purtemu.

I nostri criteri di selezzione, in più di quelli digià citati (deduplicazione, ricuperazione rapida, etc.):

• Resistenza à u travagliu unfinished. Verificate per tumbà -9.
• Dimensione nantu à u discu.
• Esigenza di risorse (CPU, memoria).
• Dimensione di i blobs almacenati.
• U travagliu cù S3.
• Verificazione di l'integrità.

Per pruvà, avemu pigliatu un cliente cù dati reali è una dimensione tutale di 1,6 TB.
Cundizioni

Borg ùn sapi micca cumu travaglià direttamente cù S3, è avemu muntatu u discu cum'è un fusible, via scemi. Restic hà mandatu à S3 stessu.

Goofys travaglia assai rapidamente è bè, è ci sò modulu di cache di discu, chì accelera u travagliu ancu di più. Hè in u stadiu beta, è, francamente, avemu crashed cù a perdita di dati durante i testi (altri). Ma a cunvenzione hè chì a prucedura di salvezza stessu ùn hà micca bisognu di assai lettura, ma soprattuttu scrittura, cusì usemu a cache solu durante i cuntrolli di integrità.

Per riduce l'influenza di a reta, avemu usatu un fornitore locale - Yandex Cloud.

I risultati di teste di paragone.

• Kill -9 cun un novu riavviu sò stati tramindui successu.
• Dimensione nantu à u discu. Borg pò cumpressà, cusì i risultati sò cum'è previstu.

Backuper
grannizza

Borg
562Gb

Restu
628Gb

• Per CPU
  Borg stessu cunsuma pocu, cù cumpressione predeterminata, ma deve esse evaluatu inseme cù u prucessu goofys. In totale, sò paragunabili è utilizanu circa 1,2 cores nantu à a stessa macchina virtuale di prova.
• Memoria. Restic hè di circa 0,5 GB, Borg hè di circa 200 MB. Ma questu hè tuttu insignificante cumparatu cù u cache di u schedariu di u sistema. Dunque, hè cunsigliu per assignà più memoria.
• A sfarenza in a dimensione di u blob era sorprendente.

Backuper
grannizza

Borg
circa 500 MB

Restu
circa 5 MB

• L'esperienza cù Restic's S3 hè eccellente. U travagliu cù Borg à traversu goofys ùn susciteghja ogni quistione, ma hè statu nutatu chì hè cunsigliatu di fà umount dopu chì a copia di salvezza hè cumpleta per resettate cumplettamente a cache. A peculiarità di S3 hè chì i chunks under-pumped ùn saranu mai mandati à u bucket, chì significa chì i dati incompletamente cumpleti portanu à danni maiò.
• A verificazione di l'integrità funziona bè in i dui casi, ma a velocità differisce significativamente.
  Restu Iornu 3,5.
  Borg, cù una cache di file SSD di 100 GB - Iornu 5.Aproximatamente u listessu risultatu vitezza si i dati sò nantu à un discu lucale.
  Borg leghje direttamente da S3 senza cache Iornu 33. Mostruosamente longu.

U fondu hè chì Borg pò cumpressà è hà blobs più grande - chì rende l'almacenamiento è l'operazioni GET/PUT in S3 più prezzu. Ma questu vene à u costu di verificazione più cumplessa è più lenta. In quantu à a veloce di ricuperazione, ùn avemu micca nutatu nisuna differenza. Restic piglia backups successivi (dopu à u primu) un pocu più longu, ma micca significativamente.

L'ultimu ma micca menu menu in a scelta era a dimensione di a cumunità.

È avemu sceltu borg.

Uni pochi parolle nantu à a compressione

Borg hà un novu algoritmu di compressione eccellente in u so arsenale - zstd. A qualità di cumpressione ùn hè micca peghju chè gzip, ma assai più veloce. È paragunabile in velocità à u default lz4.

Per esempiu, un dump di basa di dati MySQL hè cumpressu duie volte megliu cà lz4 à a stessa velocità. In ogni casu, l'experientia cù dati veri mostra chì ci hè assai poca differenza in u rapportu di compressione di u node Nextcloud.

Borg hà un modu di cumpressione piuttostu bonus - se u schedariu hà una alta entropia, a cumpressione ùn hè micca appiicata à tutti, chì aumenta a velocità. Abilitatu da l'opzione quandu crea
-C auto,zstd
per l'algoritmu zstd
Allora cù questa opzione, in paragone cù a compressione predeterminata, avemu avutu
560 Gb è 562 Gb rispettivamente. I dati da l'esempiu sopra, lasciami ricurdà, senza cumpressione u risultatu hè 628Gb. U risultatu di una diferenza di 2GB ci hà sorpresu un pocu, ma avemu pensatu chì l'avemu sceltu dopu tuttu. auto,zstd.

Metudu di verificazione di salvezza

Sicondu u pianificatore, a macchina virtuale hè lanciata direttamente da u fornitore o da u cliente, chì reduce assai a carica di a rete. Almenu hè più prezzu di alzà ellu stessu è guidà u trafficu.

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/

Utilizendu u listessu schema, cuntrollemu i schedari cù un antivirus (dopu à u fattu). Dopu tuttu, l'utilizatori caricanu diverse cose à Nextcloud è micca tutti anu un antivirus. A realizazione di l'ispezioni à u mumentu di versà pigghia troppu tempu è interferiscenu cù l'affari.

A scalabilità hè ottenuta da l'esecuzione di i corridori in diversi nodi cù diverse tag.
U nostru monitoraghju raccoglie stati di salvezza via l'API GitLab in una finestra; se ne necessariu, i prublemi sò facilmente nutati è facilmente localizzati.

cunchiusioni

In u risultatu, sapemu sicuru chì facemu backups, chì i nostri backups sò validi, i prublemi chì si sviluppanu cun elli piglianu pocu tempu è sò risolti à u livellu di l'amministratore di u duvere. Backups occupanu veramente pocu spaziu cumparatu cù tar.gz o Bacula.

Source: www.habr.com