In questo articolo esamineremo gli strumenti software per il backup che, suddividendo il flusso di dati in componenti distinti (chunks), creano un repository.
I componenti del repository possono essere ulteriormente compressi e cifrati, e soprattutto, durante i processi di backup successivi, possono essere riutilizzati.
Un backup in un repository simile è una catena nominata di componenti correlati, ad esempio, basata su diverse funzioni di hash.
Ci sono diverse soluzioni simili, mi soffermerò 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 della dimensione del repository. In un caso ideale, la sua dimensione non dovrebbe superare i 13 GB secondo la metodologia adottata, o addirittura essere inferiore, a condizione di una buona ottimizzazione.
È molto utile avere la possibilità di creare backup dei file direttamente, senza l'uso di archiviatori come tar, e di lavorare con ssh/sftp senza strumenti aggiuntivi come rsync e sshfs.
Comportamento durante la creazione dei backup:
- La dimensione del repository sarà equivalente alla dimensione delle modifiche, o inferiore.
- È prevista un'alta pressione sulla CPU quando si utilizza la compressione e/o la crittografia, e ci si aspetta un carico significativo anche sulla rete e sul sistema di archiviazione, se il processo di archiviazione e/o crittografia avviene sul server dei backup.
- Se il repository viene danneggiato, è probabile che si verifichino errori ritardati sia durante la creazione di nuovi backup che nel tentativo di ripristino. È necessario pianificare ulteriori misure per garantire l'integrità del repository o utilizzare strumenti integrati per verificarne l'integrità.
Come valore di riferimento, è stata utilizzata l'operazione con tar, come dimostrato in uno dei precedenti articoli.
Test di zbackup
Il meccanismo generale di funzionamento di zbackup consiste nel trovare nel flusso di dati in ingresso aree contenenti dati identici, così da compattarle, crittografarle e conservarle ciascuna una sola volta.
Per la deduplicazione viene utilizzata una funzione hash circolare a 64 bit con finestra mobile per il confronto byte per byte con i blocchi di dati esistenti (simile a quanto implementato in rsync).
Per la compressione si utilizzano lzma e lzo in esecuzione multithreading, mentre per la crittografia si utilizza aes. Nelle versioni più recenti è presente la possibilità di eliminare in futuro i dati obsoleti dal repository.
Il programma è scritto in C++ con dipendenze minime. L'autore sembra essere stato ispirato dal 'unix-way', quindi il programma accetta dati su stdin durante la creazione dei backup, restituendo un flusso di dati analogo su stdout durante il ripristino. Pertanto, zbackup può essere utilizzato come un utile mattone per scrivere soluzioni di backup personalizzate. Ad esempio, per l’autore di questo articolo, questo programma è lo strumento principale di backup per i computer domestici dal 2014.
Come flusso di dati verrà utilizzato il comune tar, salvo indicazioni contrarie.
Vediamo quali saranno i risultati:
Il test è stato eseguito in 2 modalità:
- si crea un repository e si avvia zbackup sul server con i dati originali, poi il contenuto del repository viene trasferito sul server di archiviazione dei backup.
- si crea un repository sul server di archiviazione dei backup, si avvia zbackup tramite ssh sul server di archiviazione, passando i dati tramite pipe.
I risultati della prima modalità sono stati: 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 (incluso un esempio con lzma; con lzo era simile, ma la parte di rsync era circa un quarto del tempo):
È chiaro che un processo di backup del genere è adatto solo per modifiche relativamente rare e ridotte. È anche fortemente consigliato limitare l'operazione di zbackup a un solo thread, altrimenti si avrà un carico CPU piuttosto elevato, dato che il programma lavora molto bene in più thread. Il carico sul disco è stato ridotto, il che in generale non sarà percepito con i moderni sistemi di archiviazione basati su SSD. È evidente inoltre il lancio del processo di sincronizzazione dei dati del repository su un server remoto, e la velocità è comparabile a quella del normale rsync, limitandosi quindi alle prestazioni del sistema di archiviazione dei backup. Uno svantaggio di questo approccio è la conservazione del repository locale e, di conseguenza, la duplicazione dei dati.
Un'opzione più interessante e praticabile è la seconda, che prevede l'esecuzione di zbackup direttamente sul server di archiviazione dei backup.
Per iniziare, verrà verificato il funzionamento senza l'uso della crittografia con il compressore lzma:
Tempo di esecuzione di ciascun avvio di prova:
Avvio 1
Avvio 2
Avvio 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Se si attiva la crittografia utilizzando aes, i risultati sono abbastanza simili:
Tempo di lavoro con gli 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 lzo, otteniamo:
Tempo di lavoro:
Avvio 1
Avvio 2
Avvio 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
La dimensione del repository risultante è stata relativamente costante ed è stata di 13 GB. Questo significa che la deduplicazione funziona correttamente. Inoltre, sull'archiviazione già compressa, l'applicazione di lzo offre un effetto significativo, avvicinando il tempo totale di esecuzione di zbackup a quello di duplicity/duplicati, anche se rimane indietro rispetto a quelli basati su librsync di 2-5 volte.
I vantaggi sono evidenti: risparmio di spazio su disco nel server di archiviazione dei backup. Per quanto riguarda gli strumenti di verifica del repository, l'autore di zbackup non li ha previsti, si consiglia di utilizzare un array di dischi ridondanti o un provider cloud.
In generale, una buona impressione, nonostante il fatto che il progetto sia fermo da circa 3 anni (l'ultima richiesta di funzionalità risale a circa un anno fa, ma senza risposta).
Test di borgbackup
Borgbackup è un fork di attic, un altro sistema simile a zbackup. Scritto in Python, ha un elenco di funzionalità simili a quelle di zbackup, ma offre anche:
- Montaggio dei backup tramite fuse
- Verifica del contenuto del repository
- Funzionamento in modalità client-server
- Utilizzo di diversi compressori per i dati, oltre alla determinazione euristica del tipo di file durante la compressione.
- 2 opzioni di crittografia, aes e blake
- Strumento integrato per
verificare le prestazioni
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
I risultati ottenuti sono stati i seguenti:
C-Z-BIG 96,51 MB/s (10 100,00 MB file tutti zeri: 10,36s)
R-Z-BIG 57,22 MB/s (10 100,00 MB file tutti zeri: 17,48s)
U-Z-BIG 253,63 MB/s (10 100,00 MB file tutti zeri: 3,94s)
D-Z-BIG 351,06 MB/s (10 100,00 MB file tutti zeri: 2,85s)
C-R-BIG 34,30 MB/s (10 100,00 MB file casuali: 29,15s)
R-R-BIG 60,69 MB/s (10 100,00 MB file casuali: 16,48s)
U-R-BIG 311,06 MB/s (10 100,00 MB file casuali: 3,21s)
D-R-BIG 72,63 MB/s (10 100,00 MB file casuali: 13,77s)
C-Z-MEDIUM 108,59 MB/s (1000 1,00 MB file tutti zeri: 9,21s)
R-Z-MEDIUM 76,16 MB/s (1000 1,00 MB file tutti zeri: 13,13s)
U-Z-MEDIUM 331,27 MB/s (1000 1,00 MB file tutti zeri: 3,02s)
D-Z-MEDIUM 387,36 MB/s (1000 1,00 MB file tutti zeri: 2,58s)
C-R-MEDIUM 37,80 MB/s (1000 1,00 MB file casuali: 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 zeri: 8,53s)
R-Z-SMALL 32,57 MB/s (10000 10,00 kB file tutti zeri: 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 verrà utilizzata l'euristica per la compressione con determinazione del tipo di file (compressione automatica), e i risultati saranno i seguenti:
Per iniziare, controlliamo il funzionamento senza crittografia:
Tempo di lavoro:
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 lavoro:
Avvio 1
Avvio 2
Avvio 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Attivando la crittografia aes, i risultati non sono peggiorati troppo:
Avvio 1
Avvio 2
Avvio 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
E se sostituiamo aes con blake, la situazione migliora notevolmente:
Tempo di lavoro:
Avvio 1
Avvio 2
Avvio 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Come per zbackup, la dimensione del repository è stata di 13 GB, leggermente inferiore, il che è fondamentalmente previsto. È stata una piacevole sorpresa il tempo di operazione, paragonabile alle soluzioni basate su librsync, offrendo possibilità molto più ampie. Anche la possibilità di impostare vari parametri tramite variabili ambientali è stata apprezzata, poiché conferisce un vantaggio significativo nell'uso di borgbackup in modalità automatica. Inoltre, è stata positiva la leggera carico durante il backup: a giudicare dal carico della CPU, borgbackup funziona in un singolo thread.
Non sono emerse particolari criticità nell'utilizzo.
Test di restic
Nonostante restic sia una soluzione relativamente nuova (i primi 2 candidati erano già noti dal 2013 o precedenti), presenta caratteristiche piuttosto buone. È scritto in Go.
Rispetto a zbackup, offre in aggiunta:
- Controllo dell'integrità del repository (incluso il controllo per sezioni).
- Un ampio elenco di protocolli e fornitori supportati per il salvataggio delle copie di sicurezza, oltre al supporto per rclone - rsync per soluzioni "cloud".
- Confronto di 2 backup fra loro.
- Montaggio del repository tramite fuse.
In generale, l'elenco delle funzionalità è abbastanza simile a borgbackup, a tratti di più, a tratti di meno. Tra le peculiarità c'è l'impossibilità di disattivare la crittografia, quindi i backup saranno sempre crittografati. Vediamo in pratica cosa si può ottenere da questo software:
I risultati sono i seguenti:
Tempo di lavoro:
Avvio 1
Avvio 2
Avvio 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
I risultati ottenuti sono comparabili con soluzioni basate su rsync e, in generale, molto vicini a borgbackup, ma l'impatto sulla CPU è più elevato (funziona con più thread) e presenta un carico a picchi.
È probabile che il programma si incespichi nelle prestazioni del sottosistema di archiviazione sul server, come già accaduto con rsync. La dimensione del repository è stata di 13 GB, come zbackup o borgbackup; non sono stati riscontrati svantaggi evidenti nell'uso di questa soluzione.
Risultati
Alla fine, tutti i candidati hanno mostrato risultati simili, ma a prezzi diversi. Borgbackup ha raggiunto le migliori prestazioni, mentre restic è stato leggermente più lento; probabilmente non vale la pena iniziare a utilizzare zbackup,
e se è già in uso, provare a passare a borgbackup o restic.
Conclusioni
La soluzione più promettente sembra essere restic, in quanto offre il miglior rapporto tra funzionalità e velocità operativa, ma per ora evitiamo di affrettare conclusioni generali.
Borgbackup in realtà non è inferiore, mentre zbackup potrebbe essere sostituito. Tuttavia, per garantire il rispetto della regola 3-2-1, zbackup può ancora essere utilizzato. Ad esempio, oltre agli strumenti di backup basati su (lib)rsync.
Annuncio
Backup, parte 5: Test di bacula e veeam backup per linux
Backup, parte 6: Confronto degli strumenti di backup
Backup, parte 7: Conclusioni
Autore della pubblicazione: Pavel Demkovich
Fonte: habr.com
