🥇Come GitLab aiuta a creare backup di grandi archivi NextCloud

Ciao, Habr!

Oggi voglio condividere la nostra esperienza nell'automazione del backup dei grandi dati degli archivi Nextcloud in diverse configurazioni. Lavoro come CTO presso "Molniya AK", dove ci occupiamo della gestione delle configurazioni dei sistemi IT, utilizzando Nextcloud per lo storage dei dati. Inclusi, con una struttura distribuita, con riserva.

I problemi derivano dalle peculiarità delle installazioni, dato che i dati sono numerosi. La versioning fornita da Nextcloud, il backup, motivi soggettivi e altro creano molteplici duplicati.

Antefatti

Quando si amministra Nextcloud sorge acutamente il problema di organizzare un backup efficace che deve essere assolutamente crittografato, poiché i dati sono preziosi.

Offriamo opzioni per memorizzare il backup da noi o dal cliente su macchine separate da Nextcloud, il che richiede un approccio automatizzato e flessibile all'amministrazione.

Ci sono molti clienti, tutti con configurazioni diverse, in piattaforme diverse e con le proprie peculiarità. In questo caso, la metodica standard, dove l'intera piattaforma appartiene a te e i backup sono effettuati da cron, si adatta male.

Per iniziare, diamo un'occhiata ai dati di input. Abbiamo bisogno di:

Scalabilità in termini di una o più nodi. Per installazioni di grandi dimensioni utilizziamo minio come storage.
Rilevare problemi nell'esecuzione del backup.
È necessario conservare il backup presso i clienti e/o presso di noi.
Risolvere rapidamente e facilmente i problemi.
I clienti e le installazioni differiscono significativamente l'uno dall'altro: non riusciamo a raggiungere l'uniformità.
La velocità di ripristino deve essere minima in due scenari: ripristino completo (disastro), una cartella - cancellata per errore.
È obbligatoria la funzione di deduplicazione.

Per affrontare il compito della gestione dei backup, abbiamo integrato GitLab. Maggiori dettagli in seguito.

Senza dubbio, non siamo i primi a risolvere un problema simile, ma ci sembra che la nostra esperienza pratica possa essere interessante e siamo pronti a condividerla.

Poiché nella nostra azienda è adottata una politica open source, abbiamo cercato una soluzione proprio con codice sorgente aperto. D'altra parte, condividiamo le nostre sviluppazioni e le pubblichiamo. Ad esempio, su GitHub c'è il nostro plugin per Nextcloud, che installiamo ai clienti, aumentando la sicurezza dei dati in caso di cancellazione accidentale o intenzionale.

Strumenti di backup

La ricerca di soluzioni è iniziata con la scelta dello strumento per la creazione del backup.

Il normale tar + gzip funziona male: i dati vengono duplicati. L'incremento spesso contiene pochissime modifiche e gran parte dei dati all'interno di un file si ripete.
C'è un altro problema: la ridondanza dello storage distribuito dei dati. Utilizziamo minio e i suoi dati sono in linea di principio ridondanti. O si doveva effettuare il backup tramite lo stesso minio, caricandolo e utilizzando tutte le interfacce tra il filesystem, e cosa non meno importante, c'è il rischio di dimenticare parte dei bucket e delle informazioni meta. Oppure si può utilizzare la deduplicazione.

Esistono strumenti di backup con deduplicazione nell'open source (ne abbiamo parlato su Habr sul CommunityHelpWiki (sullo stesso dominio a questo proposito) e i nostri finalisti sono stati Borg e Restic. Di seguito il nostro confronto tra le due applicazioni, mentre ora vi racconteremo come abbiamo organizzato l'intero schema.

Gestione della creazione di backup

Borg e Restic sono buoni, ma nessuno dei due prodotti ha un meccanismo di gestione centralizzato. Per motivi di gestione e controllo abbiamo scelto uno strumento che abbiamo già implementato, senza il quale non concepiamo il nostro lavoro, compresa l'automazione: è il noto CI/CD – GitLab.

L'idea è la seguente: su ogni nodo che memorizza dati Nextcloud viene installato gitlab-runner. Il runner esegue secondo una pianificazione uno script che monitora il processo di backup, e questo avvia Borg o Restic.

Cosa abbiamo ottenuto? Un feedback dall'esecuzione, un controllo agevole sulle modifiche, dettagli in caso di errore.

Ecco qui su GitHub abbiamo pubblicato esempi di script per diverse attività, e in ultima analisi lo abbiamo collegato al backup non solo di Nextcloud, ma anche di molti altri servizi. Lì si trova anche il pianificatore, se non si ha voglia di configurarlo manualmente (e a noi non piace) e .gitlab-ci.yml

Nell'API di GitLab attualmente non c'è la possibilità di modificare il timeout CI/CD, che è piuttosto breve. Deve essere aumentato, diciamo a 1d.

Fortunatamente, GitLab può essere avviato non solo al momento del commit, ma anche secondo una pianificazione, ed è esattamente ciò che ci serve.

Ora parliamo dello script wrapper.

Abbiamo posto le seguenti condizioni per questo script:

Deve essere avviato sia dal runner che manualmente dalla console con funzionalità identiche.
È assolutamente necessario avere gestori degli errori:
return code.
ricerca di stringhe nei log. Ad esempio, per noi un messaggio che il programma considera non fatale può essere un errore.
Timeout in elaborazione. Il tempo di esecuzione deve essere ragionevole.
Abbiamo bisogno di un log dettagliato. Ma solo in caso di errore.
Viene effettuata anche una serie di test prima dell'inizio.
Piccole comodità che abbiamo trovato utili durante l'assistenza:
L'inizio e la conclusione vengono registrati nel log di sistema della macchina locale. Questo aiuta a collegare gli errori di sistema e il funzionamento del backup.
Una parte del log degli errori, quando presenti, viene mostrata in stdout, l'intero log viene scritto in un file separato. È comodo dare un'occhiata subito in CI e valutare l'errore se è banale.
Modalità per il debug.

Un log completo viene salvato come artefatto in GitLab; se non ci sono errori, il log viene eliminato. Scriviamo lo script in bash.

Siamo lieti di considerare qualsiasi suggerimento o osservazione riguardante l'open source — benvenuti.

Come funziona

Sulla node da eseguire backup viene avviato un runner con un executor bash. Un job CI/CD viene eseguito tramite un pianificatore in un repository speciale. Il runner avvia uno script come wrapper universale per tali compiti, in cui vengono eseguiti controlli di validità del repository di backup, dei punti di montaggio e di tutto ciò che desideriamo, quindi viene eseguita l'operazione di backup e la pulizia del vecchio. Il backup pronto viene inviato a S3.

Lavoriamo secondo questo schema: un provider esterno AWS o un analogo russo (questo è più veloce e i dati non lasciano la RF). In alternativa, installiamo un cluster minio separato presso il cliente per questi scopi. Di solito facciamo così per motivi di sicurezza, quando il cliente non vuole affatto che i dati lascino il loro contesto.

Non abbiamo utilizzato la funzionalità di invio del backup tramite ssh. Questo non aggiunge sicurezza, mentre le capacità di rete del provider S3 sono molto superiori a quelle di una nostra macchina ssh.

Per proteggersi da un hacker sulla macchina locale — poiché può cancellare i dati su S3 — è assolutamente necessario abilitare la versioning.
Il backup viene sempre crittografato.

Borg ha una modalità senza crittografia none, ma non raccomandiamo categoricamente di attivarla. In questa modalità non ci sarà solo crittografia, ma non verrà calcolato nemmeno il checksum di ciò che viene registrato, quindi l'integrità può essere verificata solo indirettamente, tramite indici.

Secondo un pianificatore separato, viene eseguita la verifica dei backup sull'integrità degli indici e del contenuto. La verifica avviene lentamente e a lungo, quindi la avviamo separatamente una volta al mese. Può durare diversi giorni.

Readme in russo

Funzioni principali

preparare preparazione
testcheck verifica della prontezza
maincommand comando principale
forcepostscript funzione eseguita alla fine o in caso di errore. Utilizzata per smontare la partizione.

Funzioni di servizio

ripulire registriamo gli errori o cancelliamo il file di log.
checklog analizziamo il log per la presenza di stringhe di errore.
ret gestore di uscita.
checktimeout verifica del timeout.

Ambiente

VERBOSE=1 mostriamo gli errori immediatamente a schermo (stdout).
SAVELOGSONSUCCES=1 salviamo il log in caso di successo.
INIT_REPO_IF_NOT_EXIST=1 Creiamo il repository se non esiste. Disabilitato di default.
TIMEOUT tempo massimo per l'operazione principale. Puoi impostarlo come ‘m’, ‘h’ o ‘d’ alla fine.

Modalità di conservazione delle copie vecchie. Di default:

KEEP_DAILY=7
KEEP_WEEKLY=4
KEEP_MONTHLY=6

Variabili all'interno dello script

ERROR_STRING — stringa per il controllo nel log per l'errore.
EXTRACT_ERROR_STRING — espressione per mostrare la stringa in caso di errore.
KILL_TIMEOUT_SIGNAL — segnale per terminare in caso di timeout.
TAIL — quante stringhe con errori a schermo.
COLORMSG — colore del messaggio (default giallo).

Lo script chiamato wordpress è così chiamato perché ha anche la funzione di fare backup del database mysql. Pertanto, può essere utilizzato per installazioni monodose di Nexcloud, dove è possibile eseguire anche il backup del database. Il vantaggio non è solo che tutto è in un posto, ma anche che il contenuto del database è vicino a quello dei file, poiché la differenza di tempo è minima.

Restic vs Borg

Le comparazioni tra Borg e Restic sono disponibili anche qui su Habré, e non avevamo l'obiettivo di fare solo un altro, ma il nostro. Ci importava sapere come questo si sarebbe presentato sui nostri dati, con la nostra specificità. Li riportiamo.

I nostri criteri di selezione, oltre a quelli già menzionati (deduplicazione, ripristino rapido, ecc.):

Resistenza a lavori non completati. Verifica di kill -9.
Dimensione su disco.
Richiesta di risorse (CPU, memoria).
Dimensione dei blob conservati.
Lavoro con S3.
Verifica di integrità.

Per il testing abbiamo preso un cliente con dati reali e dimensione totale di 1,6TB.
Condizioni.

Borg non può lavorare direttamente con S3, e lo abbiamo montato come disco fuse, tramite goofys. Restic inviava a S3 direttamente.

Goofys funziona molto velocemente e bene, ed ha anche un modulo di cache su disco, che accelera ulteriormente il lavoro. È attualmente in fase beta e, a dire la verità, ha presentato malfunzionamenti con perdita di dati nei nostri test (altri). Tuttavia, il vantaggio è che l'intera procedura di backup non richiede una grande lettura, ma principalmente scrittura, quindi la cache la utilizziamo solo durante il controllo di integrità.

Per ridurre l'impatto della rete, abbiamo utilizzato un fornitore locale: Yandex Cloud.

Risultati del confronto dei test.

Kill -9 seguito da un riavvio sono andati entrambi a buon fine.
Dimensione su disco. Borg è in grado di comprimere, quindi i risultati sono attesi.

Backuper
Dimensione

Borg
562Gb

Restic
628Gb

Per CPU
Di per sé, borg consuma poco, con compressione predefinita, ma va valutato insieme al processo goofys. In totale sono comparabili e utilizzano circa 1,2 core su una stessa macchina virtuale di test.
Memoria. Restic circa 0,5Gb, Borg circa 200Mb. Ma tutto ciò è insignificante rispetto alla cache dei file di sistema. È quindi consigliabile allocare più memoria.
La differenza nelle dimensioni dei blob è stata notevole.

Backuper
Dimensione

Borg
circa 500Mb

Restic
circa 5Mb

Lavorare con S3 da Restic è eccellente. Lavorare con Borg attraverso goofys non solleva domande, ma è stato notato che è preferibile eseguire umount al termine del backup per azzerare completamente la cache. Una peculiarità dell'operazione S3 è che i chunk non completamente scaricati non saranno mai inviati al bucket, il che significa che dati non completamente caricati portano a gravi corruzioni.
La verifica dell'integrità funziona bene in entrambi i casi, ma la velocità differisce notevolmente.
Restic – 3,5 ore.
Borg, con cache dei file di 100Gb SSD – 5 ore. Un risultato di velocità circa simile se i dati si trovano su un disco locale.
Borg legge direttamente da S3 senza cache 33 ore. Un tempo mostruosamente lungo.

In sintesi, Borg è in grado di comprimere e ha blob più grandi — il che rende più economico lo storage e le operazioni GET/PUT in S3. Ma per questo si deve pagare una verifica più complessa e lenta. Per quanto riguarda la velocità di ripristino — non abbiamo notato differenze. I backup successivi (dopo il primo) restic li fa un po' più lentamente, ma non in modo significativo.

Non da ultimo nella scelta c'era la dimensione della community.

E abbiamo scelto borg.

Due parole sulla compressione

Borg ha a disposizione un ottimo nuovo algoritmo di compressione — zstd. In termini di qualità di compressione non è inferiore a gzip, ma è notevolmente più veloce. È comparabile come velocità con llz4 predefinito.

Ad esempio, un dump di un database MySQL si comprime circa due volte meglio di lz4 alla stessa velocità. Tuttavia, l'esperienza su dati reali mostra una differenza molto piccola nel grado di compressione per i nodi Nextcloud.

In Borg c'è una modalità di compressione piuttosto vantaggiosa — se il file ha un'alta entropia, la compressione non viene applicata affatto, il che aumenta la velocità di esecuzione. È attivata tramite un'opzione al momento della creazione
-C auto,zstd
per l'algoritmo zstd
Ecco, con questa opzione rispetto alla compressione predefinita abbiamo ottenuto
560Gb e 562Gb rispettivamente. I dati dell'esempio precedente, ricordo, senza compressione il risultato è stato di 628Gb. Il risultato con una differenza di 2Gb ci ha sorpreso un po', ma abbiamo deciso che sceglieremo comunque auto,zstd.

Metodologia per il controllo del backup

Il virtual machine viene avviato direttamente dal provider o dal cliente tramite il pianificatore, il che riduce notevolmente il carico di rete. Almeno è più economico che farlo in locale e gestire il traffico.

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\/

Con lo stesso schema controlliamo i file con l'antivirus (post-fatto). Infatti, gli utenti caricano vari contenuti su Nextcloud e non tutti hanno un antivirus. Effettuare il controllo al momento del caricamento richiede troppo tempo e ostacola l'attività.

La scalabilità si ottiene avviando runner su nodi diversi con tag diversi.
Nel nostro monitoraggio raccogliamo gli stati dei backup tramite l'API di GitLab in un'unica finestra; se necessario, i problemi vengono facilmente individuati e altrettanto facilmente localizzati.

Conclusione

Di conseguenza, sappiamo con certezza che stiamo effettuando i backup, che i nostri backup sono validi, e i problemi che si verificano con essi richiedono poco tempo e vengono risolti a livello di amministratore di turno. I backup occupano realmente poco spazio rispetto a tar.gz o Bacula.

Fonte: habr.com