— è un deduplicatore gratuito e open-source — un'utilità simile a un archiviatore che permette di ridurre significativamente le dimensioni dei backup e di organizzare schemi di backup incrementali e differenziali, e non solo. Questo è un articolo introduttivo per descrivere le funzionalità. L'uso di hashget (piuttosto semplice) è descritto in
progetto e documentazione wiki .
Confronto
Campione di dati
dimensione decompresso
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 premessa, come dovrebbe essere un backup ideale ed efficiente 0.5% )
Ogni volta che facevo un backup di una nuova macchina virtuale, non riuscivo a togliermi di dosso la sensazione di fare qualcosa di sbagliato. Perché mi ritrovavo con un backup pesante da un sistema dove la mia inestimabile creazione immortale era solo un semplice index.html con il testo "Hello world"?
Perché nel mio backup c'è un file di 16 megabyte /usr/sbin/mysqld? È davvero toccato a me preservare questo importante file, e se non riesco, sarà perso per l'umanità? Probabilmente no. È archiviato su server debian altamente affidabili (la loro affidabilità e continuità non possono assolutamente essere paragonate a quelle che posso garantire io), e anche nelle numerose copie di altri amministratori. È davvero necessario crearne un'altra copia per aumentare l'affidabilità di questo file così importante?
In effetti
risolve questo problema. Durante l'imballaggio, crea un backup molto piccolo. Durante l'estrazione, fornisce un sistema completamente decompresso, simile a quello che avremmo con tar -c tar -x / . (In altre parole, è un'imballaggio lossless)Come funziona hashget
In hashget ci sono concetti di Package e HashPackage, con cui esegue la deduplicazione.
(package). Un file (di solito un archivio .deb o .tar.gz) che può essere scaricato in modo sicuro da Internet e da cui possono essere recuperati uno o più file.
Package HashPackage
è un piccolo file JSON che rappresenta il Package, contenente anche l'URL del pacchetto e gli 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. è la creazione di un archivio senza file duplicati (se il deduplicatore sa da dove può scaricare l'originale del pacchetto, elimina i duplicati dall'archivio).
Deduplicazione Imballaggio
Durante l'imballaggio, vengono esaminati tutti i file dalla cartella da imballare, vengono calcolati i loro hash, e se l'hash è trovato in uno dei HashPackage noti, i metadati del file (nome, hash, diritti di accesso, ecc.) vengono salvati in un file speciale .hashget-restore.json, che sarà incluso anche nell'archivio.
L'imballaggio stesso, nel caso più semplice, non è più complicato di tar:
hashget -zf /tmp/mybackup.tar.gz --pack /path/to/data
L'estrazione avviene in due fasi. Prima l'estrazione normale con tar:Disimballaggio
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 estrae, e posiziona i file necessari nei percorsi giusti, con i corretti owner/group/permissions.Cose più complesse
Ciò che è stato descritto sopra è già sufficiente per coloro che "vogliono qualcosa di simile a tar, ma che impacchetta il mio Debian in 4 megabyte". Andiamo avanti e vediamo cose più complesse.
Indicizzazione
Se hashget non avesse avuto nemmeno un HashPackage, non sarebbe stato in grado di deduplicare nulla.
Un HashPackage può essere creato anche manualmente (semplicemente:
hashget --submit https://wordpress.org/wordpress-5.1.1.zip -p my ), ma esiste un metodo più comodo.Per ottenere i necessari hashpackage, c'è una fase
di indicizzazione (viene eseguita automaticamente con il comando --pack heuristiche) e . Durante l'indicizzazione, hashget "fornisce" ogni file trovato a tutte le euristiche disponibili a cui è interessato. Le euristiche possono quindi indicizzare un qualsiasi Package per creare un HashPackage.Ad esempio, l'euristica debian ama il file /var/lib/dpkg/status e scopre i pacchetti debian installati, e se non sono stati indicizzati (se non sono stati creati HashPackage per loro), li scarica e li indicizza. Si ottiene un effetto molto piacevole: hashget sarà sempre in grado di deduplicare le distribuzioni Debian in modo efficace, anche se ci sono pacchetti molto recenti.
File di suggerimento (hints)
Se nella tua rete stai usando un tuo pacchetto proprietario o un pacchetto pubblico che non è incluso nelle euristiche di hashget, puoi aggiungere a esso 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" }
{
"project": "wordpress.org",
"url": "https://ru.wordpress.org/wordpress-5.1.1-ru_RU.zip"
}In seguito, ogni volta che si crea un archivio, il pacchetto verrà indicizzato (se non lo è già) e i file del pacchetto verranno deduplicati dall'archivio. Non è necessaria alcuna programmazione, tutto può essere fatto da vim e si può risparmiare in ogni backup. Si noti che, grazie all'approccio basato su checksum, se alcuni file del pacchetto vengono modificati localmente (ad esempio, un file di configurazione modificato), i file modificati verranno mantenuti nell'archivio "così come sono" e non verranno accorciati.
Se un tuo pacchetto personale viene aggiornato periodicamente, ma le modifiche non sono molto significative, puoi fare hint solo per le versioni principali. Ad esempio, nella versione 1.0 è stato fatto un hint con riferimento a mypackage-1.0.tar.gz, e questa verrà completamente deduplicata, poi è stata rilasciata la versione 1.1, che è leggermente diversa, e l'hint non è stato aggiornato. Nessun problema. Verranno deduplicati solo i file che corrispondono (che possono essere ripristinati) con la versione 1.0.
L'euristica che gestisce il file hint è un buon esempio per comprendere il meccanismo interno di funzionamento delle euristiche. Essa elabora solo i file hashget-hint.json (o .hashget-hint.json con il punto) e ignora tutti gli altri. In base a questo file determina quale URL del pacchetto deve essere indicizzato, e hashget lo indicizza (se non è stato fatto precedentemente).
HashServer
Sarebbe piuttosto laborioso eseguire un'indicizzazione completa alla creazione di backup. Per fare ciò, bisognerebbe scaricare ogni pacchetto, decomprimere, indicizzare. Pertanto, hashget utilizza uno schema con . Al rilevamento di un pacchetto debian installato, se non viene trovato in HashPackage locali, si tenta prima di scaricare semplicemente HashPackage dal server hash. Solo se ciò non funziona, hashget scarica e archivia il pacchetto (e lo carica su hashserver, affinché in seguito hashserver lo fornisca).
HashServer non è un elemento obbligatorio nello schema, non è critico, serve solamente per velocizzare e ridurre il carico sui repository. Può essere facilmente disattivato (con l'opzione --hashserver senza parametri). Inoltre, è facile .
Backup incrementali e differenziali, scadenza programmata
permette di creare facilmente uno schema . Perché non indicizzare il nostro stesso backup (con tutti i nostri file unici)? Un'unica comando --submit ed è fatto! Il prossimo backup che creerà hashget non includerà file da questo archivio.
Ma questo non è un approccio molto buono, perché potrebbe capitare che nel ripristino dovremo tirare fuori tutti i backup hashget della nostra storia (se in ognuno ci sarà almeno un file unico). Per questo esiste il meccanismo . Durante l'indicizzazione è possibile specificare la data di scadenza di HashPackage --expires 2019-06-01, e al raggiungimento di tale data (dalle 00:00), non verrà utilizzato. L'archivio stesso può essere mantenuto anche dopo tale data (anche se hashget può facilmente mostrare gli URL di tutti i backup che abbiamo fatto scadere / scadono attualmente o a qualsiasi data).
Ad esempio, se il giorno 1 si esegue un backup completo, e lo si indicizza con un tempo di vita fino alla fine del mese, avremo 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 verrà compresso sia grazie alla compressione dei file dagli backup precedenti (se presenti), sia grazie ai file pubblici (quelli che possono essere scaricati).
Se per qualche motivo non ci fidiamo dell'affidabilità delle risorse debiane () o utilizziamo una distribuzione diversa, possiamo semplicemente eseguire una volta un backup completo con tutti i pacchetti, e poi fare riferimento ad esso (). Ora, se tutti i server delle nostre distribuzioni risultassero non disponibili (nella rete souvenir o in un'apocalisse zombie), ma i nostri backup fossero in ordine, potremmo ripristinarci da qualsiasi breve backup differenziale, basandoci solo sui nostri backup precedenti.
Hashget si basa solo su fonti di ripristino affidabili a QUO TUO giudizio. Quelle che consideri affidabili saranno utilizzate.
FilePool e Glacier
Meccanismo consente di non rivolgersi 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/poolo
$ hashget -u . --pool http://myhashdb.example.com/Per creare un pool in una directory locale, è sufficiente creare una directory e inserire i file, hashget troverà ciò di cui ha bisogno in base ai checksum. Per rendere il pool accessibile tramite HTTP, è necessario creare appositamente dei collegamenti simbolici, il che si fa con un unico comando (hashget-admin --build /var/www/html/hashdb/ --pool /tmp/pool). Il FilePool HTTP è composto da file statici, quindi può essere servito da qualsiasi server web semplice, con un carico quasi nullo sul server.
Grazie a FilePool, come risorse di base si possono utilizzare non solo risorse su http(s), ma anche, , Amazon Glacier.
Dopo aver caricato il backup su Glacier, otteniamo il suo Upload ID 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-01Ora i nuovi backup (differenziali) si baseranno su questo backup e saranno più brevi. Dopo aver estratto il diff_backup con tar, possiamo vedere su quali risorse si basa:
hashget --info /tmp/unpacked/ liste con uno script shell scaricare semplicemente tutti questi file da Glacier nel pool e avviare il ripristino normale: hashget -u /tmp/unpacked --pool /tmp/pool
Ne vale la pena?
Nella situazione più semplice, pagherai semplicemente meno per i backup (se li stai memorizzando da qualche parte nel cloud a pagamento). Potrebbe essere – molto, molto meno.
Ma non è tutto. La quantità si trasforma in qualità. Puoi utilizzare questo per ottenere un miglioramento qualitativo nel tuo schema di backup. Ad esempio, poiché ora i backup sono più brevi, non è necessario farne uno mensile, ma uno giornaliero. Conservarli non per sei mesi come prima, ma per 5 anni. Prima si stava conservando in un archivio "freddo" (Glacier), lento ma economico, ora puoi conservarli in uno caldo, da cui è sempre possibile scaricare rapidamente il backup e ripristinarsi in minuti, invece che in un giorno.
Si può aumentare l'affidabilità della memorizzazione dei backup. Se attualmente li stiamo conservando in un'unica posizione, riducendo il volume dei backup possiamo conservarli in 2-3 archivi e affrontare senza problemi il guasto di uno di essi.
Come provare e iniziare a utilizzare?
Visita la pagina di GitLab , installa con un semplice comando (pip3 install hashget[plugins]) e leggi semplicemente-esegui il quick-start. Penso che implementare le cose semplici richiederà circa 10-15 minuti. Poi puoi provare a comprimere le tue macchine virtuali, creare, se necessario, i file di hint per una compressione più efficace, giocare con i pool, il database locale dei hash e il hashserver, se ti interessa, e il giorno successivo vedere quale sarà la dimensione del backup incrementale rispetto a quello di ieri.
Fonte: habr.com
