Questo articolo prenderà in considerazione il software di backup che, suddividendo il flusso di dati in componenti separati (blocchi), forma un repository.
I componenti del repository possono essere ulteriormente compressi e crittografati e, soprattutto, riutilizzati durante ripetuti processi di backup.
Una copia di backup in un tale repository è una catena denominata di componenti collegati tra loro, ad esempio, sulla base di diverse funzioni hash.
Esistono diverse soluzioni simili, mi concentrerò su 3: zbackup, borgbackup e restic.
Risultati attesi
Poiché tutti i richiedenti richiedono la creazione di un repository in un modo o nell'altro, uno dei fattori più importanti sarà stimare la dimensione del repository. Idealmente, la sua dimensione non dovrebbe essere superiore a 13 GB secondo la metodologia accettata, o anche inferiore, previa buona ottimizzazione.
È anche altamente auspicabile poter creare copie di backup dei file direttamente, senza utilizzare archiviatori come tar, e lavorare con ssh/sftp senza strumenti aggiuntivi come rsync e sshfs.
Comportamento durante la creazione dei backup:
- La dimensione del repository sarà uguale alla dimensione delle modifiche o inferiore.
- Quando si utilizza la compressione e/o la crittografia è previsto un carico elevato della CPU, mentre è probabile un carico della rete e del disco piuttosto elevato se il processo di archiviazione e/o crittografia è in esecuzione su un server di archiviazione di backup.
- Se il repository è danneggiato, è probabile che si verifichi un errore ritardato sia durante la creazione di nuovi backup che durante il tentativo di ripristino. È necessario pianificare misure aggiuntive per garantire l'integrità del repository o utilizzare strumenti integrati per verificarne l'integrità.
Lavorare con tar è preso come valore di riferimento, come mostrato in uno degli articoli precedenti.
Testare zbackup
Il meccanismo generale di zbackup è che il programma trova nel flusso di dati di input aree contenenti gli stessi dati, quindi facoltativamente li comprime e li crittografa, salvando ciascuna area una sola volta.
La deduplicazione utilizza una funzione di hash ad anello a 64 bit con una finestra scorrevole per verificare le corrispondenze byte per byte con i blocchi di dati esistenti (simile a come la implementa rsync).
Lzma e lzo multi-thread vengono utilizzati per la compressione e aes per la crittografia. Le ultime versioni hanno la possibilità di eliminare in futuro i vecchi dati dal repository.
Il programma è scritto in C++ con dipendenze minime. L'autore è stato apparentemente ispirato da unix-way, quindi il programma accetta i dati su stdin durante la creazione dei backup, producendo un flusso di dati simile su stdout durante il ripristino. Pertanto, zbackup può essere utilizzato come un ottimo “mattone” quando si scrivono le proprie soluzioni di backup. Ad esempio, l'autore dell'articolo utilizza questo programma come principale strumento di backup per i computer domestici dal 2014 circa.
Il flusso di dati sarà un normale tar se non diversamente specificato.
Vediamo quali sono i risultati:
Il lavoro è stato controllato in 2 opzioni:
- viene creato un repository e zbackup viene avviato sul server con i dati di origine, quindi il contenuto del repository viene trasferito al server di archiviazione di backup.
- viene creato un repository sul server di archiviazione di backup, zbackup viene avviato tramite ssh sul server di archiviazione di backup e i dati vengono inviati ad esso tramite pipe.
I risultati della prima opzione erano i seguenti: 43m11s - quando si utilizza un repository non crittografato e il compressore lzma, 19m13s - quando si sostituisce il compressore con lzo.
Il carico sul server con i dati originali era il seguente (viene mostrato un esempio con lzma; con lzo c'era più o meno la stessa immagine, ma la quota di rsync era circa un quarto del tempo):
È chiaro che un simile processo di backup è adatto solo per modifiche relativamente rare e piccole. È inoltre altamente consigliabile limitare zbackup a 1 thread, altrimenti il carico della CPU sarà molto elevato, perché Il programma è molto bravo a lavorare in più thread. Il carico sul disco era ridotto, il che in generale non sarebbe evidente con un moderno sottosistema di dischi basato su SSD. Puoi anche vedere chiaramente l'inizio del processo di sincronizzazione dei dati del repository su un server remoto; la velocità di funzionamento è paragonabile al normale rsync e dipende dalle prestazioni del sottosistema disco del server di archiviazione di backup. Lo svantaggio di questo approccio è l'archiviazione di un repository locale e, di conseguenza, la duplicazione dei dati.
Più interessante e applicabile nella pratica è la seconda opzione, che esegue zbackup direttamente sul server di archiviazione di backup.
Per prima cosa testeremo l'operazione senza utilizzare la crittografia con il compressore lzma:
Tempo di esecuzione di ogni esecuzione di prova:
Lancio 1
Lancio 2
Lancio 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Se abiliti la crittografia utilizzando aes, i risultati sono abbastanza vicini:
Tempo di funzionamento sugli stessi dati, con crittografia:
Lancio 1
Lancio 2
Lancio 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Se la crittografia è combinata con la compressione utilizzando lzo, appare così:
Tempo di esecuzione:
Lancio 1
Lancio 2
Lancio 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
La dimensione del repository risultante era relativamente la stessa: 13 GB. Ciò significa che la deduplica funziona correttamente. Inoltre, su dati già compressi, l'uso di lzo dà un effetto notevole; in termini di tempo operativo totale, zbackup si avvicina a duplicity/duplicati, ma resta indietro di 2-5 volte rispetto a quelli basati su librsync.
I vantaggi sono evidenti: risparmio di spazio su disco sul server di archiviazione di backup. Per quanto riguarda gli strumenti di controllo del repository, l'autore di zbackup non li fornisce; si consiglia di utilizzare un array di dischi o un provider cloud con tolleranza agli errori.
Nel complesso un'ottima impressione, nonostante il progetto sia fermo da circa 3 anni (l'ultima richiesta di funzionalità risale a circa un anno fa, ma senza risposta).
Testare borgbackup
Borgbackup è un fork di Attic, un altro sistema simile a zbackup. Scritto in Python, ha un elenco di funzionalità simili a zbackup, ma in più può:
- Montare i backup tramite fusibile
- Controlla il contenuto del repository
- Lavora in modalità client-server
- Utilizza vari compressori per i dati, nonché la determinazione euristica del tipo di file durante la compressione.
- 2 opzioni di crittografia, aes e blake
- Strumento integrato per
controlli delle prestazioni
benchmark borgbackup crud ssh://backup_server/repo/path local_dir
I risultati sono stati i seguenti:
CZ-BIG 96.51 MB/s (10 File tutti zero da 100.00 MB: 10.36 s)
RZ-BIG 57.22 MB/s (10 File tutti zero da 100.00 MB: 17.48 s)
UZ-BIG 253.63 MB/s (10 File tutti zero da 100.00 MB: 3.94 s)
DZ-BIG 351.06 MB/s (10 File tutti zero da 100.00 MB: 2.85 s)
CR-BIG 34.30 MB/s (10 File casuali da 100.00 MB: 29.15 s)
RR-BIG 60.69 MB/s (10 File casuali da 100.00 MB: 16.48 s)
UR-BIG 311.06 MB/s (10 File casuali da 100.00 MB: 3.21 s)
DR-BIG 72.63 MB/s (10 File casuali da 100.00 MB: 13.77 s)
CZ-MEDIO 108.59 MB/s (1000 File tutti zero da 1.00 MB: 9.21 s)
RZ-MEDIO 76.16 MB/s (1000 File tutti zero da 1.00 MB: 13.13 s)
UZ-MEDIO 331.27 MB/s (1000 File tutti zero da 1.00 MB: 3.02 s)
DZ-MEDIO 387.36 MB/s (1000 File tutti zero da 1.00 MB: 2.58 s)
CR-MEDIO 37.80 MB/s (1000 File casuali da 1.00 MB: 26.45 s)
RR-MEDIO 68.90 MB/s (1000 File casuali da 1.00 MB: 14.51 s)
UR-MEDIO 347.24 MB/s (1000 File casuali da 1.00 MB: 2.88 s)
DR-MEDIO 48.80 MB/s (1000 File casuali da 1.00 MB: 20.49 s)
CZ-PICCOLO 11.72 MB/s (10000 File da 10.00 kB tutti zero: 8.53 s)
RZ-PICCOLO 32.57 MB/s (10000 File da 10.00 kB tutti zero: 3.07 s)
UZ-PICCOLO 19.37 MB/s (10000 File da 10.00 kB tutti zero: 5.16 s)
DZ-PICCOLO 33.71 MB/s (10000 File da 10.00 kB tutti zero: 2.97 s)
CR-PICCOLO 6.85 MB/s (10000 File casuali da 10.00 kB: 14.60 s)
RR-PICCOLO 31.27 MB/s (10000 File casuali da 10.00 kB: 3.20 s)
UR-PICCOLO 12.28 MB/s (10000 File casuali da 10.00 kB: 8.14 s)
DR-PICCOLO 18.78 MB/s (10000 File casuali da 10.00 kB: 5.32 s)
Durante il test, verrà utilizzata l'euristica di compressione per determinare il tipo di file (compressione automatica) e i risultati saranno i seguenti:
Innanzitutto, controlliamo come funziona senza crittografia:
Tempo di esecuzione:
Lancio 1
Lancio 2
Lancio 3
4m6s
4m10s
4m5s
56 secondi
58 secondi
54 secondi
1m26s
1m34s
1m30s
Se abiliti l'autorizzazione del repository (modalità autenticata), i risultati saranno vicini:
Tempo di esecuzione:
Lancio 1
Lancio 2
Lancio 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Quando è stata attivata la crittografia aes, i risultati non sono peggiorati molto:
Lancio 1
Lancio 2
Lancio 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
E se cambi ae in Blake, la situazione migliorerà completamente:
Tempo di esecuzione:
Lancio 1
Lancio 2
Lancio 3
4m33s
4m43s
4m40s
59 secondi
1m0s
1m0s
1m38s
1m43s
1m40s
Come nel caso di zbackup, la dimensione del repository era di 13 GB e anche leggermente inferiore, come generalmente previsto. Sono rimasto molto soddisfatto della durata di esecuzione; è paragonabile a soluzioni basate su librsync, fornendo funzionalità molto più ampie. Sono rimasto soddisfatto anche dalla possibilità di impostare vari parametri tramite variabili d'ambiente, il che offre un vantaggio molto serio quando si utilizza borgbackup in modalità automatica. Sono rimasto soddisfatto anche del carico durante il backup: a giudicare dal carico del processore, borgbackup funziona in 1 thread.
Non ci sono stati particolari svantaggi durante l'utilizzo.
test resto
Nonostante il fatto che Restic sia una soluzione abbastanza nuova (i primi 2 candidati erano conosciuti nel 2013 e prima), ha caratteristiche abbastanza buone. Scritto in Go.
Rispetto a zbackup, offre inoltre:
- Controllare l'integrità del repository (incluso il check-in di parti).
- Un vasto elenco di protocolli e provider supportati per l'archiviazione dei backup, nonché il supporto per rclone - rsync per soluzioni cloud.
- Confronto di 2 backup tra loro.
- Montaggio del repository tramite fusibile.
In generale, l'elenco delle funzionalità è abbastanza vicino a borgbackup, in alcuni punti di più, in altri meno. Una delle caratteristiche è che non è possibile disabilitare la crittografia e pertanto le copie di backup verranno sempre crittografate. Vediamo in pratica cosa si può spremere da questo software:
I risultati sono stati i seguenti:
Tempo di esecuzione:
Lancio 1
Lancio 2
Lancio 3
5m25s
5m50s
5m38s
35 secondi
38 secondi
36 secondi
1m54s
2m2s
1m58s
Anche i risultati in termini di prestazioni sono paragonabili a soluzioni basate su rsync e, in generale, molto vicini a borgbackup, ma il carico della CPU è maggiore (più thread in esecuzione) e a dente di sega.
Molto probabilmente il programma è limitato dalle prestazioni del sottosistema disco sul server di archiviazione dati, come già accadeva con rsync. La dimensione del repository era di 13 GB, proprio come zbackup o borgbackup, non c'erano svantaggi evidenti nell'utilizzo di questa soluzione.
Giudizio
In effetti, tutti i candidati hanno ottenuto risultati simili, ma a prezzi diversi. Borgbackup ha funzionato meglio di tutti, restic è stato un po' più lento, probabilmente non vale la pena iniziare a usare zbackup,
e se è già in uso, prova a cambiarlo in borgbackup o restic.
risultati
La soluzione più promettente sembra essere riposante, perché... è lui che ha il miglior rapporto tra capacità e velocità operativa, ma per ora non affrettiamoci a conclusioni generali.
Borgbackup sostanzialmente non è peggiore, ma zbackup probabilmente è meglio sostituito. È vero, zbackup può ancora essere utilizzato per garantire il funzionamento della regola 3-2-1. Ad esempio, oltre alle funzionalità di backup basate su (lib)rsync.
annuncio
Backup Parte 5: Testare il backup di bacula e veeam per linux
Backup Parte 6: Confronto degli strumenti di backup
Backup Parte 7: Conclusioni
Pubblicato da: Pavel Demkovich
Fonte: habr.com