Aquesta nota tracta les eines de còpia de seguretat que realitzen còpies de seguretat mitjançant la creació d'arxius en un servidor de còpia de seguretat.
Entre els que compleixen els requisits hi ha la duplicitat (que té una interfície agradable en forma de deja dup) i la duplicació.
Una altra eina de còpia de seguretat molt destacable és dar, però com que té una llista molt extensa d'opcions -la metodologia de prova cobreix amb prou feines el 10% del que és capaç-, no l'estem provant com a part del cicle actual.
Resultats previstos
Atès que ambdós candidats creen arxius d'una manera o una altra, es pot utilitzar tar normal com a guia.
A més, avaluarem com s'optimitza l'emmagatzematge de dades al servidor d'emmagatzematge mitjançant la creació de còpies de seguretat que continguin només la diferència entre una còpia completa i l'estat actual dels fitxers, o entre els arxius anteriors i actuals (incremental, decremental, etc.) .
Comportament en crear còpies de seguretat:
- Un nombre relativament petit de fitxers al servidor d'emmagatzematge de còpia de seguretat (comparable al nombre de còpies de seguretat o la mida de les dades en GB), però la seva mida és bastant gran (de desenes a centenars de megabytes).
- La mida del dipòsit només inclourà els canvis; no s'emmagatzemarà cap duplicat, de manera que la mida del dipòsit serà més petita que amb el programari basat en rsync.
- Espereu una càrrega elevada de la CPU quan utilitzeu compressió i/o xifratge, i probablement una càrrega de xarxa i disc força alta si el procés d'arxivament i/o xifratge s'executa en un servidor d'emmagatzematge de còpia de seguretat.
Executem la següent comanda com a valor de referència:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Els resultats de l'execució van ser els següents:
Temps d'execució 3m12s. Es pot veure que la velocitat està limitada pel subsistema de disc del servidor d'emmagatzematge de còpia de seguretat, com a l'exemple amb . Només una mica més ràpid, perquè... la gravació va a un fitxer.
A més, per avaluar la compressió, executem la mateixa opció, però activem la compressió al costat del servidor de còpia de seguretat:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Els resultats són:
Temps d'execució 10m11s. El més probable és que el coll d'ampolla sigui el compressor d'un sol flux a l'extrem receptor.
La mateixa comanda, però amb compressió transferida al servidor amb les dades originals per provar la hipòtesi que el coll d'ampolla és un compressor d'un sol fil.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Va resultar així:
El temps d'execució va ser de 9m37s. La càrrega d'un nucli pel compressor és clarament visible, perquè La velocitat de transferència de xarxa i la càrrega del subsistema del disc d'origen són similars.
Per avaluar el xifratge, podeu utilitzar openssl o gpg connectant una ordre addicional openssl o gpg en canonada. Com a referència, hi haurà una ordre com aquesta:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Els resultats van sortir així:
El temps d'execució va resultar ser de 10 m30, ja que s'estaven executant 2 processos al costat receptor: el coll d'ampolla torna a ser un compressor d'un sol fil, a més d'una petita sobrecàrrega de xifratge.
ACTUALITZACIÓ: A petició de bliznezz estic afegint proves amb pigz. Si utilitzeu només el compressor, trigarien 6m30s, si afegiu també xifratge, serien uns 7m. La caiguda al gràfic inferior és una memòria cau de disc sense esborrar:
Prova duplicada
Duplicity és un programari Python per fer còpies de seguretat mitjançant la creació d'arxius xifrats en format tar.
Per als arxius incrementals, s'utilitza librsync, de manera que podeu esperar el comportament descrit a .
Les còpies de seguretat es poden xifrar i signar amb gnupg, que és important quan s'utilitzen diferents proveïdors per emmagatzemar còpies de seguretat (s3, backblaze, gdrive, etc.)
Vegem quins seran els resultats:
Aquests són els resultats que vam obtenir en executar-nos sense xifratge
spoiler
Temps d'execució de cada prova:
Llançament 1
Llançament 2
Llançament 3
16 m33 s
17 m20 s
16 m30 s
8 m29 s
9 m3 s
8 m45 s
5 m21 s
6 m04 s
5 m53 s
I aquests són els resultats quan el xifratge gnupg està habilitat, amb una mida de clau de 2048 bits:
Temps de funcionament amb les mateixes dades, amb xifratge:
Llançament 1
Llançament 2
Llançament 3
17 m22 s
17 m32 s
17 m28 s
8 m52 s
9 m13 s
9 m3 s
5 m48 s
5 m40 s
5 m30 s
Es va indicar la mida del bloc: 512 megabytes, que és clarament visible als gràfics; La càrrega del processador es va mantenir en realitat al 50%, la qual cosa significa que el programa no utilitza més d'un nucli de processador.
El principi de funcionament del programa també és ben visible: van agafar una peça de dades, la van comprimir i les van enviar a un servidor d'emmagatzematge de còpia de seguretat, que pot ser bastant lent.
Una altra característica és el temps d'execució previsible del programa, que només depèn de la mida de les dades modificades.
L'habilitació del xifratge no va augmentar significativament el temps d'execució del programa, però va augmentar la càrrega del processador al voltant d'un 10%, la qual cosa pot ser un bon avantatge.
Malauradament, aquest programa no va poder detectar correctament la situació amb el canvi de nom del directori, i la mida del repositori resultant va resultar ser igual a la mida dels canvis (és a dir, tots els 18 GB), però la capacitat d'utilitzar un servidor no fiable per a la còpia de seguretat clarament cobreix aquest comportament.
Prova duplicada
Aquest programari està escrit en C# i s'executa amb un conjunt de biblioteques de Mono. Hi ha una GUI i una versió CLI.
La llista aproximada de les funcions principals és similar a la duplicitat, incloent diversos proveïdors d'emmagatzematge de còpia de seguretat, però, a diferència de la duplicitat, la majoria de les funcions estan disponibles sense eines de tercers. Que això sigui un avantatge o un negatiu depèn del cas concret, però per als principiants, és més probable que sigui més fàcil tenir una llista de totes les funcions al davant alhora, en lloc d'haver d'instal·lar paquets addicionals per a Python, com és el cas. el cas de la duplicitat.
Un altre petit matís: el programa escriu activament una base de dades sqlite local en nom de l'usuari que inicia la còpia de seguretat, de manera que cal assegurar-se, a més, que la base de dades necessària s'especifiqui correctament cada vegada que s'inicia el procés amb el cli. Quan es treballa mitjançant GUI o WEBGUI, els detalls s'amagaran a l'usuari.
Vegem quins indicadors pot produir aquesta solució:
Si desactiveu el xifratge (i WEBGUI no recomana fer-ho), els resultats són els següents:
Horari:
Llançament 1
Llançament 2
Llançament 3
20 m43 s
20 m13 s
20 m28 s
5 m21 s
5 m40 s
5 m35 s
7 m36 s
7 m54 s
7 m49 s
Amb el xifratge habilitat, utilitzant aes, es veu així:
Horari:
Llançament 1
Llançament 2
Llançament 3
29 m9 s
30 m1 s
29 m54 s
5 m29 s
6 m2 s
5 m54 s
8 m44 s
9 m12 s
9 m1 s
I si utilitzeu el programa extern gnupg, surten els següents resultats:
Llançament 1
Llançament 2
Llançament 3
26 m6 s
26 m35 s
26 m17 s
5 m20 s
5 m48 s
5 m40 s
8 m12 s
8 m42 s
8 m15 s
Com podeu veure, el programa pot funcionar en diversos fils, però això no el converteix en una solució més productiva, i si compareu el treball de xifratge, està llançant un programa extern.
va resultar ser més ràpid que utilitzar la biblioteca del conjunt Mono. Això pot ser degut al fet que el programa extern està més optimitzat.
Una altra cosa agradable va ser el fet que la mida del dipòsit pren exactament tant com les dades canviades reals, és a dir. duplicati va detectar un canvi de nom del directori i va gestionar aquesta situació correctament. Això es pot veure en executar la segona prova.
En general, impressions força positives del programa, inclòs ser bastant amable amb els novells.
Troballes
Tots dos candidats van treballar bastant lentament, però en general, en comparació amb quitrà normal, hi ha avenços, almenys amb duplicati. El preu d'aquest progrés també és clar: una càrrega notable
processador. En general, no hi ha desviacions especials en la predicció dels resultats.
Troballes
Si no cal precipitar-se enlloc, i també disposar d'un processador de recanvi, qualsevol de les solucions considerades farà, en qualsevol cas, s'ha fet força feina que no s'ha de repetir escrivint scripts d'embolcall a sobre de quitrà . La presència del xifratge és una propietat molt necessària si el servidor per emmagatzemar còpies de seguretat no es pot confiar completament.
En comparació amb solucions basades - El rendiment pot ser diverses vegades pitjor, malgrat que en la seva forma pura el quitrà funcionava un 20-30% més ràpid que rsync.
Hi ha estalvis en la mida del dipòsit, però només amb duplicati.
Anunci
Còpia de seguretat Part 3: revisió i prova de duplicitat, duplicat, deja dup
Còpia de seguretat Part 4: revisió i prova de zbackup, restic, borgbackup
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