Aquest article compararà les eines de còpia de seguretat, però primer hauríeu d'esbrinar amb quina rapidesa i bé s'enfronten a la restauració de dades de les còpies de seguretat.
Per facilitar la comparació, considerarem la restauració des d'una còpia de seguretat completa, sobretot perquè tots els candidats admeten aquest mode de funcionament. Per simplificar, els nombres ja estan promediats (la mitjana aritmètica de diverses tirades). Els resultats es resumiran en una taula, que també contindrà informació sobre les capacitats: presència d'una interfície web, facilitat de configuració i funcionament, capacitat d'automatització, presència de diverses funcions addicionals (per exemple, comprovació de la integritat de les dades) , etc. Els gràfics mostraran la càrrega al servidor on s'utilitzaran les dades (no el servidor per emmagatzemar còpies de seguretat).
Recuperació de dades
rsync i tar s'utilitzaran com a punt de referència des de llavors scripts senzills per fer còpies de seguretat.
Rsync va fer front al conjunt de dades de la prova en 4 minuts i 28 segons, mostrant-se
tal càrrega
El procés de recuperació va afectar una limitació del subsistema de disc del servidor d'emmagatzematge de còpia de seguretat (gràfics de dent de serra). També podeu veure clarament la càrrega d'un nucli sense cap problema (baix iowait i softirq - sense problemes amb el disc i la xarxa, respectivament). Com que els altres dos programes, és a dir, rdiff-backup i rsnapshot, es basen en rsync i també ofereixen rsync regular com a eina de recuperació, tindran aproximadament el mateix perfil de càrrega i temps de recuperació de la còpia de seguretat.
Tar ho va fer una mica més ràpid
2 minuts i 43 segons:
La càrrega total del sistema va ser més alta de mitjana un 20% a causa de l'augment de softirq: els costos generals durant el funcionament del subsistema de xarxa van augmentar.
Si l'arxiu es comprimeix més, el temps de recuperació augmenta a 3 minuts i 19 segons.
amb aquesta càrrega al servidor principal (desembalatge al costat del servidor principal):
El procés de descompressió ocupa els dos nuclis del processador perquè hi ha dos processos en execució. En general, aquest és el resultat esperat. A més, es va obtenir un resultat comparable (3 minuts i 20 segons) en executar gzip al costat del servidor amb còpies de seguretat; el perfil de càrrega al servidor principal era molt similar a l'execució de tar sense el compressor gzip (vegeu el gràfic anterior).
В rdiff-còpia de seguretat podeu sincronitzar l'última còpia de seguretat que heu fet amb rsync normal (els resultats seran similars), però les còpies de seguretat més antigues encara s'han de restaurar amb el programa rdiff-backup, que va completar la restauració en 17 minuts i 17 segons, mostrant
aquesta càrrega:
Potser es pretenia, almenys, limitar la velocitat dels autors . El procés de restauració d'una còpia de seguretat requereix una mica menys de la meitat d'un nucli, amb un rendiment proporcionalment comparable (és a dir, 2-5 vegades més lent) al disc i a la xarxa amb rsync.
Rsnapshot Per a la recuperació, suggereix utilitzar rsync regular, de manera que els seus resultats seran similars. En general, així va resultar.
Eructe Vaig completar la tasca de restaurar una còpia de seguretat en 7 minuts i 2 segons amb
amb aquesta càrrega:
Va funcionar amb força rapidesa i, almenys, és molt més convenient que el rsync pur: no cal que recordeu cap bandera, una interfície cli senzilla i intuïtiva, suport integrat per a diverses còpies, tot i que és dues vegades més lent. Si necessiteu restaurar les dades de l'última còpia de seguretat que heu fet, podeu utilitzar rsync, amb algunes advertències.
El programa mostrava aproximadament la mateixa velocitat i càrrega Còpia de seguretat del PC en habilitar el mode de transferència rsync, desplegant la còpia de seguretat per
7 minuts i 42 segons:
Però en el mode de transferència de dades, BackupPC va fer front al tar més lentament: en 12 minuts i 15 segons, la càrrega del processador era generalment més baixa.
una vegada i mitja:
Duplicitat sense xifratge va mostrar resultats lleugerament millors, restaurant una còpia de seguretat en 10 minuts i 58 segons. Si activeu l'encriptació mitjançant gpg, el temps de recuperació augmenta a 15 minuts i 3 segons. A més, quan creeu un dipòsit per emmagatzemar còpies, podeu especificar la mida de l'arxiu que s'utilitzarà en dividir el flux de dades entrant. En general, als discs durs convencionals, també a causa del mode de funcionament d'un sol fil, no hi ha molta diferència. Pot aparèixer en diferents mides de bloc quan s'utilitza l'emmagatzematge híbrid. La càrrega al servidor principal durant la recuperació va ser la següent:
sense xifratge
amb xifratge
Duplicat va mostrar una taxa de recuperació comparable, completant-la en 13 minuts i 45 segons. Va trigar uns 5 minuts més a comprovar la correcció de les dades recuperades (un total d'uns 19 minuts). La càrrega era
bastant alt:
Quan el xifratge aes es va habilitar internament, el temps de recuperació va ser de 21 minuts 40 segons, amb la utilització de la CPU al màxim (ambdós nuclis!) durant la recuperació; En comprovar les dades, només un fil estava actiu, ocupant un nucli de processador. La comprovació de les dades després de la recuperació va trigar els mateixos 5 minuts (gairebé 27 minuts en total).
Resultat
duplicati va ser una mica més ràpid amb la recuperació quan s'utilitzava el programa extern gpg per al xifratge, però en general les diferències amb el mode anterior són mínimes. El temps de funcionament va ser de 16 minuts 30 segons, amb la verificació de dades en 6 minuts. La càrrega era
tals:
AMANDA, utilitzant quitrà, el va completar en 2 minuts 49 segons, que, en principi, s'acosta molt al quitrà normal. Càrrega al sistema en principi
el mateix:
Quan es restaura una còpia de seguretat utilitzant zbackup es van obtenir els següents resultats:
xifratge, compressió lzma
Temps d'execució 11 minuts i 8 segons
Xifratge AES, compressió lzma
Temps de funcionament 14 minuts
Xifratge AES, compressió lzo
Temps de funcionament 6 minuts, 19 segons
En general, no està malament. Tot depèn de la velocitat del processador al servidor de còpia de seguretat, que es pot veure clarament des del temps d'execució del programa amb diferents compressors. Al costat del servidor de còpia de seguretat, es va llançar un quitrà normal, de manera que si el compareu amb ell, la recuperació és 3 vegades més lenta. Potser val la pena comprovar el funcionament en mode multifils, amb més de dos fils.
BorgBackup en mode no xifrat era una mica més lent que el quitrà, en 2 minuts i 45 segons, però, a diferència del quitrà, es va fer possible desduplicar el dipòsit. La càrrega va resultar ser
el següent:
Si activeu el xifratge basat en blake, la velocitat de recuperació de la còpia de seguretat és lleugerament més lenta. El temps de recuperació en aquest mode és de 3 minuts i 19 segons i la càrrega ha desaparegut
com això:
El xifratge AES és una mica més lent, el temps de recuperació és de 3 minuts 23 segons, la càrrega és especialment
no ha canviat:
Com que Borg pot treballar en mode multifil, la càrrega del processador és màxima i, quan s'activen funcions addicionals, el temps de funcionament simplement augmenta. Pel que sembla, val la pena explorar el multithreading d'una manera similar a zbackup.
Rústic va fer front a la recuperació una mica més lentament, el temps operatiu va ser de 4 minuts i 28 segons. La càrrega semblava
així que:
Pel que sembla, el procés de recuperació funciona en diversos fils, però l'eficiència no és tan alta com la de BorgBackup, però comparable en el temps a la rsync regular.
Amb UrBackup Va ser possible restaurar les dades en 8 minuts i 19 segons, la càrrega era
tals:
La càrrega encara no és molt alta, fins i tot inferior a la del quitrà. En alguns llocs hi ha ràfegues, però no més que la càrrega d'un nucli.
Selecció i justificació de criteris de comparació
Tal com s'indica en un dels articles anteriors, el sistema de còpia de seguretat ha de complir els criteris següents:
- Facilitat d'ús
- versatilitat
- Estabilitat
- Rapidesa
Val la pena considerar cada punt per separat amb més detall.
Facilitat d'operació
El millor és quan hi ha un botó "Fes-ho tot bé", però si tornes als programes reals, el més convenient serà un principi de funcionament estàndard i familiar.
La majoria dels usuaris probablement estaran millor si no han de recordar un munt de claus per a cli, configurar un munt d'opcions diferents, sovint obscures, a través del web o tui, o configurar notificacions sobre un funcionament infructuós. Això també inclou la possibilitat d'"encaixar" fàcilment una solució de còpia de seguretat a la infraestructura existent, així com l'automatització del procés de còpia de seguretat. També hi ha la possibilitat d'instal·lar-se mitjançant un gestor de paquets, o en una o dues ordres com ara "descarregar i desempaquetar". curl ссылка | sudo bash - un mètode complex, ja que cal comprovar el que arriba a través de l'enllaç.
Per exemple, dels candidats considerats, una solució senzilla és burp, rdiff-backup i restic, que tenen tecles mnemotècniques per a diferents modes de funcionament. Una mica més complexos són borg i duplicitat. El més difícil va ser AMANDA. La resta es troben en un lloc intermedi en termes de facilitat d'ús. En qualsevol cas, si necessites més de 30 segons per llegir el manual d'usuari, o necessites anar a Google o un altre cercador, i també desplaçar-te per un llarg full d'ajuda, la decisió és difícil, d'una manera o altra.
Alguns dels candidats considerats són capaços d'enviar automàticament un missatge a través de l'e-mailjabber, mentre que altres es basen en alertes configurades al sistema. A més, la majoria de les solucions complexes no tenen configuracions d'alerta del tot òbvies. En qualsevol cas, si el programa de còpia de seguretat produeix un codi de retorn diferent de zero, que el servei del sistema entendrà correctament per a les tasques periòdiques (s'enviarà un missatge a l'administrador del sistema o directament a la supervisió), la situació és senzilla. Però si el sistema de còpia de seguretat, que no s'executa en un servidor de còpia de seguretat, no es pot configurar, la manera òbvia de dir sobre el problema és que la complexitat ja és excessiva. En qualsevol cas, emetre avisos i altres missatges només a la interfície web o al registre és una mala pràctica, ja que la majoria de vegades s'ignoraran.
Pel que fa a l'automatització, un programa senzill pot llegir variables d'entorn que defineixen el seu mode de funcionament, o té una cli desenvolupada que pot duplicar completament el comportament quan es treballa a través d'una interfície web, per exemple. Això inclou també la possibilitat de funcionament continu, la disponibilitat d'oportunitats d'expansió, etc.
versatilitat
Fent-se ressò parcialment de la subsecció anterior sobre l'automatització, no hauria de ser un problema particular "encaixar" el procés de còpia de seguretat a la infraestructura existent.
Val la pena assenyalar que l'ús de ports no estàndard (bé, excepte la interfície web) per al treball, la implementació del xifratge d'una manera no estàndard, l'intercanvi de dades amb un protocol no estàndard són signes de no - Solució universal. En la seva majoria, tots els candidats els tenen d'una manera o altra per la raó òbvia: la senzillesa i la versatilitat no solen anar juntes. Com a excepció: eructe, n'hi ha d'altres.
Com a senyal: la capacitat de treballar amb ssh normal.
Velocitat de treball
El punt més polèmic i polèmic. D'una banda, vam posar en marxa el procés, va funcionar el més ràpid possible i no va interferir amb les tasques principals. D'altra banda, hi ha un augment del trànsit i la càrrega del processador durant el període de còpia de seguretat. També val la pena assenyalar que els programes més ràpids per fer còpies solen ser els més pobres pel que fa a funcions importants per als usuaris. Un cop més: si per obtenir un fitxer de text desafortunat de diverses desenes de bytes de mida amb una contrasenya i, per això, tot el servei costa (sí, sí, entenc que el procés de còpia de seguretat no és el més sovint culpable aquí), i cal tornar a llegir seqüencialment tots els fitxers del dipòsit o ampliar tot l'arxiu: el sistema de còpia de seguretat mai és ràpid. Un altre punt que sovint es converteix en un obstacle és la velocitat de desplegament d'una còpia de seguretat des d'un arxiu. Aquí hi ha un avantatge clar per a aquells que simplement poden copiar o moure fitxers a la ubicació desitjada sense gaire manipulació (rsync, per exemple), però sovint el problema s'ha de resoldre d'una manera organitzativa, empírica: mesurant el temps de recuperació de la còpia de seguretat. i informar obertament als usuaris sobre això.
Estabilitat
S'ha d'entendre d'aquesta manera: d'una banda, s'ha de poder tornar a desplegar la còpia de seguretat de qualsevol manera, d'altra banda, ha de ser resistent a diversos problemes: interrupció de la xarxa, fallada del disc, supressió de part del repositori.
Comparació d'eines de còpia de seguretat
Temps de creació de còpies
Temps de recuperació de la còpia
Fàcil instal·lació
Fàcil configuració
Ús senzill
Automatització senzilla
Necessites un servidor client?
Comprovació de la integritat del repositori
Còpies diferencials
Treballant per tub
versatilitat
Independència
Transparència del repositori
Xifrat
Compressió
Deduplicació
Interfície web
Omplint fins al núvol
Suport de Windows
Puntuació
Rsync
4 m15 s
4 m28 s
sí
нет
нет
нет
sí
нет
нет
sí
нет
sí
sí
нет
нет
нет
нет
нет
sí
6
Tar
pur
3 m12 s
2 m43 s
sí
нет
нет
нет
нет
нет
sí
sí
нет
sí
нет
нет
нет
нет
нет
нет
sí
8,5
gzip
9 m37 s
3 m19 s
sí
Còpia de seguretat Rdiff
16 m26 s
17 m17 s
sí
sí
sí
sí
sí
нет
sí
нет
sí
нет
sí
нет
sí
sí
sí
нет
sí
11
Rsnapshot
4 m19 s
4 m28 s
sí
sí
sí
sí
нет
нет
sí
нет
sí
нет
sí
нет
нет
sí
sí
нет
sí
12,5
Eructe
11 m9 s
7 m2 s
sí
нет
sí
sí
sí
sí
sí
нет
sí
sí
нет
нет
sí
нет
sí
нет
sí
10,5
Duplicitat
sense xifratge
16 m48 s
10 m58 s
sí
sí
нет
sí
нет
sí
sí
нет
нет
sí
нет
sí
sí
нет
sí
нет
sí
11
gpg
17 m27 s
15 m3 s
Duplicat
sense xifratge
20 m28 s
13 m45 s
нет
sí
нет
нет
нет
sí
sí
нет
нет
sí
нет
sí
sí
sí
sí
sí
sí
11
aes
29 m41 s
21 m40 s
gpg
26 m19 s
16 m30 s
Còpia de seguretat Z
sense xifratge
40 m3 s
11 m8 s
sí
sí
нет
нет
нет
sí
sí
sí
нет
sí
нет
sí
sí
sí
нет
нет
нет
10
aes
42 m0 s
14 m1 s
aes+lzo
18 m9 s
6 m19 s
BorgBackup
sense xifratge
4 m7 s
2 m45 s
sí
sí
sí
sí
sí
sí
sí
sí
sí
sí
нет
sí
sí
sí
sí
нет
sí
16
aes
4 m58 s
3 m23 s
blake2
4 m39 s
3 m19 s
Rústic
5 m38 s
4 m28 s
sí
sí
sí
sí
нет
sí
sí
sí
sí
sí
нет
sí
нет
sí
нет
sí
sí
15,5
UrBackup
8 m21 s
8 m19 s
sí
sí
sí
нет
sí
нет
sí
нет
sí
sí
нет
sí
sí
sí
sí
нет
sí
12
Amanda
9 m3 s
2 m49 s
sí
нет
нет
sí
sí
sí
sí
нет
sí
sí
sí
sí
sí
нет
sí
sí
sí
13
Còpia de seguretat del PC
rsync
12 m22 s
7 m42 s
sí
нет
sí
sí
sí
sí
sí
нет
sí
нет
нет
sí
sí
нет
sí
нет
sí
10,5
tar
12 m34 s
12 m15 s
Llegenda de la taula:
- Verd, temps de funcionament inferior a cinc minuts, o respon "Sí" (excepte la columna "Necessites un servidor client?"), 1 punt
- Groc, temps de funcionament de cinc a deu minuts, 0.5 punts
- Vermell, el temps de treball és de més de deu minuts o la resposta és "No" (excepte la columna "Necessites un servidor client?"), 0 punts
Segons la taula anterior, l'eina de còpia de seguretat més senzilla, ràpida i alhora còmoda i potent és BorgBackup. Restic va ocupar el segon lloc, la resta de candidats considerats es van col·locar aproximadament a parts iguals amb un repartiment d'un o dos punts al final.
Dono les gràcies a tots els que llegiu la sèrie fins al final, us proposo discutir les opcions i oferir les vostres, si n'hi ha. A mesura que avança la discussió, la taula es pot ampliar.
El resultat de la sèrie serà l'article final, en el qual s'intentarà desenvolupar una eina de còpia de seguretat ideal, ràpida i manejable que permeti tornar a desplegar una còpia en el menor temps possible i alhora ser còmoda i fàcil. per configurar i mantenir.
Anunci
Còpia de seguretat Part 6: comparació d'eines de còpia de seguretat
Còpia de seguretat Part 7: Conclusions
Font: www.habr.com