diff diffrazione per la memorizzazione di file molto simili?


18

Al lavoro facciamo una discarica notturna dei nostri database mysql. Di giorno in giorno, direi che quasi il 90-95% dei dati è duplicato, aumentando col passare del tempo. (Cavolo a questo punto alcuni sono probabilmente del 99%)

Questi dump sono dove una riga è una singola istruzione INSERT mysql, quindi le uniche differenze sono intere righe e l'ordine in cui si trovano nel file. Se li avessi ordinati, la differenza effettiva da un file all'altro sarebbe molto piccola.

Ho cercato e non ho trovato alcun modo per ordinare l'output in dump. Potrei inoltrarlo tramite il sortcomando, comunque. Quindi ci sarebbero lunghi, lunghi blocchi di linee identiche.

Quindi sto cercando di trovare un modo per memorizzare solo i diff. Potrei iniziare con una discarica principale, e differire da quello ogni notte. Ma le differenze sarebbero più grandi ogni notte. Oppure, potrei fare diff rolling, che individualmente sarebbe molto piccolo, ma sembra che ci vorrebbe sempre più tempo per calcolare, se dovessi mettere insieme un master diff di tutta la serie ogni notte.

È fattibile? Con quali strumenti?


Modifica Non sto chiedendo come eseguire i backup di mysql. Dimentica mysql per il momento. È un'aringa rossa. Quello che voglio sapere è come creare una serie di diff differenziali da una serie di file. Ogni notte otteniamo un file (che sembra essere un file mysqldump ) che è simile al 99% a quello precedente. Sì, li comprimiamo tutti. Ma è ridondante avere tutta quella ridondanza in primo luogo. Tutto ciò di cui ho veramente bisogno sono le differenze rispetto alla sera prima ... che è solo l'1% diverso dalla notte prima ... e così via. Quindi quello che sto cercando è come fare una serie di diff, quindi ho bisogno di immagazzinare solo l'1% ogni notte.

Risposte:


14

Due strumenti di backup in grado di memorizzare differenze binarie sono rdiff-backup e duplicity . Entrambi sono basati librsync, ma soprattutto si comportano in modo molto diverso. Rdiff-backup memorizza le differenze di copia e inversione più recenti, mentre la duplicità memorizza le differenze incrementali tradizionali. I due strumenti offrono anche un diverso set di funzionalità periferiche.


1
IIUC, rdiff-backup è più attraente, poiché consente di sfogliare normalmente il backup, mentre la duplicità ha solo una vecchia copia.
Tshepang,

So che la domanda + domanda è piuttosto vecchia, ma potresti aggiungere un esempio di comandi che mostrano come usarla? Ad esempio per backup201901.tar.gz, backup201902.tar.gz, ..., backup201912.tar.gz, backup202001.tar.gz. Ciò sarebbe utile per riferimento futuro.
Basj

L'ultima volta che ho seguito rdiff-backup, gli sviluppatori principali sono passati e il progetto si è ristagnato, non so se è cambiato. È stato anche incredibilmente lento sulle reti, se è importante.
Lizardx,

13

Ultimamente ho provato a archiviare i dump del database in git. Questo potrebbe diventare poco pratico se i dump del tuo database sono davvero grandi, ma ha funzionato per me per database piccoli (siti Wordpress e simili).

Il mio script di backup è approssimativamente:

cd /where/I/keep/backups && \
mysqldump > backup.sql && \
git commit -q -m "db dump `date '+%F-%T'`" backup.sql

Questo memorizza solo differenze?
user394

2
Sì. È molto conveniente! Puoi "estrarre" il file da qualsiasi momento e git combinerà automaticamente le differenze per darti l'intero file così com'era in quel momento.
sep332

1
Questo post sul blog (non il mio) è più dettagliato: viget.com/extend/backup-your-database-in-git I commenti approfondiscono i pro ei contro e gli avvertimenti. Aggiungerò anche che se usi git, otterrai molto di più che essere in grado di ripristinare le versioni. Puoi anche taggare i dump o avere rami separati (dev / prod). Il modo in cui lo guardo è git (o inserire il tuo sistema di controllo versione moderna preferito) fa un lavoro migliore di quello che potrei facendo rotolando la mia 'soluzione' diff / gzip. Un avvertimento su questo articolo: non spingere i tuoi dump su github a meno che tu non li desideri pubblici (o stai pagando per un repository privato).
inzuppare il

1
Git non non unico negozio diff. Infatti, in primo luogo memorizza l'istantanea completa di ogni revisione, ma con varie ottimizzazioni. Vedi questa risposta eccellente e la sua domanda
tremby

3

Potresti fare qualcosa del genere (con a.sqlcome backup settimanale).

mysqldump > b.sql
diff a.sql b.sql > a1.diff
scp a1.diff backupserver:~/backup/

I tuoi file diff diventeranno più grandi entro la fine della settimana.

Il mio consiglio però è semplicemente decomprimerlo (utilizzare gzip -9per la massima compressione). Al momento lo facciamo e ciò utilizza un file gz da 59 MB mentre l'originale è 639 MB.


Li stiamo già comprimendo :)
user394

1

Esistono diversi approcci possibili da seguire, a seconda delle dimensioni e dell'effettiva somiglianza testuale dei dump del database:

  1. applicare un programma di backup deduplicato che utilizza un checksum continuo come richiesto dall'OP, ad esempio restic ( https://restic.net/ ) o borgbackup ( https://borgbackup.readthedocs.io/ ) sui dump non modificati. Entrambi i sistemi consentono anche il montaggio di una determinata versione di backup tramite FUSE e funzionano in un cosiddetto modo sempre incrementale.
  2. Disaccoppiare la struttura del database dal contenuto, in modo simile a come lo fanno i ragazzi dell'NCBI per le loro basi di dati genetici piuttosto grandi. Cioè: dovresti creare script SQL per creare lo schema del database (ad esempio come ftp://ftp.ncbi.nlm.nih.gov/snp/organisms/human_9606_b151_GRCh38p7/database/organism_schema/ ) e archiviare separatamente il contenuto delle tabelle in formato binario in chiaro o compresso senza le istruzioni insert (come fatto in ftp://ftp.ncbi.nlm.nih.gov/snp/organisms/human_9606_b151_GRCh38p7/database/organism_data/) ad es. come valori separati da tabulazione o virgola. Naturalmente ciò richiede una routine di importazione separata che crei le istruzioni di inserimento appena in tempo per importare nuovamente i dati nel database, ovvero ripristinare dal backup. Nel caso in cui il vostro DBMS offra un importatore di file CSV, il requisito dello script aggiuntivo sopra può essere omesso. I file di testo così rimpiccioliti potrebbero quindi essere nuovamente inseriti nei programmi di backup summenzionati o in altri regolari come rdiff-backup.
  3. Scegli una soluzione in cui la struttura e il contenuto sono liberamente associati usando un formato come i file arff come utilizza WEKA ( https://www.cs.waikato.ac.nz/ml/weka/arff.html ): la struttura e i tipi di dati di le colonne verrebbero dichiarate nell'intestazione del file e il contenuto effettivo verrebbe seguito separato da un'istruzione @DATA ancora una volta in forma simile a CSV. Molti strumenti ETL al giorno d'oggi offrono un lettore arff oltre a un connettore di base di dati. I file stessi potrebbero essere nuovamente inseriti nei normali programmi di backup

Questa risposta risponde alla domanda "come eseguire il backup di backup dei dump del database", ma non alla domanda più generale "Come eseguire il backup di backup di backup molto simili", che è quello che ho chiesto
user394

Sinceramente sospetto che ciò che realmente vuoi ottenere sia la deduplicazione, che è menzionata nel primo approccio. Forse ti piacerebbe dare un'occhiata a restic.net/blog/2015-09-12/restic-foundation1-cdc dove è descritto, e forse ti piacerebbe provarli?
jf1,

Questo commento, reso più dettagliato, darebbe una risposta molto più pertinente di quella attuale.
user394

-3

(Non l'ho fatto in produzione.)

Esegui un backup completo una volta al giorno o alla settimana. Registri di inoltro di backup una volta all'ora o al giorno.


Che cos'è un registro di inoltro?
user394
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.