Aquest article tractarà les eines de programari per a la còpia de seguretat, que, dividint el flux de dades en components separats (trossos), formen un dipòsit.
Els components del dipòsit es poden comprimir i xifrar addicionalment i, el més important, durant els processos de còpia de seguretat repetits, es poden reutilitzar.
Una còpia de seguretat en un dipòsit d'aquest tipus és una cadena anomenada de components relacionats entre si, per exemple, basats en diverses funcions hash.
Hi ha diverses solucions semblants, em centraré en 3: zbackup, borgbackup i restic.
Resultats previstos
Com que tots els sol·licitants requereixen la creació d'un dipòsit d'una manera o altra, un dels factors més importants serà la mida del dipòsit. Idealment, la seva mida no hauria de ser superior a 13 GB segons la metodologia acceptada, o fins i tot menys, subjecte a una bona optimització.
També és molt desitjable poder fer còpies de seguretat dels fitxers directament sense utilitzar arxivadors com tar, així com treballar amb ssh / sftp sense eines addicionals com rsync i sshfs.
Comportament en crear còpies de seguretat:
- La mida del repositori serà igual a la mida dels canvis, o menys.
- S'espera un ús elevat de la CPU quan s'utilitza la compressió i/o el xifratge, i és probable que la xarxa i el subsistema del disc siguin força pesats si el procés d'arxivament i/o xifratge s'executa al servidor d'emmagatzematge de còpia de seguretat.
- Si el dipòsit està danyat, és probable que es produeixi un error amb retard tant en crear noves còpies de seguretat com en intentar restaurar-les. Heu de planificar mesures addicionals per garantir la integritat del dipòsit o utilitzar els verificadors d'integritat integrats.
El treball amb quitrà es pren com a valor de referència, tal com es mostrava en un dels articles anteriors.
Prova zbackup
El mecanisme general de l'operació de zbackup és que el programa troba àrees que contenen les mateixes dades al flux de dades d'entrada i, opcionalment, les comprimeix i les xifra, estalviant cada àrea només una vegada.
Per a la desduplicació, s'utilitza una funció d'anell hash de finestra lliscant de 64 bits per comprovar byte a byte si hi ha una coincidència amb els blocs de dades ja existents (de manera similar a com s'implementa a rsync).
Per a la compressió, lzma i lzo s'utilitzen en l'execució multiprocés, i per al xifratge, s'utilitza aes. En les últimes versions, és possible suprimir dades antigues del dipòsit en el futur.
El programa està escrit en C++ amb dependències mínimes. Aparentment, l'autor es va inspirar en la manera Unix, de manera que el programa rep dades a stdin quan es crea còpies de seguretat, emetent un flux de dades similar a stdout quan es restaura. Per tant, zbackup es pot utilitzar com un molt bon "maó" quan escriu les teves pròpies solucions de còpia de seguretat. Per exemple, per a l'autor de l'article, aquest programa ha estat la principal eina de còpia de seguretat per a màquines domèstiques des del 2014 aproximadament.
El tar normal s'utilitzarà com a flux de dades, tret que s'indiqui el contrari.
Vegem quins seran els resultats:
El treball es va comprovar en 2 versions:
- es crea un dipòsit i s'executa zbackup al servidor amb les dades originals, després el contingut del dipòsit es transfereix al servidor d'emmagatzematge de còpia de seguretat.
- es crea un repositori al servidor d'emmagatzematge de còpia de seguretat, zbackup s'inicia mitjançant ssh al servidor d'emmagatzematge de còpia de seguretat, les dades se li donen a través de la canonada.
Els resultats de la primera opció van ser els següents: 43m11s - quan s'utilitzava un repositori sense xifrar i el compressor lzma, 19m13s - en substituir el compressor per lzo.
La càrrega al servidor amb les dades inicials era la següent (es mostra un exemple amb lzma, amb lzo era aproximadament la mateixa imatge, però la quota de rsync era aproximadament una quarta part del temps):
Està clar que aquest procés de còpia de seguretat només és adequat per a canvis relativament poc freqüents i petits. També és molt desitjable limitar el treball de zbackup a 1 fil, en cas contrari, hi haurà una càrrega de CPU molt elevada, perquè. El programa és molt capaç de treballar en diversos fils. La càrrega al disc era petita, cosa que en general no es notarà amb un subsistema de disc modern basat en ssd. També podeu veure clarament l'inici del procés de sincronització de les dades del dipòsit amb un servidor remot, la velocitat de treball és comparable a la rsync habitual i es basa en el rendiment del subsistema de disc del servidor d'emmagatzematge de còpia de seguretat. El desavantatge de l'enfocament és l'emmagatzematge d'un dipòsit local i, com a resultat, la duplicació de dades.
Més interessant i aplicable a la pràctica és la segona opció amb l'execució immediata de zbackup al servidor d'emmagatzematge de còpia de seguretat.
Per començar, es comprovarà el treball sense utilitzar el xifratge amb el compressor lzma:
Temps d'execució de cada prova:
Llançament 1
Llançament 2
Llançament 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
Si activeu el xifratge mitjançant aes, els resultats són bastant propers:
Temps de funcionament amb les mateixes dades, amb xifratge:
Llançament 1
Llançament 2
Llançament 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
Si el xifratge es combina amb la compressió a lzo, resulta així:
Horari:
Llançament 1
Llançament 2
Llançament 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
La mida del dipòsit resultant era relativament la mateixa amb 13 GB. Això vol dir que la deduplicació funciona correctament. A més, en dades ja comprimides, l'ús de lzo dóna un efecte tangible, pel que fa al temps d'execució total, zbackup està molt a prop de la duplicitat/duplicació, però queda enrere de 2 a 5 vegades per darrere dels basats en librsync.
Els avantatges són evidents: estalviar espai al disc al servidor d'emmagatzematge de còpia de seguretat. Pel que fa a les eines de verificació del dipòsit, no les proporciona l'autor de zbackup, es recomana utilitzar una matriu de disc tolerant a errors o un proveïdor de núvol.
En general, una molt bona impressió, malgrat que el projecte ha estat parat durant uns 3 anys (l'última petició de funcions va ser fa aproximadament un any, però sense resposta).
proves de borgbackup
Borgbackup és una bifurcació d'àtic, un altre sistema similar a zbackup. Escrit en Python, té una llista de funcions similars a zbackup, però a més pot:
- Munta còpies de seguretat amb fusible
- Comproveu el contingut del repositori
- Treballar en mode client-servidor
- Utilitzeu diversos compressors per a dades, així com la determinació heurística del tipus de fitxer en comprimir-lo.
- 2 opcions de xifratge, aes i blake
- Eina integrada per
controls de rendiment
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Els resultats van sortir així:
CZ-BIG 96.51 MB/s (10 100.00 MB de fitxers tot zero: 10.36 s)
RZ-BIG 57.22 MB/s (10 100.00 MB de fitxers tot zero: 17.48 s)
UZ-BIG 253.63 MB/s (10 100.00 MB de fitxers tot zero: 3.94 s)
DZ-BIG 351.06 MB/s (10 100.00 MB de fitxers tot zero: 2.85 s)
CR-BIG 34.30 MB/s (10 100.00 MB de fitxers aleatoris: 29.15 s)
RR-BIG 60.69 MB/s (10 100.00 MB de fitxers aleatoris: 16.48 s)
UR-BIG 311.06 MB/s (10 100.00 MB de fitxers aleatoris: 3.21 s)
DR-BIG 72.63 MB/s (10 100.00 MB de fitxers aleatoris: 13.77 s)
CZ-MEDIUM 108.59 MB/s (1000 1.00 MB de fitxers tot zero: 9.21 s)
RZ-MEDIUM 76.16 MB/s (1000 1.00 MB de fitxers tot zero: 13.13 s)
UZ-MEDIUM 331.27 MB/s (1000 1.00 MB de fitxers tot zero: 3.02 s)
DZ-MEDIUM 387.36 MB/s (1000 1.00 MB de fitxers tot zero: 2.58 s)
CR-MEDIUM 37.80 MB/s (1000 1.00 MB de fitxers aleatoris: 26.45 s)
RR-MEDIUM 68.90 MB/s (1000 1.00 MB de fitxers aleatoris: 14.51 s)
UR-MEDIUM 347.24 MB/s (1000 1.00 MB de fitxers aleatoris: 2.88 s)
DR-MEDIUM 48.80 MB/s (1000 1.00 MB de fitxers aleatoris: 20.49 s)
CZ-SMALL 11.72 MB/s (10000 Fitxers de 10.00 kB tot zero: 8.53 s)
RZ-SMALL 32.57 MB/s (10000 Fitxers de 10.00 kB tot zero: 3.07 s)
UZ-SMALL 19.37 MB/s (10000 Fitxers de 10.00 kB tot zero: 5.16 s)
DZ-SMALL 33.71 MB/s (10000 Fitxers de 10.00 kB tot zero: 2.97 s)
CR-SMALL 6.85 MB/s (10000 Fitxers aleatoris de 10.00 kB: 14.60 s)
RR-SMALL 31.27 MB/s (10000 Fitxers aleatoris de 10.00 kB: 3.20 s)
UR-SMALL 12.28 MB/s (10000 Fitxers aleatoris de 10.00 kB: 8.14 s)
DR-SMALL 18.78 MB/s (10000 Fitxers aleatoris de 10.00 kB: 5.32 s)
Durant la prova, s'utilitzaran les heurístiques durant la compressió amb la definició del tipus de fitxer (compressió automàtica) i els resultats seran els següents:
Primer, comprovem el treball sense xifratge:
Horari:
Llançament 1
Llançament 2
Llançament 3
4 m6 s
4 m10 s
4 m5 s
56s
58s
54s
1 m26 s
1 m34 s
1 m30 s
Si activeu l'autorització del dipòsit (mode autenticat), els resultats seran tancats:
Horari:
Llançament 1
Llançament 2
Llançament 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
En activar el xifratge aes, els resultats no es van deteriorar gaire:
Llançament 1
Llançament 2
Llançament 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
I si canvieu aes per blake, la situació millorarà completament:
Horari:
Llançament 1
Llançament 2
Llançament 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
Com en el cas de zbackup, la mida del dipòsit era de 13 GB i fins i tot una mica menys, cosa que, en general, s'espera. Estic molt satisfet amb el temps d'execució, és comparable a solucions basades en librsync, proporcionant moltes més oportunitats. També em va satisfer la possibilitat d'establir diversos paràmetres mitjançant variables d'entorn, la qual cosa dóna un avantatge molt seriós quan s'utilitza borgbackup en mode automàtic. També em va satisfer la càrrega durant la còpia de seguretat: a jutjar per la càrrega del processador, borgbackup funciona en 1 fil.
No hi va haver inconvenients particulars en utilitzar-lo.
prova resta
Tot i que restic és una solució força nova (els 2 primers candidats es coneixen des del 2013 i més), té unes característiques força bones. Escrit a Go.
En comparació amb zbackup, també ofereix:
- Comprovació de la integritat del dipòsit (inclosa la comprovació de parts).
- Una llista enorme de protocols i proveïdors compatibles per emmagatzemar còpies de seguretat, així com suport per a rclone - rsync for cloud solutions.
- Comparació de 2 còpies de seguretat entre si.
- Muntatge d'un dipòsit amb fusible.
En general, la llista de funcions és força propera a borgbackup, de vegades més, de vegades menys. De les característiques: la incapacitat de desactivar el xifratge i, per tant, les còpies de seguretat sempre es xifraran. Vegem a la pràctica què es pot extreure d'aquest programari:
Els resultats són els següents:
Horari:
Llançament 1
Llançament 2
Llançament 3
5 m25 s
5 m50 s
5 m38 s
35s
38s
36s
1 m54 s
2 m2 s
1 m58 s
Els resultats també són comparables a les solucions basades en rsync i, en general, són molt propers a borgbackup, però la càrrega del processador és més alta (funcionen diversos fils) i amb dents de serra.
Molt probablement, el programa es basa en el rendiment del subsistema de disc al servidor d'emmagatzematge, com va ser el cas de rsync. La mida del dipòsit era de 13 GB, com zbackup o borgbackup, no hi havia desavantatges evidents en utilitzar aquesta solució.
Troballes
De fet, tots els candidats van obtenir resultats similars, però a preus diferents. borgbackup va demostrar ser el millor, una mica més lent: restic, zbackup, probablement, no hauríeu de començar a utilitzar,
i si ja està en ús, proveu de canviar-lo a borgbackup o restic.
Troballes
Restic sembla ser la solució més prometedora, perquè és ell qui té la millor relació entre capacitats i velocitat, però de moment no ens precipitarem a conclusions generals.
Borgbackup no és pitjor en principi, però probablement és millor substituir zbackup. Tanmateix, la regla 3-2-1 de zbackup encara es pot utilitzar per fer-la funcionar. Per exemple, a més de les eines de còpia de seguretat basades en (lib)rsync.
Anunci
Còpia de seguretat Part 5: prova de còpia de seguretat de bacula i veeam per a Linux
Còpia de seguretat Part 6: comparació d'eines de còpia de seguretat
Còpia de seguretat Part 7: Conclusions
Autor de la publicació: Pavel Demkovich
Font: www.habr.com