In che modo GitLab ti aiuta a eseguire il backup di grandi archivi NextCloud

Ehi Habr!

Oggi voglio parlare della nostra esperienza nell'automazione del backup di big data dagli archivi Nextcloud in diverse configurazioni. Lavoro come stazione di servizio presso Molniya AK, dove ci occupiamo della gestione della configurazione dei sistemi IT; Nextcloud viene utilizzato per l'archiviazione dei dati. Anche con struttura distribuita, con ridondanza.

I problemi derivanti dalle caratteristiche degli impianti sono che ci sono molti dati. Il controllo delle versioni fornito da Nextcloud, la ridondanza, ragioni soggettive e altro creano molti duplicati.

Sfondo

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

Offriamo opzioni per l'archiviazione dei backup presso la nostra sede o presso quella del cliente su macchine separate da Nextcloud, il che richiede un approccio flessibile e automatizzato all'amministrazione.

Ci sono tanti client, tutti con configurazioni diverse, e tutti con i propri siti e con le proprie caratteristiche. Questa è una tecnica standard quando l’intero sito appartiene a te e i backup sono realizzati con corone; non si adatta bene.

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

• Scalabilità in termini di uno o più nodi. Per installazioni di grandi dimensioni utilizziamo minio come storage.
• Scopri i problemi con l'esecuzione dei backup.
• Devi mantenere un backup con i tuoi clienti e/o con noi.
• Affronta i problemi in modo rapido e semplice.
• Clienti e installazioni sono molto diversi tra loro: non è possibile raggiungere l'uniformità.
• La velocità di ripristino dovrebbe essere minima in due scenari: ripristino completo (disastro), una cartella cancellata per errore.
• È richiesta la funzione di deduplicazione.

Per risolvere il problema della gestione dei backup, abbiamo installato GitLab. Maggiori dettagli per placcaggio.

Certo, non siamo i primi a risolvere un problema del genere, ma ci sembra che la nostra esperienza pratica e faticosa possa essere interessante e siamo pronti a condividerla.

Poiché la nostra azienda ha una politica open source, stavamo cercando una soluzione open source. A nostra volta, condividiamo i nostri sviluppi e li pubblichiamo. Ad esempio, su GitHub c'è il nostro plugin per Nextcloud, che forniamo ai clienti, migliorando la sicurezza dei dati in caso di cancellazione accidentale o intenzionale.

Strumenti di backup

Abbiamo iniziato la nostra ricerca di metodi di soluzione scegliendo uno strumento per la creazione di backup.

Il normale tar + gzip non funziona bene: i dati sono duplicati. Un incremento spesso contiene pochissime modifiche effettive e la maggior parte dei dati all'interno di un singolo file viene ripetuta.
C'è un altro problema: la ridondanza dell'archiviazione distribuita dei dati. Usiamo minio e i suoi dati sono sostanzialmente ridondanti. Oppure dovevi fare un backup tramite minio stesso: caricarlo e utilizzare tutti gli spaziatori tra il file system e, cosa non meno importante, c'è il rischio di dimenticare alcuni bucket e metainformazioni. Oppure usa la deduplicazione.

Gli strumenti di backup con duplicazione sono disponibili in open source (su Habré c'erano articoli sull'argomento) e i nostri finalisti lo erano Borg и Resto. Di seguito il nostro confronto tra le due applicazioni, ma per ora vi raccontiamo come abbiamo organizzato l'intero schema.

Gestione dei backup

Borg e Restic sono buoni, ma nessuno dei due prodotti ha un meccanismo di controllo centralizzato. Ai fini della gestione e del controllo abbiamo scelto uno strumento che abbiamo già implementato, senza il quale non possiamo immaginare il nostro lavoro, compresa l'automazione: questo è il noto CI/CD - GitLab.

L'idea è la seguente: gitlab-runner è installato su ciascun nodo che memorizza i dati Nextcloud. Il runner esegue uno script in base a una pianificazione che monitora il processo di backup e avvia Borg o Restic.

Cosa abbiamo ottenuto? Feedback dall'esecuzione, comodo controllo sulle modifiche, dettagli in caso di errore.

Qui qui su GitHub abbiamo pubblicato esempi di script per varie attività e alla fine lo abbiamo allegato al backup non solo di Nextcloud, ma anche di molti altri servizi. C'è anche uno scheduler se non vuoi configurarlo manualmente (e noi non vogliamo) e .gitlab-ci.yml

Non c'è ancora modo di modificare il timeout CI/CD nell'API Gitlab, ma è piccolo. Ha bisogno di essere aumentato, diciamo 1d.

GitLab, fortunatamente, può essere avviato non solo in base a un commit, ma solo in base a una pianificazione, questo è esattamente ciò di cui abbiamo bisogno.

Ora riguardo allo script wrapper.

Impostiamo le seguenti condizioni per questo script:

• Dovrebbe essere lanciato sia dal corridore che manualmente dalla console con la stessa funzionalità.
• Devono esserci gestori di errori:
• codice di ritorno.
• cercare una stringa nel log. Ad esempio, per noi un errore può essere un messaggio che il programma non considera fatale.
• Timeout dell'elaborazione. Il tempo di consegna deve essere ragionevole.
• Abbiamo bisogno di un registro molto dettagliato. Ma solo in caso di errore.
• Prima di iniziare vengono inoltre effettuati numerosi test.
• Piccoli bonus per comodità che abbiamo trovato utili durante il processo di supporto:
• L'inizio e la fine vengono registrati nel syslog della macchina locale. Ciò aiuta a collegare gli errori di sistema e l'operazione di backup.
• Parte del log degli errori, se presente, viene emessa su stdout, l'intero log viene scritto in un file separato. È conveniente esaminare immediatamente CI e valutare l'errore se è banale.
• Modalità di debug.

Il registro completo viene salvato come artefatto in GitLab; se non si verificano errori, il registro viene eliminato. Scriviamo lo script in bash.

Saremo lieti di prendere in considerazione qualsiasi suggerimento e commento riguardante l'open source: benvenuto.

Come funziona

Un runner con un esecutore Bash viene avviato sul nodo di backup. Secondo lo scheduler, il lavoro CI/CD viene avviato in una rapa speciale. Il corridore avvia uno script wrapper universale per tali attività, controlla la validità del repository di backup, dei punti di montaggio e di tutto ciò che desideriamo, quindi esegue il backup e ripulisce quello vecchio. Il backup finito stesso viene inviato a S3.

Lavoriamo secondo questo schema: si tratta di un fornitore AWS esterno o equivalente russo (è più veloce e i dati non lasciano la Federazione Russa). Oppure installiamo un minio cluster separato per il cliente sul suo sito per questi scopi. Di solito lo facciamo per motivi di sicurezza, quando il cliente non vuole che i dati lascino il suo circuito.

Non abbiamo utilizzato la funzionalità di invio del backup tramite ssh. Ciò non aggiunge sicurezza e le capacità di rete del provider S3 sono molto più elevate della nostra macchina ssh.

Per proteggere il tuo computer locale da un hacker, poiché può cancellare i dati su S3, devi abilitare il controllo delle versioni.
Il backup crittografa sempre il backup.

Borg ha una modalità non crittografata none, ma sconsigliamo vivamente di accenderlo. In questa modalità non solo non ci sarà alcuna crittografia, ma non verrà calcolato il checksum di ciò che si sta scrivendo, il che significa che l'integrità potrà essere verificata solo indirettamente, tramite indici.

Uno scheduler separato controlla l'integrità degli indici e dei contenuti dei backup. Il controllo è lento e lungo, quindi lo eseguiamo separatamente una volta al mese. Potrebbero essere necessari diversi giorni.

Leggimi in russo

funzioni di base

• prepare formazione
• testcheck controllo della prontezza
• maincommand squadra centrale
• forcepostscript una funzione che viene eseguita alla fine o per errore. Lo usiamo per smontare la partizione.

Funzioni di servizio

• cleanup Registriamo gli errori o cancelliamo il file di registro.
• checklog analizzare il registro per rilevare la presenza di una riga con un errore.
• ret gestore dell'uscita.
• checktimeout controlla il timeout.

Ambiente

• VERBOSE=1 Visualizziamo immediatamente gli errori sullo schermo (stdout).
• SAVELOGSONSUCCES=1 salvare il registro in caso di successo.
• INIT_REPO_IF_NOT_EXIST=1 Crea un repository se non esiste. Disabilitato per impostazione predefinita.
• TIMEOUT tempo massimo per l'operazione principale. Puoi impostarlo come "m", "h" o "d" alla fine.

Modalità di archiviazione per vecchie copie. Predefinito:

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

Variabili all'interno dello script

• ERROR_STRING — stringa per il registro di check-in in caso di errore.
• EXTRACT_ERROR_STRING — espressione per mostrare la stringa in caso di errore.
• KILL_TIMEOUT_SIGNAL — segnale per l'uccisione in caso di timeout.
• TAIL — quante stringhe con errori sullo schermo.
• COLORMSG — colore del messaggio (giallo predefinito).

Quello script, che si chiama wordpress, ha un nome condizionale, il suo trucco è che esegue anche il backup del database mysql. Ciò significa che può essere utilizzato per installazioni Nexcloud a nodo singolo, dove è possibile anche eseguire il backup del database. La comodità non è solo che tutto è in un unico posto, ma anche che il contenuto del database è vicino al contenuto dei file, poiché la differenza temporale è minima.

Restic contro Borg

Ci sono anche confronti tra Borg e Restic qui su Habré, e non avevamo il compito di realizzarne un altro, ma il nostro. Per noi era importante come sarebbe apparso sui nostri dati, con le nostre specifiche. Li portiamo.

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

• Resistenza al lavoro incompiuto. Controlla l'uccisione -9.
• Spazio sul disco.
• Fabbisogno di risorse (CPU, memoria).
• Dimensioni dei BLOB archiviati.
• Lavorare con S3.
• Controllo dell'integrità.

Per i test abbiamo preso un client con dati reali e una dimensione totale di 1,6 TB.
Condizioni.

Borg non sa come lavorare direttamente con S3 e abbiamo montato il disco come fusibile, tramite stupidi. Restic lo ha inviato allo stesso S3.

Goofys funziona molto velocemente e bene, e ce ne sono modulo cache del disco, che velocizza ancora di più il lavoro. È in fase beta e, francamente, si è verificato un crash con perdita di dati durante i test (altri). Ma la comodità è che la procedura di backup in sé non richiede molta lettura, ma soprattutto scrittura, quindi utilizziamo la cache solo durante i controlli di integrità.

Per ridurre l'influenza della rete, abbiamo utilizzato un provider locale: Yandex Cloud.

Risultati dei test comparativi.

• Kill -9 con un ulteriore riavvio hanno avuto entrambi successo.
• Spazio sul disco. Borg può comprimere, quindi i risultati sono quelli previsti.

Sostenitore
dimensione

Borg
562Gb

Resto
628Gb

• Per CPU
  Borg stesso consuma poco, con la compressione predefinita, ma deve essere valutato insieme al processo goofys. In totale, sono comparabili e utilizzano circa 1,2 core sulla stessa macchina virtuale di test.
• Memoria. Restic è di circa 0,5 GB, Borg è di circa 200 MB. Ma tutto questo è insignificante rispetto alla cache dei file di sistema. Quindi è consigliabile allocare più memoria.
• La differenza nella dimensione del blob era sorprendente.

Sostenitore
dimensione

Borg
circa 500 MB

Resto
circa 5 MB

• L'esperienza S3 di Restic è eccellente. Lavorare con Borg tramite goofys non solleva dubbi, ma è stato notato che è consigliabile eseguire unmount dopo aver completato il backup per ripristinare completamente la cache. La particolarità di S3 è che i blocchi sottopompati non verranno mai inviati al bucket, il che significa che i dati riempiti in modo incompleto causano gravi danni.
• Il controllo di integrità funziona bene in entrambi i casi, ma la velocità differisce in modo significativo.
  Resto 3,5 ore.
  Borg, con una cache di file SSD da 100 GB – Ore 5.Circa la stessa velocità risulterà se i dati si trovano su un disco locale.
  Borg legge direttamente da S3 senza cache 33 ore. Mostruosamente lungo.

La conclusione è che Borg può comprimersi e ha blob più grandi, il che rende più economiche le operazioni di archiviazione e GET/PUT in S3. Ma ciò avviene a costo di una verifica più complessa e più lenta. Per quanto riguarda la velocità di recupero, non abbiamo notato alcuna differenza. Restic impiega i backup successivi (dopo il primo) un po' più a lungo, ma non in modo significativo.

Non ultima nella scelta è stata la dimensione della comunità.

E abbiamo scelto Borg.

Qualche parola sulla compressione

Borg ha un nuovo eccellente algoritmo di compressione nel suo arsenale: zstd. La qualità della compressione non è peggiore di gzip, ma molto più veloce. E paragonabile in velocità al lz4 predefinito.

Ad esempio, un dump del database MySQL viene compresso due volte meglio di lz4 alla stessa velocità. Tuttavia, l’esperienza con i dati reali mostra che c’è pochissima differenza nel rapporto di compressione del nodo Nextcloud.

Borg ha una modalità di compressione piuttosto bonus: se il file ha un'entropia elevata, la compressione non viene applicata affatto, il che aumenta la velocità. Abilitato tramite opzione durante la creazione
-C auto,zstd
per l'algoritmo zstd
Quindi con questa opzione, rispetto alla compressione predefinita, abbiamo ottenuto
rispettivamente 560Gb e 562Gb. I dati dell'esempio sopra, lascia che te lo ricordi, senza compressione il risultato è 628 Gb. Il risultato di 2 GB di differenza ci ha un po' sorpreso, ma abbiamo pensato che l'avremmo comunque scelto. auto,zstd.

Metodo di verifica del backup

Secondo lo scheduler, la macchina virtuale viene avviata direttamente dal provider o dal client, il che riduce notevolmente il carico di rete. Almeno è più economico che sollevarlo da solo e attirare 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/

Utilizzando lo stesso schema, controlliamo i file con un antivirus (a posteriori). Dopotutto, gli utenti caricano cose diverse su Nextcloud e non tutti hanno un antivirus. L'esecuzione delle ispezioni al momento del getto richiede troppo tempo e interferisce con l'attività.

La scalabilità si ottiene eseguendo corridori su nodi diversi con tag diversi.
Il nostro monitoraggio raccoglie gli stati dei backup tramite l'API GitLab in un'unica finestra; se necessario, i problemi vengono facilmente notati e altrettanto facilmente localizzati.

conclusione

Di conseguenza, sappiamo per certo che eseguiamo backup, che i nostri backup sono validi, che i problemi che ne derivano richiedono poco tempo e vengono risolti a livello dell'amministratore di turno. I backup occupano davvero poco spazio rispetto a tar.gz o Bacula.

Fonte: habr.com