Este artigo comparará as ferramentas de copia de seguranza, pero primeiro debes descubrir o rápido e ben que xestionan a restauración dos datos das copias de seguridade.
Para facilitar a comparación, consideraremos a restauración desde unha copia de seguranza completa, especialmente porque todos os candidatos admiten este modo de operación. Para simplificar, os números xa están promediados (a media aritmética de varias carreiras). Os resultados resumiranse nunha táboa, que tamén conterá información sobre as capacidades: a presenza dunha interface web, a facilidade de configuración e operación, a capacidade de automatizar, a presenza de varias funcións adicionais (por exemplo, a comprobación da integridade dos datos) , etc. Os gráficos mostrarán a carga no servidor onde se usarán os datos (non o servidor para almacenar copias de seguridade).
Recuperación de datos
rsync e tar utilizaranse como punto de referencia xa que scripts sinxelos para facer copias de seguridade.
Rsync enfrontou o conxunto de datos da proba en 4 minutos e 28 segundos, mostrando
tal carga
O proceso de recuperación alcanzou unha limitación do subsistema de discos do servidor de almacenamento de copia de seguridade (gráficos de dente de serra). Tamén podes ver claramente a carga dun núcleo sen ningún problema (baixa iowait e softirq - sen problemas co disco e coa rede, respectivamente). Dado que os outros dous programas, a saber, rdiff-backup e rsnapshot, están baseados en rsync e tamén ofrecen rsync regular como ferramenta de recuperación, terán aproximadamente o mesmo perfil de carga e tempo de recuperación da copia de seguridade.
Tar fíxoo un pouco máis rápido
2 minutos e 43 segundos:
A carga total do sistema foi maior de media nun 20% debido ao aumento do softirq: aumentaron os custos xerais durante a operación do subsistema de rede.
Se o arquivo se comprime máis, o tempo de recuperación aumenta a 3 minutos e 19 segundos.
con tal carga no servidor principal (descomprimir no lado do servidor principal):
O proceso de descompresión ocupa os dous núcleos do procesador porque hai dous procesos en execución. En xeral, este é o resultado esperado. Ademais, obtívose un resultado comparable (3 minutos e 20 segundos) ao executar gzip no lado do servidor con copias de seguridade; o perfil de carga no servidor principal era moi semellante ao de executar tar sen o compresor gzip (ver gráfico anterior).
В rdiff-backup pode sincronizar a última copia de seguranza que fixera mediante rsync normal (os resultados serán similares), pero as copias de seguridade máis antigas aínda deben ser restauradas mediante o programa rdiff-backup, que completou a restauración en 17 minutos e 17 segundos, mostrando
esta carga:
Quizais se pretendía, polo menos, limitar a velocidade dos autores . O proceso de restauración dunha copia de seguranza en si leva un pouco menos da metade dun núcleo, cun rendemento proporcionalmente comparable (é dicir, 2-5 veces máis lento) no disco e na rede con rsync.
Rsnapshot Para a recuperación, suxire usar rsync regular, polo que os seus resultados serán similares. En xeral, así foi como resultou.
Eructar Completei a tarefa de restaurar unha copia de seguridade en 7 minutos e 2 segundos con
con esta carga:
Funcionou bastante rápido e, polo menos, é moito máis cómodo que a sincronización pura: non precisa lembrar ningunha bandeira, unha interface cli simple e intuitiva, soporte integrado para varias copias, aínda que é dúas veces máis lento. Se precisas restaurar os datos da última copia de seguranza que fixeches, podes usar rsync, con algunhas advertencias.
O programa mostrou aproximadamente a mesma velocidade e carga Copia de seguridade do PC ao activar o modo de transferencia rsync, implementar a copia de seguridade para
7 minutos e 42 segundos:
Pero no modo de transferencia de datos, BackupPC afrontou o tar máis lentamente: en 12 minutos e 15 segundos, a carga do procesador era xeralmente menor
unha vez e media:
Duplicidade sen cifrado mostrou resultados lixeiramente mellores, restaurando unha copia de seguridade en 10 minutos e 58 segundos. Se activas o cifrado mediante gpg, o tempo de recuperación aumenta a 15 minutos e 3 segundos. Ademais, ao crear un repositorio para almacenar copias, pode especificar o tamaño do arquivo que se utilizará ao dividir o fluxo de datos entrante. En xeral, nos discos duros convencionais, tamén debido ao modo de funcionamento dun só fío, non hai moita diferenza. Pode aparecer en diferentes tamaños de bloque cando se usa almacenamento híbrido. A carga no servidor principal durante a recuperación foi a seguinte:
sen cifrado
con cifrado
Duplicar mostrou unha taxa de recuperación comparable, completándoa en 13 minutos e 45 segundos. Tardaron uns 5 minutos máis en comprobar a corrección dos datos recuperados (un total duns 19 minutos). A carga foi
bastante alto:
Cando o cifrado aes estaba habilitado internamente, o tempo de recuperación era de 21 minutos e 40 segundos, co uso máximo da CPU (¡ambos núcleos!) durante a recuperación; Ao comprobar os datos, só estaba activo un fío, que ocupaba un núcleo do procesador. Comprobar os datos despois da recuperación levou os mesmos 5 minutos (case 27 minutos en total).
Resultado
duplicati foi un pouco máis rápido coa recuperación ao usar o programa gpg externo para o cifrado, pero en xeral as diferenzas co modo anterior son mínimas. O tempo de funcionamento foi de 16 minutos e 30 segundos, coa verificación dos datos en 6 minutos. A carga foi
tales:
Amanda, usando alcatrán, completouno en 2 minutos e 49 segundos, o que, en principio, está moi próximo ao alcatrán normal. Carga no sistema en principio
o mesmo:
Ao restaurar unha copia de seguridade usando zbackup obtivéronse os seguintes resultados:
cifrado, compresión lzma
Tempo de execución 11 minutos e 8 segundos
Cifrado AES, compresión lzma
Tempo de funcionamento 14 minutos
Cifrado AES, compresión lzo
Tempo de execución 6 minutos, 19 segundos
En xeral, non está mal. Todo depende da velocidade do procesador no servidor de copia de seguridade, que se pode ver claramente desde o tempo de execución do programa con diferentes compresores. No lado do servidor de copia de seguranza, lanzouse un tar normal, polo que se o comparas con el, a recuperación é 3 veces máis lenta. Pode valer a pena comprobar o funcionamento en modo multi-fíos, con máis de dous fíos.
BorgBackup en modo sen cifrar era un pouco máis lento que tar, en 2 minutos e 45 segundos, con todo, a diferenza de tar, fíxose posible deduplicar o repositorio. A carga resultou ser
O seguinte:
Se activas o cifrado baseado en Blake, a velocidade de recuperación da copia de seguranza é un pouco máis lenta. O tempo de recuperación neste modo é de 3 minutos e 19 segundos e a carga desapareceu
como isto:
O cifrado AES é un pouco máis lento, o tempo de recuperación é de 3 minutos e 23 segundos, a carga é especialmente
non cambiou:
Dado que Borg pode traballar en modo multiproceso, a carga do procesador é máxima e, cando se activan funcións adicionais, o tempo de funcionamento simplemente aumenta. Ao parecer, paga a pena explorar o multithreading dun xeito similar ao zbackup.
Restric afrontou a recuperación un pouco máis lentamente, o tempo operativo foi de 4 minutos e 28 segundos. A carga parecía
así:
Ao parecer, o proceso de recuperación funciona en varios fíos, pero a eficiencia non é tan alta como a de BorgBackup, pero comparable no tempo á rsync regular.
Con urBackup Foi posible restaurar os datos en 8 minutos e 19 segundos, a carga foi
tales:
A carga aínda non é moi alta, incluso inferior á do alcatrán. Nalgúns lugares hai ráfagas, pero non máis que a carga dun núcleo.
Selección e xustificación de criterios de comparación
Como se indica nun dos artigos anteriores, o sistema de copia de seguridade debe cumprir os seguintes criterios:
- Facilidade de uso
- versatilidade
- Estabilidade
- Rapidez
Paga a pena considerar cada punto por separado con máis detalle.
Facilidade de operación
É mellor cando hai un botón "Fai todo ben", pero se volves aos programas reais, o máis cómodo será un principio de funcionamento familiar e estándar.
A maioría dos usuarios probablemente estarán mellor se non teñen que lembrar un montón de claves para cli, configurar unha morea de opcións diferentes, moitas veces escuras a través da web ou tui, ou configurar notificacións sobre un funcionamento incorrecto. Isto tamén inclúe a posibilidade de "encaixar" facilmente unha solución de copia de seguridade na infraestrutura existente, así como a automatización do proceso de copia de seguridade. Tamén existe a posibilidade de realizar a instalación mediante un xestor de paquetes, ou nun ou dous comandos como "descargar e desempaquetar". curl ссылка | sudo bash - un método complexo, xa que cómpre comprobar o que chega a través da ligazón.
Por exemplo, dos candidatos considerados, unha solución sinxela é burp, rdiff-backup e restic, que contan con teclas mnemotécnicas para diferentes modos de funcionamento. Un pouco máis complexos son borg e duplicidade. O máis difícil foi AMANDA. O resto están nalgún lugar no medio en termos de facilidade de uso. En calquera caso, se precisas máis de 30 segundos para ler o manual de usuario, ou precisas ir a Google ou a outro buscador, e tamén percorrer unha longa folla de axuda, a decisión é difícil, dun xeito ou doutro.
Algúns dos candidatos considerados poden enviar automaticamente unha mensaxe a través de e-mailjabber, mentres que outros confían en alertas configuradas no sistema. Ademais, a maioría das veces as solucións complexas non teñen unha configuración de alerta totalmente obvia. En calquera caso, se o programa de copia de seguridade produce un código de retorno distinto de cero, que o servizo do sistema entenderá correctamente para tarefas periódicas (enviarase unha mensaxe ao administrador do sistema ou directamente ao seguimento), a situación é sinxela. Pero se o sistema de copia de seguridade, que non se executa nun servidor de copia de seguridade, non se pode configurar, a forma obvia de dicir sobre o problema é que a complexidade xa é excesiva. En calquera caso, emitir avisos e outras mensaxes só á interface web ou ao rexistro é unha mala práctica, xa que a maioría das veces se ignorarán.
En canto á automatización, un programa sinxelo pode ler variables de ambiente que definen o seu modo de funcionamento, ou ben ten un cli desenvolvido que pode duplicar completamente o comportamento cando se traballa a través dunha interface web, por exemplo. Isto inclúe tamén a posibilidade de funcionamento continuo, a dispoñibilidade de oportunidades de expansión, etc.
versatilidade
Facendo eco parcialmente da subsección anterior sobre automatización, non debería ser un problema particular "encaixar" o proceso de copia de seguridade na infraestrutura existente.
Paga a pena sinalar que o uso de portos non estándar (ben, excepto a interface web) para o traballo, a implementación do cifrado de forma non estándar, o intercambio de datos mediante un protocolo non estándar son signos de non -Solución universal. Na súa meirande parte, todos os candidatos téñenas dun xeito ou doutro pola razón obvia: a sinxeleza e a versatilidade non adoitan ir xuntas. Como excepción - eructar, hai outros.
Como sinal: a capacidade de traballar usando ssh normal.
Velocidade de traballo
O punto máis polémico e polémico. Por unha banda, puxemos en marcha o proceso, funcionou o máis rápido posible e non interferiu nas tarefas principais. Por outra banda, hai un aumento no tráfico e na carga do procesador durante o período de copia de seguridade. Tamén cabe destacar que os programas máis rápidos para facer copias adoitan ser os máis pobres en funcións que son importantes para os usuarios. De novo: se para obter un ficheiro de texto desafortunado de varias decenas de bytes de tamaño cun contrasinal e, por iso, todo o servizo custa (si, si, entendo que o proceso de copia de seguridade non ten a culpa na maioría das veces aquí), e cómpre volver ler secuencialmente todos os ficheiros do repositorio ou expandir todo o arquivo: o sistema de copia de seguridade nunca é rápido. Outro punto que moitas veces se converte nun obstáculo é a velocidade de implantación dunha copia de seguridade dun arquivo. Aquí hai unha clara vantaxe para aqueles que simplemente poden copiar ou mover ficheiros ao lugar desexado sen moita manipulación (rsync, por exemplo), pero a maioría das veces o problema debe resolverse de forma organizativa, empíricamente: medindo o tempo de recuperación da copia de seguridade. e informar abertamente aos usuarios sobre isto.
Estabilidade
Debe entenderse deste xeito: por unha banda, debe ser posible implantar de novo a copia de seguridade de calquera forma, por outra parte, debe ser resistente a diversos problemas: interrupción da rede, fallo do disco, eliminación de parte do repositorio.
Comparación de ferramentas de copia de seguridade
Tempo de creación de copias
Copia tempo de recuperación
Instalación sinxela
Fácil configuración
Uso sinxelo
Automatización sinxela
Necesitas un servidor cliente?
Comprobación da integridade do repositorio
Copias diferenciais
Traballando por tubo
versatilidade
Independencia
Transparencia do repositorio
Cifrado
Compresión
Deduplicación
Interface web
Enchendo ata a nube
Soporte de Windows
Puntuación
Rsync
4 min 15 s
4 min 28 s
si
non
non
non
si
non
non
si
non
si
si
non
non
non
non
non
si
6
Tar
puro
3 min 12 s
2 min 43 s
si
non
non
non
non
non
si
si
non
si
non
non
non
non
non
non
si
8,5
gzip
9 min 37 s
3 min 19 s
si
Rdiff-backup
16 min 26 s
17 min 17 s
si
si
si
si
si
non
si
non
si
non
si
non
si
si
si
non
si
11
Rsnapshot
4 min 19 s
4 min 28 s
si
si
si
si
non
non
si
non
si
non
si
non
non
si
si
non
si
12,5
Eructar
11 min 9 s
7 min 2 s
si
non
si
si
si
si
si
non
si
si
non
non
si
non
si
non
si
10,5
Duplicidade
sen cifrado
16 min 48 s
10 min 58 s
si
si
non
si
non
si
si
non
non
si
non
si
si
non
si
non
si
11
gpg
17 min 27 s
15 min 3 s
Duplicar
sen cifrado
20 min 28 s
13 min 45 s
non
si
non
non
non
si
si
non
non
si
non
si
si
si
si
si
si
11
AES
29 min 41 s
21 min 40 s
gpg
26 min 19 s
16 min 30 s
zbackup
sen cifrado
40 min 3 s
11 min 8 s
si
si
non
non
non
si
si
si
non
si
non
si
si
si
non
non
non
10
AES
42 min 0 s
14 min 1 s
aes+lzo
18 min 9 s
6 min 19 s
BorgBackup
sen cifrado
4 min 7 s
2 min 45 s
si
si
si
si
si
si
si
si
si
si
non
si
si
si
si
non
si
16
AES
4 min 58 s
3 min 23 s
blake2
4 min 39 s
3 min 19 s
Restric
5 min 38 s
4 min 28 s
si
si
si
si
non
si
si
si
si
si
non
si
non
si
non
si
si
15,5
urBackup
8 min 21 s
8 min 19 s
si
si
si
non
si
non
si
non
si
si
non
si
si
si
si
non
si
12
Amanda
9 min 3 s
2 min 49 s
si
non
non
si
si
si
si
non
si
si
si
si
si
non
si
si
si
13
Copia de seguridade do PC
rsync
12 min 22 s
7 min 42 s
si
non
si
si
si
si
si
non
si
non
non
si
si
non
si
non
si
10,5
alcatrán
12 min 34 s
12 min 15 s
Lenda da táboa:
- Verde, tempo de funcionamento inferior a cinco minutos ou responde "Si" (excepto na columna "¿Necesitas un servidor cliente?"), 1 punto
- Amarelo, tempo de funcionamento de cinco a dez minutos, 0.5 puntos
- Vermello, o tempo de traballo é superior a dez minutos ou a resposta é "Non" (excepto a columna "Necesitas un servidor cliente?"), 0 puntos
Segundo a táboa anterior, a ferramenta de copia de seguridade máis sinxela, rápida e ao mesmo tempo cómoda e poderosa é BorgBackup. Restic ocupou o segundo lugar, o resto dos candidatos considerados situáronse aproximadamente a partes iguais cunha repartición de un ou dous puntos ao final.
Agradezo a todos os que leron a serie ata o final, convídovos a comentar as opcións e ofrecer as vosas, se as houbese. A medida que o debate avance, a mesa pode ampliarse.
O resultado da serie será o artigo final, no que se tentará desenvolver unha ferramenta de copia de seguridade ideal, rápida e manexable que permita despregar unha copia de volta no menor tempo posible e, ao mesmo tempo, ser cómoda e sinxela. para configurar e manter.
Anuncio
Copia de seguranza Parte 6: Comparación de ferramentas de copia de seguranza
Copia de seguridade Parte 7: Conclusións
Fonte: www.habr.com