hashget è un deduplicatore gratuito e open source simile a uno strumento di archiviazione che consente di ridurre significativamente le dimensioni dei backup, oltre a organizzare schemi di backup incrementale e differenziale e non solo. Questo è un articolo introduttivo che descrive le funzionalità. L'uso stesso di hashget (piuttosto semplice) è descritto in

progetto e README documentazione wiki Secondo la legge del genere, comincerò subito con l'intrigo — il confronto dei risultati:.

Confronto

Campione di dati

dimensione non compressa
hashget .tar.gz
.tar.gz
WordPress-5.1.1

43 Mb
11 Mb ( 26% )
155 Kb (
Linux kernel 5.0.4 0.3% )

934 Mb
161 Mb ( 20% )
4.7 Mb (
Debian 9 (LAMP) LXC VM 0.5% )

724 Mb
165 Mb ( 23% )
4.1 Mb (
La storia, di come dovrebbe essere un backup ideale ed efficiente 0.5% )

Ogni volta che facevo un backup di una nuova macchina virtuale, mi assaliva la sensazione di non fare la cosa giusta. Perché ottengo un backup pesante da un sistema in cui la mia preziosa creazione immortale è solo un file index.html con il testo "Hello world"?

Perché nel mio backup c'è un file di 16 megabyte /usr/sbin/mysqld? Spetta proprio a me conservare questo importante file, e se non ce la faccio — sarà perso per l'umanità? Probabilmente no. È conservato su server debian ad alta affidabilità (l'affidabilità e la continuità non sono paragonabili a quelle che posso offrire io), e nelle copie di sicurezza (milioni di esse) di altri amministratori. È davvero necessario creare per aumentare l'affidabilità 10.000.000 + 1 copia di questo file importante?

In effetti

risolve questo problema. Durante l'archiviazione — crea un backup molto piccolo. Durante l'estrazione — un sistema completamente estratto, simile a quello che sarebbe stato con hashget tar -c tar -x / . (In altre parole, è un'imballaggio senza perdita di dati)Come funziona hashget

In hashget ci sono i concetti di Package e HashPackage, con i quali esegue la deduplicazione.

(pacchetto). Un file (di solito un archivio .deb o .tar.gz) che può essere scaricato in modo sicuro dalla rete e da cui si possono ottenere uno o più file.

Pacchetto HashPackage

è un piccolo file JSON che rappresenta un Package, incluso l'URL del pacchetto e le hash (sha256) dei file in esso. Ad esempio, per il pacchetto mariadb-server-core di 5 megabyte, la dimensione dell'hashpackage è solo di 6 kilobyte. Circa mille volte più piccolo. Deduplicazione

è la creazione di un archivio senza file duplicati (se il deduplicatore sa dove può essere scaricato l'originale del pacchetto, riduce i duplicati dall'archivio). Imballaggio

Pack

Durante la compressione, vengono esaminati tutti i file nella cartella da comprimere, vengono calcolati i loro hash e, se l'hash viene trovato in uno degli HashPackage noti, i metadati del file (nome, hash, permessi, ecc.) vengono salvati in un file speciale .hashget-restore.json, che sarà anch'esso incluso nell'archivio.

La compressione stessa, nel caso più semplice, non è più complicata di tar:

hashget -zf /tmp/mybackup.tar.gz --pack /path/to/data

Disimballaggio

La decompressione avviene in due fasi. Prima la normale decompressione tar:

tar -xf mybackup.tar.gz -C /path/to/data

poi il ripristino dalla rete:

hashget -u /path/to/data

Durante il ripristino, hashget legge il file .hashget-restore.json, scarica i pacchetti necessari, li decomprime ed estrae i file necessari, installandoli nei percorsi appropriati, con i giusti proprietari/gruppi/permissi.

Cose più complesse

Ciò che è descritto sopra è già sufficiente per chi desidera 'voglio come tar, ma voglio comprimere il mio Debian in 4 megabyte'. Vedremo ora cose più complesse.

Indicizzazione

Se hashget non avesse nemmeno un HashPackage, non sarebbe stato in grado di deduplicare nulla.

È possibile creare un HashPackage anche manualmente (semplicemente: hashget --submit https://wordpress.org/wordpress-5.1.1.zip -p my), ma c'è un modo più conveniente.

Per ottenere gli hashpackage necessari, c'è una fase di indicizzazione viene eseguita automaticamente con il comando --pack) e euristiche. Durante l'indicizzazione, hashget 'nutre' ogni file trovato alle euristiche disponibili che lo riguardano. Le euristiche possono quindi indicizzare un qualsiasi Package per creare un HashPackage.

Ad esempio, l'euristica di Debian ama il file /var/lib/dpkg/status e scopre i pacchetti debian installati; se non sono indicizzati (non è stato creato alcun HashPackage per loro), li scarica e li indicizza. Si ottiene un effetto molto piacevole: hashget deduplicerà sempre in modo efficiente i sistemi operativi Debian, anche se hanno i pacchetti più recenti.

File di suggerimenti (hint)

Se nella tua rete viene utilizzato qualche pacchetto proprietario o pacchetto pubblico non incluso nelle euristiche di hashget, puoi aggiungere un semplice file di hint hashget-hint.json secondo il modello:

{
    "project": "wordpress.org",
    "url": "https://ru.wordpress.org/wordpress-5.1.1-ru_RU.zip"
}

Successivamente, ogni volta che viene creato un archivio, il pacchetto sarà indicizzato (se non era già stato fatto) e i file del pacchetto saranno deduplicati dall'archivio. Non è necessario alcun programmazione, tutto può essere fatto da vim risparmiando su ogni backup. Si noti che grazie all'approccio tramite checksum, se alcuni file del pacchetto vengono modificati localmente (ad esempio, un file di configurazione viene cambiato) – i file modificati saranno conservati nell'archivio «così come sono» e non verranno ridotti.

Se qualche pacchetto di vostra proprietà viene aggiornato periodicamente, ma le modifiche non sono molto grandi, è possibile effettuare un hint solo per le versioni principali. Ad esempio, per la versione 1.0 è stato fatto un hint che punta a mypackage-1.0.tar.gz, e verrà completamente deduplicato, poi è stata rilasciata la versione 1.1, che è leggermente diversa, ma l'hint non è stato aggiornato. Nessun problema. Vengono deduplicati solo i file che corrispondono (che possono essere recuperati) con la versione 1.0.

L'euristica che tratta il file hint è un buon esempio per comprendere il meccanismo interno delle euristiche. Essa elabora solo i file hashget-hint.json (o .hashget-hint.json con il punto) e ignora tutti gli altri. Da questo file determina quale URL del pacchetto deve essere indicizzato, e hashget lo indicizza (se non è stato fatto prima)

HashServer

Sarebbe piuttosto laborioso eseguire completamente l'indicizzazione durante la creazione dei backup. È necessario scaricare ogni pacchetto, decomprimere, indicizzare. Pertanto, hashget utilizza uno schema con HashServer. Quando viene rilevato un pacchetto debian installato, se non viene trovato nei HashPackage locali, prima si tenta semplicemente di scaricare HashPackage dal server hash. E solo se non ci riesce - hashget scarica e hash codice il pacchetto (e lo carica su hashserver, affinché in seguito hashserver lo renda disponibile).

HashServer non è un elemento obbligatorio dello schema, non critico, serve esclusivamente a velocizzare e ridurre il carico sui repository. Può essere facilmente disabilitato (con l'opzione --hashserver senza parametri). Inoltre, è facile poterlo realizzare il proprio hashserver.

Backup incrementali e differenziali, scadenza programmata

hashget permette di creare molto facilmente uno schema di backup incrementali e differenziali. Perché non indicizzare il nostro backup stesso (con tutti i nostri file unici)? Un solo comando --submit E tutto pronto! Il prossimo backup che creerà hashget non includerà i file di questo archivio.

Ma questo non è un approccio molto valido, perché potrebbe succedere che durante il ripristino dovremo prendere in considerazione tutti i backup hashget della storia (se in ognuno ci sarà almeno un file unico). A questo scopo esiste un meccanismo di scadenza programmata dei backup. Durante l'indicizzazione è possibile specificare la data di scadenza del HashPackage --expires 2019-06-01, e al verificarsi di tale data (dalle 00:00), non verrà utilizzato. L'archivio stesso può essere mantenuto anche dopo questa data (anche se hashget può comodamente mostrare gli URL di tutti i backup che sono scaduti/scadranno al momento attuale o a qualsiasi data).

Ad esempio, se il 1° giorno facciamo un backup completo e lo indicizziamo con una durata fino alla fine del mese — otteniamo uno schema di backup differenziale.

Se indicizziamo anche i nuovi backup — avremo uno schema di backup incrementale.

A differenza degli schemi tradizionali, hashget consente di utilizzare più fonti di base. Il backup sarà ridotto sia grazie alla rimozione dei file dai backup precedenti (se esistono), sia grazie ai file pubblici (quelli che possono essere scaricati).

Se per qualche motivo non ci fidiamo dell'affidabilità delle risorse debiane (https://snapshot.debian.org/) o stiamo utilizzando un'altra distribuzione, possiamo semplicemente effettuare un backup completo con tutti i pacchetti una sola volta e poi basarci su di esso (disattivando l'euristica). Ora, se tutti i server delle nostre distribuzioni dovessero risultare inaccessibili (su Internet souvenir o durante un'apocalisse zombie), ma i nostri backup saranno in ordine — potremo ripristinare qualsiasi breve backup differenziale, basandoci solo sui nostri backup precedenti.

Hashget si basa esclusivamente su fonti di ripristino affidabili a vostra discrezione. Quelle che consideri affidabili verranno utilizzate.

FilePool e Glacier

Il meccanismo FilePool permette di non dover accedere costantemente a server esterni per scaricare pacchetti, ma di utilizzare pacchetti da una directory locale o da un server aziendale, ad esempio:

$ hashget -u . --pool /tmp/pool

$ hashget -u . --pool http://myhashdb.example.com/

Per creare un pool in una cartella locale, basta semplicemente creare una cartella e inserire i file al suo interno; hashget troverà autonomamente ciò di cui ha bisogno tramite gli hash. Per rendere il pool accessibile tramite HTTP, è necessario creare symlink in un modo speciale, il che può essere fatto con un solo comando (hashget-admin --build /var/www/html/hashdb/ --pool /tmp/pool). L'HTTP FilePool consiste in file statici, quindi può essere servito da qualsiasi server web molto semplice, con un carico quasi nullo sul server.

Grazie a FilePool, è possibile utilizzare come risorse di base non solo risorse su http(s), ma anche, ad esempio, Amazon Glacier.

Dopo aver caricato il backup su Glacier, otteniamo il suo ID di caricamento e lo utilizziamo come URL. Ad esempio:

hashget --submit Glacier_Upload_ID --file /tmp/my-glacier-backup.tar.gz --project glacier --hashserver --expires 2019-09-01

Ora i nuovi backup (differenziali) si baseranno su questo backup e saranno più corti. Dopo aver estratto il differenziale con tar, possiamo vedere a quali risorse si basa:

hashget --info /tmp/unpacked/ list

e con uno semplice script shell possiamo scaricare da Glacier tutti questi file nel pool e avviare un normale ripristino: hashget -u /tmp/unpacked --pool /tmp/pool

Ne vale la pena

Nel caso più semplice, pagherete semplicemente di meno per i backup (se li conservate da qualche parte nel cloud a pagamento). Potrebbe essere molto, molto meno.

Ma non è l'unico vantaggio. La quantità si trasforma in qualità. Puoi usare questo per ottenere un miglioramento qualitativo nel sistema di backup. Ad esempio, visto che i backup ora sono più brevi, puoi fare un backup giornaliero invece di mensile. Conservarli non per sei mesi, come prima, ma per 5 anni. Prima li conservavi in un'unità di archiviazione "fredda" (Glacier), ora puoi conservarli in un'unità calda, da cui puoi sempre scaricare rapidamente il backup e ripristinarti in pochi minuti, non in un giorno.

Puoi aumentare l'affidabilità della conservazione dei backup. Se attualmente li conserviamo in un'unica unità di storage, riducendo il volume dei backup, saremo in grado di conservarli in 2-3 unità senza subire danni, anche se una di esse si danneggia.

Come provare e iniziare a usarli?

Visitiamo la pagina di GitLab https://gitlab.com/yaroslaff/hashget, installiamo con un solo comando (pip3 install hashget[plugins]) e semplicemente seguiamo il quick-start. Penso che fare tutte le cose semplici richiederà circa 10-15 minuti. Poi possiamo provare a comprimere le nostre macchine virtuali, creare, se necessario, file di hint per comprimere ulteriormente, giocare con i pool, il database locale di hash e l’hashserver, se sarà di interesse, e il giorno dopo vedere qual è la dimensione del backup incrementale rispetto a quello di ieri.

Fonte: habr.com