Come eseguire il backup su larga scala di Gitlab?

Quando chiedono supporto a Gitlab su come eseguire un backup da 3 TB su quelli Gitlab locali, rispondono utilizzando il nostro strumento che produce un tarball.

Questo mi sembra sbagliato a tutti i livelli. Questo tarball contiene il dump postgres, le immagini docker, i dati repo, la configurazione GIT LFS, ecc. E così via. Il backup di TB di dati statici insieme a dati molto dinamici di KB non risulta corretto. E poi arriva il problema di, vogliamo fare un backup ogni ora.

Domanda

Mi piacerebbe davvero sapere dagli altri come lo fanno, per ottenere un backup coerente.

ZFS su Linux andrebbe bene con me, se questo fa parte della soluzione.

— sandra
fonte

Perché è sbagliato? Esegui il backup completo di Gitlab per ripristinarlo completamente. Non penso che sia sbagliato. Ovviamente utilizza molto più spazio rispetto ai backup incrementali, ma ... Non mi importerebbe sulle dimensioni del backup.

— Lenniey,

Avere un backup ogni ora non è inaudito, ma è impossibile fare un 3 TB in meno di un'ora con il loro approccio. E i backup per un solo giorno sarebbero ~ 100 TB, dove potrebbero esserci solo 10 MB di modifiche ai dati.

— Sandra,

OK, questa è una domanda diversa, non sul backup in generale ma sui backup frequenti.

— Lenniey,

Nei loro documenti ufficiali menzionano persino il loro metodo come lento e suggeriscono alternative:

If your GitLab server contains a lot of Git repository data you may find the GitLab backup script to be too slow. In this case you can consider using filesystem snapshots as part of your backup strategy.

non posso parlare per esperienza, però. Ma potrei dover includere qualcosa del genere presto ...

— Lenniey,

Gitlab ha opzioni nel file di configurazione e flag di backup che ti permetteranno di escludere sezioni o arrivare al punto di archiviare immagini e artefatti su un archivio oggetti

— ssube

Risposte:

Per un tempo così breve tra i backup (1h), la soluzione migliore è affidarsi allo snapshot e al send/recv supporto a livello di filesystem .

Se l'utilizzo di ZoL non è un problema nel tuo ambiente, ti consiglio vivamente di usarlo. ZFS è un filesystem molto robusto e ti piaceranno davvero tutti gli extra (es: compressione) che offre. Se combinato con sanoid/syncoid, può fornire una strategia di backup molto forte. Lo svantaggio principale è che non è incluso nel kernel mainline, quindi è necessario installarlo / aggiornarlo separatamente.

In alternativa, se hai davvero bisogno di limitarti alle cose incluse nella mainline, puoi usare BTRFS. Ma essere sicuri di capire i suoi (tanti) inconvenienti e pita .

Infine, una soluzione alternativa è quella di utilizzare lvmthinper prendere backup regolari (ad esempio: con snapper), basandosi su strumenti di terze parti (ad esempio: bdsync, blocksync, ecc) per copiare solo / delta nave.

Un approccio diverso sarebbe quello di avere due macchine replicate (via DRBD) in cui si scattano istantanee indipendenti tramite lvmthin.

— shodanshok
fonte

Che dire di postgres? Smetterebbe Gitlab e Postgres per un minuto, in modo da poter realizzare una formulazione coerente? Idealmente sarebbe fantastico se Postgres potesse essere messo in modalità di sola lettura mentre veniva fatta l'istantanea.

— Sandra,

Il ripristino di @Sandra da un'istantanea del filesystem dovrebbe apparire a postgresql (e qualsiasi altro database correttamente scritto) come uno scenario generico di "crash dell'host", innescando la propria procedura di recupero (cioè: impegnando nel database principale qualsiasi pagina parzialmente scritta). In altre parole, non è necessario mettere Postgres in modalità di sola lettura quando si scattano istantanee.

— shodanshok,

Vorrei rivedere ciò di cui si sta eseguendo il backup e possibilmente utilizzare un approccio "multi-path". Ad esempio, è possibile eseguire il backup dei repository Git eseguendo costantemente i pull di Git su un server di backup. Ciò copierebbe solo il diff e ti lascerebbe con una seconda copia di tutti i repository Git. Presumibilmente potresti rilevare nuovi repository con l'API.

E utilizzare le procedure di backup "integrate" per eseguire il backup dei problemi, ecc. Dubito che il 3 TB provenga da questa parte in modo da poter eseguire backup molto spesso a costi molto bassi. È inoltre possibile impostare il database PostgreSQL con un warm standby con replica.

Forse il tuo 3 TB proviene da immagini del contenitore nel registro Docker. Devi eseguire il backup? In tal caso, potrebbe esserci un approccio migliore proprio per quello.

Fondamentalmente, consiglierei davvero di guardare cos'è che costituisce il backup e il backup dei dati in varie parti.

Anche lo strumento di backup di GitLab ha opzioni per includere / escludere alcune parti del sistema come il Docker Registry.

— ETL
fonte

git pulls non è un backup incrementale perfetto. git push --forceinterromperà i backup o cancellerà la cronologia da essi, a seconda della modalità di implementazione.

— user371366

@ dn3s è per questo che disabiliti sempre git push --force sul repository principale. Se qualcuno vuole cambiare la storia, può creare il proprio fork e accettare tutti i rischi che comporta.

— charlie_pl,

ciò potrebbe andare bene per la replica , ma non si desidera che l'integrità dei backup si basi sul corretto comportamento dell'applicazione. cosa succede se c'è un bug nell'applicazione o è configurato in modo errato lungo la strada? cosa succede se il tuo server è compromesso da un utente malintenzionato? se l'applicazione ha la capacità di rimuovere il contenuto dall'host di backup, gran parte del valore dei backup remoti incrementali viene perso.

— user371366