Il backup di un database MySQL in Git è una buona idea?

Sto cercando di migliorare la situazione del backup per la mia applicazione. Ho un'applicazione Django e un database MySQL. Ho letto un articolo che suggerisce di eseguire il backup del database in Git.

Da un lato mi piace, poiché manterrà una copia dei dati e del codice sincronizzati.

Ma Git è progettato per il codice, non per i dati. Come tale, farà un sacco di lavoro extra diffondendo il dump di MySQL ad ogni commit, il che non è davvero necessario. Se comprimo il file prima di memorizzarlo, git diffonde comunque i file?

(Il file di dump è attualmente non compresso da 100 MB, 5,7 MB quando è decompresso.)

Modifica: le definizioni del codice e dello schema del database sono già in Git, sono davvero i dati che mi preoccupano per il backup ora.

Prima di perdere qualsiasi dato, fammi provare a introdurre una prospettiva di amministratore di sistema a questa domanda.

C'è solo una ragione per cui creiamo i backup: rendere possibile il ripristino quando qualcosa va storto, come sempre lo farà. Come tale, un sistema di backup adeguato ha requisiti che vanno ben oltre ciò che git può ragionevolmente gestire.

Ecco alcuni dei problemi che posso prevedere con il tentativo di eseguire il backup del database in git:

• Il repository crescerà notevolmente con ogni "backup". Dal momento che git memorizza interi oggetti (anche se compressi) e poi li diffonde in seguito (ad esempio quando si esegue git gc) e mantiene la cronologia per sempre , si avrà una grande quantità di dati memorizzati che in realtà non è necessario o addirittura desiderato. Potrebbe essere necessario limitare la quantità o il periodo di conservazione dei backup eseguiti per risparmiare spazio su disco o per motivi legali, ma è difficile rimuovere le vecchie revisioni da un repository git senza molti danni collaterali.
• Il ripristino è limitato ai punti temporali archiviati nel repository e, poiché i dati sono così grandi, tornare indietro per un periodo di tempo banale può essere lento. Un sistema di backup progettato allo scopo limita la quantità di dati archiviati fornendo potenzialmente maggiore granularità e offre ripristini più rapidi, riducendo i tempi di inattività in caso di disastro. Le soluzioni di backup compatibili con il database ( esempio ) possono anche fornire backup continui , garantendo che non venga persa una singola transazione.
• È probabile che anche i commit siano lenti e rallentino con la crescita del database. Ricorda che git è essenzialmente un archivio dati di valori-chiave mappato su un filesystem , e quindi è soggetto alle caratteristiche prestazionali del filesystem sottostante. È possibile per questo periodo di tempo eventualmente superare l'intervallo di backup e a quel punto non è più possibile rispettare il contratto di servizio. Anche i sistemi di backup corretti richiedono più tempo per il backup man mano che i dati crescono, ma non in modo così drammatico, poiché gestiranno automaticamente le proprie dimensioni in base al criterio di conservazione che è stato configurato.

Nonostante apparentemente ci siano diverse cose interessanti che puoi fare con un dump del database se lo metti in git, nel complesso non posso raccomandarlo allo scopo di mantenere i backup. Soprattutto perché i sistemi di backup sono ampiamente disponibili (e molti sono persino open source) e funzionano molto meglio per proteggere i dati e consentire il ripristino il più rapidamente possibile.

I miei due centesimi: non credo sia una buona idea. GIT fa qualcosa di simile "Memorizzazione istantanee di un insieme di file in diversi punti nel tempo", in modo da poter utilizzare perfettamente GIT per qualcosa di simile, ma questo non significa che si dovrebbe . GIT è progettato per archiviare il codice sorgente, quindi manchi la maggior parte delle sue funzionalità e scambieresti molte prestazioni solo per un po 'di praticità.

Suppongo che il motivo principale per cui stai pensando a questo sia quello di "mantenere una copia dei dati e del codice in sincronia", e questo significa che sei preoccupato che la versione 2.0 del tuo codice abbia bisogno di uno schema di database diverso rispetto alla versione 1.0 . Una soluzione più semplice sarebbe quella di memorizzare lo schema del database, come un insieme di script SQL con CREATEistruzioni, lungo il codice sorgente nel repository Git. Quindi, una parte della procedura di installazione consisterebbe nell'eseguire quegli script su un server database precedentemente installato.

Il contenuto effettivo di quelle CREATEtabelle -d non ha nulla a che fare con la versione del codice sorgente. Immagina di installare il tuo software, versione 1.0, sul server A e sul server B, che vengono utilizzati in diverse società da diversi team. Dopo alcune settimane, il contenuto delle tabelle sarà molto diverso, anche se gli schemi sono esattamente gli stessi.

Poiché si desidera eseguire il backup dei contenuti del database, suggerirei di utilizzare uno script di backup che tagga il dump del backup con la versione corrente del software a cui appartiene il dump. Lo script dovrebbe trovarsi nel repository GIT (in modo che abbia accesso alla stringa della versione del codice sorgente), ma i dump stessi non appartengono a un sistema di controllo della versione.

MODIFICA :

Dopo aver letto il post originale che ha motivato la domanda , trovo un'idea ancora più dubbia. Il punto chiave è che il mysqldumpcomando trasforma lo stato corrente di un DB in una serie di INSERTistruzioni SQL e GIT può differirle per ottenere solo le righe della tabella aggiornate.

La mysqldumpparte è valida, poiché si tratta di uno dei metodi di backup elencati nella documentazione di MySQL. La parte GIT è dove l'autore non riesce a notare che i server di database mantengono un registro delle transazioni al fine di recuperare dagli arresti anomali, incluso MySQL . Sta utilizzando questo registro , non GIT, per creare backup incrementali per il database. Questo ha, in primo luogo, il vantaggio di poter ruotare o svuotare i log dopo il ripristino, invece di gonfiare un repository GIT nell'infinito e oltre ...

Personalmente, non credo sia una buona idea usare un sistema di versione di controllo del codice sorgente per archiviare i file di backup, perché il controllo della versione GIT è progettato per file di dati, non per file binari o di dump come un file di dump di backup di MySQL. Il fatto che tu possa farlo non significa automaticamente che dovresti farlo. Inoltre, il tuo repository, considerando un nuovo backup del database per ogni nuovo commit, aumenterà notevolmente, utilizzando molto spazio sul disco rigido e le prestazioni di GIT ne risentiranno, con conseguente rallentamento del sistema di controllo del codice sorgente. Per me va bene eseguire una strategia di backup e avere sempre pronto un file di backup quando è necessario ripristinare il database quando qualcosa nel codice va storto, ma gli strumenti di controllo del codice sorgente non sono creati per archiviare dati binari.

Per questi motivi, non vedo alcuna utilità nell'archiviazione dei file di backup per il giorno 1 e per il giorno 2 e quindi vedere le differenze tra i due file di backup. Richiederà molto lavoro extra e inutile. Invece di utilizzare GIT per archiviare i backup del database quando si commette un nuovo codice, archiviare i backup del database in un percorso diverso, separati da data e ora e inserire nel codice alcuni riferimenti ai nuovi backup del database creati per ogni versione, utilizzando i tag, come qualcuno ha già suggerito.

La mia nota finale sui backup del database e GIT: Un amministratore di database, quando deve ripristinare un database a causa della perdita di alcuni dati, non deve controllare le differenze tra il file di backup per il giorno 1 e il file di backup per il giorno 2, deve solo sapere qual è il ultimo file di backup che gli consentirà di ripristinare il database, senza errori e perdite di dati, riducendo i tempi di inattività. In effetti, il compito di un amministratore di database è di rendere i dati disponibili per il ripristino il più presto possibile, quando il sistema, per alcuni motivi, fallisce. Se si archiviano i backup del database in GIT, collegati ai propri commit, non si consente all'amministratore del database di ripristinare rapidamente i dati, poiché i backup sono limitati ai punti temporali archiviati nel repository GIT e per ridurre i tempi di inattività del sistema,

Quindi, non consiglio di archiviare i backup utilizzando GIT, utilizzare invece una buona soluzione software di backup (ce ne sono alcuni qui ), che fornirà maggiore granularità e ti consentirà di mantenere i tuoi dati sicuri e protetti, e di rendere recupero dati semplice e veloce in caso di catastrofi.

Non si dovrebbero archiviare dati binari in Git, in particolare nel database.
Modifiche al codice e modifiche al DML del database sono cose totalmente diverse.

MySQL e Oracle possono scrivere registri di archivio allo scopo di essere ripristinati in qualsiasi momento. Basta fare il backup di quei registri in un posto sicuro e andrà tutto bene.

Usare Git per eseguire il backup di questi "registri di archivio" non ha senso. I registri di archivio negli ambienti di produzione sono piuttosto pesanti e devono essere rimossi dopo aver eseguito backup regolari regolari. Inoltre è inutile metterli in git - quelli sono già un repository in un certo senso.