Questu articulu hà da cunsiderà un software di salvezza chì, rompendu u flussu di dati in cumpunenti separati (pezzi), forma un repository.
I cumpunenti di u repositoriu ponu esse più cumpressi è criptati, è più importantemente - durante i prucessi di salvezza ripetuti - reutilizati.
Una copia di salvezza in un tali repository hè una catena chjamata di cumpunenti cunnessi l'un à l'altru, per esempiu, basatu annantu à diverse funzioni di hash.
Ci sò parechje suluzioni simili, mi cuncintraraghju nantu à 3: zbackup, borgbackup è restic.
Risultati previsti
Siccomu tutti i candidati necessitanu a creazione di un repository in un modu o un altru, unu di i fatturi più impurtanti serà a stima di a dimensione di u repository. Ideale, a so dimensione ùn deve esse più di 13 GB secondu a metodulugia accettata, o ancu menu - sottumessu à una bona ottimisazione.
Hè ancu assai desideratu di pudè creà copie di salvezza di i fugliali direttamente, senza aduprà archivi cum'è tar, è ancu travaglià cù ssh / sftp senza strumenti supplementari cum'è rsync è sshfs.
Cumportamentu quandu creanu backups:
- A dimensione di u repositoriu serà uguali à a dimensione di i cambiamenti, o menu.
- Una carica di CPU pesante hè prevista quandu si usa compressione è / o criptografia, è una carica abbastanza alta di rete è di discu hè prubabile se u prucessu di archiviazione è / o di criptografia hè in esecuzione in un servitore di salvezza di salvezza.
- Se u repositoriu hè dannatu, un errore ritardatu hè prubabile sia quandu creanu novi backups è quandu pruvate di restaurà. Hè necessariu di pianificà e misure supplementari per assicurà l'integrità di u repositoriu o aduprà strumenti integrati per verificà a so integrità.
U travagliu cù u tar hè pigliatu cum'è un valore di riferimentu, cum'è hè statu dimustratu in unu di l'articuli previ.
Pruvate zbackup
U mekanismu generale di zbackup hè chì u prugramma trova in l'area di flussu di dati di input chì cuntenenu i stessi dati, poi opzionalmente comprime è cripta, salvendu ogni area solu una volta.
A deduplicazione usa una funzione di hash di 64 bit cù una finestra scorrevule per verificà e partite byte per byte contr'à i blocchi di dati esistenti (simile à cumu rsync l'implementa).
Lzma è lzo multi-threaded sò usati per a compressione, è aes per a criptografia. L'ultime versioni anu a capacità di sguassà vechji dati da u repository in u futuru.
U prugramma hè scrittu in C ++ cù dipendenze minimu. L'autore era apparentemente inspiratu da u modu Unix, cusì u prugramma accetta dati nantu à stdin quandu crea copia di salvezza, pruducia un flussu di dati simili nantu à stdout quandu restaurà. Cusì, zbackup pò esse usatu cum'è un "bloccu di custruzzione" assai bonu quandu scrive u vostru propiu suluzione di salvezza. Per esempiu, l'autore di l'articulu hà utilizatu stu prugramma cum'è u principale strumentu di salvezza per e macchine di casa da circa 2014.
U flussu di dati serà un tar regulare, salvu s'ellu ùn hè micca dettu altrimenti.
Videmu quali sò i risultati:
U travagliu hè statu verificatu in 2 opzioni:
- un repository hè creatu è zbackup hè lanciatu nantu à u servitore cù i dati fonte, allora u cuntenutu di u repository hè trasferitu à u servitore di salvezza di salvezza.
- un repository hè creatu nantu à u servitore di salvezza di salvezza, zbackup hè lanciatu via ssh nantu à u servitore di salvezza di salvezza, è i dati sò mandati via pipe.
I risultati di a prima opzione eranu i seguenti: 43m11s - quandu si usa un repository unencrypted è u compressore lzma, 19m13s - quandu si rimpiazza u compressore cù lzo.
A carica nantu à u servitore cù i dati originali era a siguenti (un esempiu cù lzma hè mostratu; cù lzo ci era apprussimatamente a stessa stampa, ma a parte di rsync era circa un quartu di u tempu):
Hè chjaru chì un tali prucessu di salvezza hè adattatu solu per cambiamenti relativamente rari è chjuchi. Hè ancu assai cunsigliatu di limità zbackup à 1 thread, altrimenti ci sarà una carica di CPU assai alta, perchè U prugramma hè assai bonu per travaglià in parechje fili. A carica nantu à u discu era chjuca, chì in generale ùn saria micca notu cù un subsistema di discu mudernu basatu in ssd. Pudete ancu vede chjaramente l'iniziu di u prucessu di sincronizazione di dati di repository à un servitore remotu; a velocità di l'operazione hè paragunabile à a rsync regulare è dipende da u rendiment di u sottosistema di discu di u servitore di salvezza di salvezza. U svantaghju di questu approcciu hè l'almacenamiento di un repository locale è, in u risultatu, a duplicazione di dati.
Più interessante è applicabile in a pratica hè a seconda opzione, esegue zbackup direttamente nantu à u servitore di salvezza di salvezza.
Prima, cuntrolleremu l'operazione senza aduprà criptografia cù u compressore lzma:
Durata di ogni esecuzione di prova:
Lanciamentu 1
Lanciamentu 2
Lanciamentu 3
39 m45 s
40 m20 s
40 m3 s
7 m36 s
8 m3 s
7 m48 s
15 m35 s
15 m48 s
15 m38 s
Se attivate a criptografia cù aes, i risultati sò abbastanza vicini:
Tempu di operazione nantu à i stessi dati, cù criptografia:
Lanciamentu 1
Lanciamentu 2
Lanciamentu 3
43 m40 s
44 m12 s
44 m3 s
8 m3 s
8 m15 s
8 m12 s
15 m0 s
15 m40 s
15 m25 s
Se a criptografia hè cumminata cù a compressione cù lzo, pare cusì:
Oghje ghjornu:
Lanciamentu 1
Lanciamentu 2
Lanciamentu 3
18 m2 s
18 m15 s
18 m12 s
5 m13 s
5 m24 s
5 m20 s
8 m48 s
9 m3 s
8 m51 s
A dimensione di u repositoriu risultatu era relativamente uguale à 13GB. Questu significa chì a deduplicazione funziona bè. Inoltre, nantu à e dati digià cumpressi, l'usu di lzo dà un effettu notevuli; in quantu à u tempu di u funziunamentu tutale, zbackup hè vicinu à a duplicità / duplicati, ma si trova in daretu à quelli basati in librsync da 2-5 volte.
I vantaghji sò evidenti - risparmià spaziu di discu nantu à u servitore di salvezza di salvezza. In quantu à l'arnesi di verificazione di u repository, l'autore di zbackup ùn li furnisce micca; hè cunsigliatu d'utilizà un array di discu tolerante à i difetti o un fornitore di nuvola.
In generale, una impressione assai bona, malgradu u fattu chì u prugettu hè statu fermu per circa 3 anni (l'ultima dumanda di funziunalità era circa un annu fà, ma senza risposta).
Pruvate borgbackup
Borgbackup hè una furchetta di attic, un altru sistema simile à zbackup. Scrittu in python, hà una lista di capacità simili à zbackup, ma ancu pò:
- Muntà backups via fusible
- Verificate u cuntenutu di u repository
- U travagliu in modu client-server
- Aduprate diversi compressori per i dati, è ancu a determinazione euristica di u tipu di fugliale quandu u cumpressà.
- 2 opzioni di crittografia, aes è blake
- Strumenta integrata per
cuntrolli di prestazione
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
I risultati eranu i seguenti:
CZ-BIG 96.51 MB/s (10 100.00 MB tutti i fugliali zero: 10.36 s)
RZ-BIG 57.22 MB/s (10 100.00 MB tutti i fugliali zero: 17.48 s)
UZ-BIG 253.63 MB/s (10 100.00 MB tutti i fugliali zero: 3.94 s)
DZ-BIG 351.06 MB/s (10 100.00 MB tutti i fugliali zero: 2.85 s)
CR-BIG 34.30 MB/s (10 100.00 MB di fugliali casuali: 29.15 s)
RR-BIG 60.69 MB/s (10 100.00 MB di fugliali casuali: 16.48 s)
UR-BIG 311.06 MB/s (10 100.00 MB di fugliali casuali: 3.21 s)
DR-BIG 72.63 MB/s (10 100.00 MB di fugliali casuali: 13.77 s)
CZ-MEDIUM 108.59 MB/s (1000 1.00 MB tutti i fugliali zero: 9.21 s)
RZ-MEDIUM 76.16 MB/s (1000 1.00 MB tutti i fugliali zero: 13.13 s)
UZ-MEDIUM 331.27 MB/s (1000 1.00 MB tutti i fugliali zero: 3.02 s)
DZ-MEDIUM 387.36 MB/s (1000 1.00 MB tutti i fugliali zero: 2.58 s)
CR-MEDIUM 37.80 MB/s (1000 1.00 MB di fugliali casuali: 26.45 s)
RR-MEDIUM 68.90 MB/s (1000 1.00 MB di fugliali casuali: 14.51 s)
UR-MEDIUM 347.24 MB/s (1000 1.00 MB di fugliali casuali: 2.88 s)
DR-MEDIUM 48.80 MB/s (1000 1.00 MB di fugliali casuali: 20.49 s)
CZ-SMALL 11.72 MB/s (10000 10.00 kB tutti i schedari zero: 8.53s)
RZ-SMALL 32.57 MB/s (10000 10.00 kB tutti i schedari zero: 3.07s)
UZ-SMALL 19.37 MB/s (10000 10.00 kB tutti i schedari zero: 5.16s)
DZ-SMALL 33.71 MB/s (10000 10.00 kB tutti i schedari zero: 2.97s)
CR-SMALL 6.85 MB/s (10000 10.00 kB file casuali: 14.60s)
RR-SMALL 31.27 MB/s (10000 10.00 kB file casuali: 3.20s)
UR-SMALL 12.28 MB/s (10000 10.00 kB file casuali: 8.14s)
DR-SMALL 18.78 MB/s (10000 10.00 kB file casuali: 5.32s)
Quandu a prova, l'euristica di compressione serà aduprata per determinà u tipu di schedariu (compressione auto), è i risultati seranu i seguenti:
Prima, verificate cumu funziona senza criptografia:
Oghje ghjornu:
Lanciamentu 1
Lanciamentu 2
Lanciamentu 3
4 m6 s
4 m10 s
4 m5 s
56s
58s
54s
1 m26 s
1 m34 s
1 m30 s
Se attivate l'autorizazione di repository (modu autenticatu), i risultati seranu vicinu:
Oghje ghjornu:
Lanciamentu 1
Lanciamentu 2
Lanciamentu 3
4 m11 s
4 m20 s
4 m12 s
1 m0 s
1 m3 s
1 m2 s
1 m30 s
1 m34 s
1 m31 s
Quandu a criptografia aes hè stata attivata, i risultati ùn anu micca deterioratu assai:
Lanciamentu 1
Lanciamentu 2
Lanciamentu 3
4 m55 s
5 m2 s
4 m58 s
1 m0 s
1 m2 s
1 m0 s
1 m49 s
1 m50 s
1 m50 s
È se cambiate aes à blake, a situazione migliurà cumplitamenti:
Oghje ghjornu:
Lanciamentu 1
Lanciamentu 2
Lanciamentu 3
4 m33 s
4 m43 s
4 m40 s
59s
1 m0 s
1 m0 s
1 m38 s
1 m43 s
1 m40 s
Cum'è in u casu di zbackup, a dimensione di u repository era 13GB è ancu un pocu menu, chì hè generalmente aspittatu. Eru assai piacè cù u tempu di esecuzione; hè paragunabile à e soluzioni basate in librsync, chì furnisce capacità assai più larghe. Eru ancu cuntentu di a capacità di stabilisce diversi paràmetri attraversu variabili di l'ambiente, chì dà un vantaghju assai seriu quandu si usa borgbackup in modu automaticu. Eru ancu piacè cù a carica durante a copia di salvezza: à ghjudicà da a carica di u processatore, borgbackup travaglia in 1 filu.
Ùn ci era micca svantaghji particulare quandu l'utilizanu.
essai resty
Malgradu u fattu chì u restu hè una suluzione abbastanza nova (i primi 2 candidati eranu cunnisciuti in 2013 è più vechji), hà caratteristiche abbastanza boni. Scrittu in Go.
Comparatu cù zbackup, dà in più:
- Verificate l'integrità di u repositoriu (cumpresu a verificazione in parti).
- Un vastu elencu di protokolli è fornitori supportati per l'almacenamiento di backups, è ancu supportu per rclone - rsync for cloud solutions.
- Paragunendu 2 backups cun l'altri.
- Muntà u repository via fusible.
In generale, a lista di funzioni hè abbastanza vicinu à borgbackup, in certi lochi più, in altri menu. Una di e caratteristiche hè chì ùn ci hè micca manera di disattivà a criptografia, è dunque e copie di salvezza seranu sempre criptate. Videmu in pratica ciò chì pò esse spressu da stu software:
I risultati eranu i seguenti:
Oghje ghjornu:
Lanciamentu 1
Lanciamentu 2
Lanciamentu 3
5 m25 s
5 m50 s
5 m38 s
35s
38s
36s
1 m54 s
2 m2 s
1 m58 s
I risultati di u rendiment sò ancu paragunabili à e soluzioni basate in rsync è, in generale, assai vicinu à borgbackup, ma a carica di CPU hè più altu (multiple threads running) è sawtooth.
Hè assai prubabile, u prugramma hè limitatu da a prestazione di u sottosistema di discu nantu à u servitore di almacenamiento di dati, cum'è era digià u casu cù rsync. A dimensione di u repository era 13GB, cum'è zbackup o borgbackup, ùn ci era micca svantaghji evidenti quandu si usa sta suluzione.
Risultati
In fatti, tutti i candidati ottennu risultati simili, ma à prezzi diffirenti. Borgbackup hà fattu u megliu di tuttu, restic era un pocu più lento, zbackup ùn vale micca a pena di principià à aduprà,
è s'ellu hè digià in usu, pruvate à cambià in borgbackup o restic.
scuperti
A suluzione più promettente pare esse risica, perchè ... hè quellu chì hà u megliu rapportu di capacità à a rapidità di u funziunamentu, ma ùn ci precipitemu à cunclusioni generale per avà.
Borgbackup hè basicamente micca peghju, ma zbackup hè probabilmente megliu rimpiazzatu. True, zbackup pò ancu esse usatu per assicurà chì a regula 3-2-1 funziona. Per esempiu, in più di e facilità di salvezza basate in (lib)rsync.
Avvisu
Backup Part 5: Testing bacula è veeam backup per linux
Backup Part 6: Comparazione di Strumenti di Backup
Backup Part 7: Conclusioni
Postatu da: Pavel Demkovich
Source: www.habr.com