In questo articolo verranno considerati gli strumenti software per il backup, che, suddividendo il flusso di dati in componenti separate (chunks), formano un repository.
I componenti del repository possono essere ulteriormente compressi e crittografati, e la cosa più importante è che, durante i processi di backup successivi, possano essere riutilizzati.
Un backup in un simile repository è una catena nominata di componenti correlati tra loro, ad esempio, basata su diverse funzioni hash.
Esistono diverse soluzioni simili, mi concentrerò su 3: zbackup, borgbackup e restic.
Risultati attesi
Poiché tutti i candidati richiedono in un modo o nell'altro la creazione di un repository, uno dei fattori più importanti sarà la valutazione delle dimensioni del repository. Idealmente, la sua dimensione non dovrebbe superare i 13 GB secondo la metodologia accettata, e ancor meno — a condizione di una buona ottimizzazione.
Inoltre, è estremamente desiderabile avere la possibilità di creare backup di file direttamente, senza l'uso di archivi come tar, e gestire ssh/sftp senza strumenti aggiuntivi come rsync e sshfs.
Comportamento nella creazione dei backup:
- La dimensione del repository sarà pari alla dimensione delle modifiche, o minore.
- Ci si aspetta un carico maggiore sulla CPU durante l'uso della compressione e/o della crittografia, e potrebbe esserci un carico piuttosto elevato sulla rete e sul sottosistema di memorizzazione, se il processo di archiviazione e/o crittografia avviene sul server di archiviazione dei backup.
- Se il repository viene danneggiato, si potrebbe verificare un errore ritardato sia durante la creazione di nuovi backup, sia durante il tentativo di ripristino. È necessario pianificare misure aggiuntive per garantire l'integrità del repository o utilizzare strumenti integrati di verifica della sua integrità.
Un valore di riferimento è considerato il lavoro con tar, come mostrato in uno degli articoli precedenti.
Test del zbackup
Il meccanismo generale di funzionamento di zbackup consiste nel fatto che il programma individua nel flusso di dati fornito in ingresso aree contenenti dati identici, poi le comprime e le crittografa opzionalmente, mantenendo ogni area solo una volta.
Per la deduplicazione viene utilizzata una funzione hash circolare a 64 bit con una finestra scorrevole per il confronto byte per byte con i blocchi di dati già esistenti (in modo simile a quanto realizzato in rsync).
Per la compressione vengono utilizzati lzma e lzo in esecuzione multithread, mentre per la crittografia - aes. Nelle ultime versioni è presente la possibilità di eliminare in futuro i vecchi dati dal repository.
Il programma è scritto in C++ con dipendenze minime. L'autore sembra essersi ispirato al unix-way, quindi il programma accetta dati su stdin durante la creazione dei backup, restituendo un flusso di dati simile su stdout durante il ripristino. In questo modo, zbackup può essere utilizzato come un ottimo "mattoncino" per scrivere soluzioni di backup personalizzate. Ad esempio, per l'autore dell'articolo, questo programma è il principale strumento di backup per i computer domestici dal 2014.
Come flusso di dati verrà utilizzato un normale tar, se non diversamente specificato.
Vediamo quali saranno i risultati:
Il test è stato eseguito in 2 varianti:
- si crea un repository e si avvia zbackup su un server con i dati originali, poi il contenuto del repository viene trasferito su un server di archiviazione dei backup.
- si crea un repository su un server di archiviazione dei backup, si avvia zbackup tramite ssh sul server di archiviazione dei backup e i dati vengono forniti tramite pipe.
I risultati del primo caso sono stati i seguenti: 43m11s - utilizzando un repository non crittografato e il compressore lzma, 19m13s - sostituendo il compressore con lzo.
Il carico sul server con i dati originali è stato il seguente (mostrata un esempio con lzma, con lzo è stata ottenuta un'immagine simile, ma la quota di rsync è stata circa un quarto del tempo):
È chiaro che un simile processo di backup è adatto solo per modifiche relativamente rare e di piccole dimensioni. È anche estremamente consigliabile limitare l'operazione di zbackup a 1 thread, altrimenti ci sarà un carico elevato sulla CPU, poiché il programma riesce a lavorare molto bene in più thread. Il carico sul disco è stato modesto, il che, in generale, con i moderni sistemi di archiviazione basati su SSD, sarà impercettibile. È anche evidente l'avvio del processo di sincronizzazione dei dati del repository sul server remoto, la velocità di lavoro è paragonabile a quella del normale rsync e dipende dalla performance del sistema di archiviazione del server di backup. Un punto negativo dell'approccio è la conservazione del repository locale e, di conseguenza, la duplicazione dei dati.
Risulta più interessante e pratico il secondo opzione con avvio di zbackup direttamente sul server di archiviazione dei backup.
Per cominciare, verrà controllato il funzionamento senza crittografia con il compressore lzma:
Tempo di esecuzione di ciascun avvio di test:
Avvio 1
Avvio 2
Avvio 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Se si attiva la crittografia usando aes, i risultati sono abbastanza simili:
Tempo di esecuzione sugli stessi dati, con crittografia:
Avvio 1
Avvio 2
Avvio 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Se si combina la crittografia con la compressione su lzo, i risultati sono:
Tempo di esecuzione:
Avvio 1
Avvio 2
Avvio 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
La dimensione del repository risultante era relativamente uniforme e pari a 13 GB. Questo significa che la deduplicazione funziona correttamente. Inoltre, sull'insieme di dati già compressi, l’applicazione di lzo produce un effetto tangibile: il tempo totale di esecuzione di zbackup si avvicina a quello di duplicity/duplicati, pur rimanendo in ritardo rispetto a soluzioni basate su librsync di 2-5 volte.
I vantaggi sono evidenti: risparmio di spazio su disco sul server di archiviazione dei backup. Per quanto riguarda gli strumenti di verifica del repository, l'autore di zbackup non li prevede, si consiglia di utilizzare un array di dischi ridondanti o un fornitore cloud.
In generale, un’impressione abbastanza positiva, nonostante il progetto sia fermo da circa 3 anni (l'ultima richiesta di funzionalità è stata inoltrata circa un anno fa, ma senza risposta).
Testing di borgbackup
Borgbackup è un fork di attic, un'altra sistemazione simile a zbackup. Scritto in python, ha un elenco di funzionalità simile a zbackup, ma in aggiunta può:
- Montare i backup tramite fuse
- Controllare il contenuto del repository
- Funzionare in modalità client-server
- Utilizzare diversi compressori per i dati, nonché definire in modo euristico il tipo di file durante la sua compressione.
- 2 opzioni di crittografia, aes e blake
- Strumento integrato per
verifica delle prestazioni
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
I risultati sono stati i seguenti:
C-Z-BIG 96.51 MB/s (10 100.00 MB file all-zero: 10.36s)
R-Z-BIG 57.22 MB/s (10 100.00 MB file all-zero: 17.48s)
U-Z-BIG 253.63 MB/s (10 100.00 MB file all-zero: 3.94s)
D-Z-BIG 351.06 MB/s (10 100.00 MB file all-zero: 2.85s)
C-R-BIG 34.30 MB/s (10 100.00 MB file random: 29.15s)
R-R-BIG 60.69 MB/s (10 100.00 MB file random: 16.48s)
U-R-BIG 311.06 MB/s (10 100.00 MB file random: 3.21s)
D-R-BIG 72.63 MB/s (10 100.00 MB file random: 13.77s)
C-Z-MEDIUM 108.59 MB/s (1000 1.00 MB file all-zero: 9.21s)
R-Z-MEDIUM 76.16 MB/s (1000 1.00 MB file all-zero: 13.13s)
U-Z-MEDIUM 331.27 MB/s (1000 1.00 MB file all-zero: 3.02s)
D-Z-MEDIUM 387.36 MB/s (1000 1.00 MB file all-zero: 2.58s)
C-R-MEDIUM 37.80 MB/s (1000 1.00 MB file random: 26.45s)
R-R-MEDIUM 68.90 MB/s (1000 1.00 MB file casuali: 14.51s)
U-R-MEDIUM 347.24 MB/s (1000 1.00 MB file casuali: 2.88s)
D-R-MEDIUM 48.80 MB/s (1000 1.00 MB file casuali: 20.49s)
C-Z-SMALL 11.72 MB/s (10000 10.00 kB file tutti zero: 8.53s)
R-Z-SMALL 32.57 MB/s (10000 10.00 kB file tutti zero: 3.07s)
U-Z-SMALL 19.37 MB/s (10000 10.00 kB file tutti zero: 5.16s)
D-Z-SMALL 33.71 MB/s (10000 10.00 kB file tutti zero: 2.97s)
C-R-SMALL 6.85 MB/s (10000 10.00 kB file casuali: 14.60s)
R-R-SMALL 31.27 MB/s (10000 10.00 kB file casuali: 3.20s)
U-R-SMALL 12.28 MB/s (10000 10.00 kB file casuali: 8.14s)
D-R-SMALL 18.78 MB/s (10000 10.00 kB file casuali: 5.32s)
Durante il test sarà utilizzata un'euristica nella compressione con determinazione del tipo di file (compressione automatica), e i risultati saranno i seguenti:
Per iniziare, controlliamo il funzionamento senza crittografia:
Tempo di esecuzione:
Avvio 1
Avvio 2
Avvio 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Se attiviamo l'autenticazione del repository (modalità autenticata), i risultati saranno simili:
Tempo di esecuzione:
Avvio 1
Avvio 2
Avvio 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Con l'attivazione della crittografia aes, i risultati non sono peggiorati molto:
Avvio 1
Avvio 2
Avvio 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Ma se sostituiamo aes con blake, la situazione migliorerà notevolmente:
Tempo di esecuzione:
Avvio 1
Avvio 2
Avvio 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Come nel caso di zbackup, la dimensione del repository è stata di 13 GB e anche un po' meno, il che è, in generale, prevedibile. È stato molto incoraggiante il tempo di esecuzione, comparabile con soluzioni basate su librsync, offrendo molte più possibilità. Anche la possibilità di impostare vari parametri tramite variabili d'ambiente è stata molto apprezzata, fornendo un vantaggio considerevole nell'utilizzo di borgbackup in modalità automatica. Inoltre, è stata apprezzata la carico durante il backup: considerando il carico della CPU, borgbackup opera in un solo thread.
Non sono stati riscontrati particolari svantaggi nell'uso.
Test del restic
Nonostante sia una soluzione relativamente nuova (i primi 2 candidati erano noti già dal 2013 e antecedenti), ha caratteristiche piuttosto buone. È scritto in Go.
Se confrontato con zbackup, offre anche:
- Controllo dell'integrità del repository (incluso il controllo per parti).
- Un enorme elenco di protocolli e fornitori supportati per l'archiviazione dei backup, oltre al supporto di rclone — rsync per soluzioni 'cloud'.
- Confronto tra 2 backup.
- Montaggio del repository tramite fuse.
In generale, l'elenco delle capacità è abbastanza simile a borgbackup, a volte maggiore, a volte minore. Tra le peculiarità c'è l'assenza della possibilità di disattivare la crittografia, il che significa che i backup saranno sempre crittografati. Vediamo nella pratica cosa si può ottenere da questo software:
I risultati sono i seguenti:
Tempo di esecuzione:
Avvio 1
Avvio 2
Avvio 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
I risultati del lavoro sono anche paragonabili alle soluzioni basate su rsync e, in generale, molto vicini a borgbackup, ma il carico sulla CPU è più alto (funzionano più thread) e presenta delle fluttuazioni.
Probabilmente, il programma è limitato dalle prestazioni del sistema di archiviazione del server, come è già accaduto con rsync. Le dimensioni del repository sono state di 13 GB, come in zbackup o borgbackup, senza evidenti svantaggi nell'utilizzo di questa soluzione.
Risultati
In effetti, tutti i candidati hanno mostrato risultati simili, ma con costi diversi. Borgbackup ha mostrato la migliore performance, seguito da restic, mentre zbackup probabilmente non vale la pena di utilizzarlo,
e se viene già utilizzato, è consigliabile provare a passare a borgbackup o restic.
Conclusioni
La soluzione più promettente sembra essere restic, poiché ha il miglior rapporto tra funzionalità e velocità di esecuzione, ma per ora evitiamo di trarre conclusioni affrettate.
Borgbackup in generale non è inferiore, mentre zbackup sarebbe meglio sostituirlo. Tuttavia, per garantire l'applicazione della regola 3-2-1, zbackup può ancora essere utilizzato. Ad esempio, come supporto per strumenti di backup basati su (lib)rsync.
Annuncio
Backup, parte 5: Test di Bacula e Veeam Backup for Linux
Backup, parte 6: Confronto degli strumenti di backup
Backup, parte 7: Conclusioni
Autore della pubblicazione: Pavel Demkovich
Fonte: habr.com
