Qual é o desempenho esperado de obnam? Ou: por que é tão lento?

Eu tenho brincado com o obnam nos últimos dias e, embora pareça muito promissor e pareça oferecer basicamente tudo o que eu sempre desejei em uma ferramenta de backup, estou bastante decepcionado com seu desempenho. Na verdade, é tão lento que desconfio que o obnam não tenha culpa aqui, mas algo no meu ambiente está causando isso.

Então, eu estou me perguntando principalmente, se alguém mais está usando o obnam ou conhece bem o seu interior para talvez identificar o problema.

Pelo que pude dizer até agora, o obnam parece dividir um processo individual de gpg para cada arquivo cujo backup é feito. A julgar pelo htop, strace e iostat, a velocidade de um backup inicial é limitada principalmente pela bifurcação constante, enquanto a CPU e as unidades (nenhuma rede está envolvida) geralmente ficam ociosas abaixo de 20% de utilização.

Meu backup equivale a cerca de 500.000 arquivos com 170 GiB de dados no total. Portanto, para cada execução de backup, o gpg é bifurcado 500.000 vezes. Na verdade, nem me surpreendo que isso leve quase um dia inteiro para a execução inicial e mais de três horas para outra, com a maioria dos arquivos inalterados. Mas esse é realmente o desempenho que os usuários do obnam devem esperar? Para comparação: uma execução incremental do rsnapshot (mesmos dados, mesma máquina, mesmas unidades) leva cerca de quatro minutos. Concedido, não há criptografia envolvida, mas isso não deve ser tão significativo.

Portanto, pergunte claramente: a máquina de todos os outros também não é capaz de executar o gpg (criptografando uma pequena porção de dados) mais de 50 vezes por segundo, tornando o obnam uma ferramenta quase inusoravelmente lenta? Ou é só comigo?

(FWIW, minha máquina é um Core i5-2500 com 8G de RAM e unidades SSD, executando o Gentoo. O backup é feito em um disco rígido, mas não pude observar nenhuma diferença em fazer backup no SSD, pois não é I / O -limite.)

Aqui está uma boa leitura sobre como acelerar o obnam (pode ser executado até 10 vezes mais rápido): http://listmaster.pepperfish.net/pipermail/obnam-support-obnam.org/2014-June/003086.html

Resumo: adicione "--lru-size = 1024 --upload-queue-size = 512" à sua linha de comando ou arquivo de configuração. Observe que isso aumenta um pouco o uso de memória do obnam.

Acho que atacaria esse problema de duas maneiras. Para iniciantes, eu tentaria diagnosticá-lo usando as seguintes metodologias.

1. registros obnam

Para iniciantes, você pode registrar mensagens da seguinte obnamforma:

$ obnam --log obnam.log

Você também pode aumentar o nível de registro por meio do --log-levelswitch para obter mais detalhes.

--log=FILE          write log entries to FILE (default is to not write log
                    files at all); use "syslog" to log to system log, or
                    "none" to disable logging
--log-level=LEVEL   log at LEVEL, one of debug, info, warning, error,
                    critical, fatal (default: info)

2. Perfil

Você também pode obter um perfil do que obnamestá fazendo da seguinte forma neste trecho nas Perguntas frequentes do projeto :

Se a OBNAM_PROFILEvariável de ambiente contiver um nome de arquivo, os dados de criação de perfil serão armazenados lá e poderão ser visualizados posteriormente com obnam-viewprof:

  $ OBNAM_PROFILE=obnam.prof obnam ... obnam-viewprof obnam.prof | less

Problemas de desempenho que não estão relacionados a uma instalação específica também podem ser observados usando o obnam-benchmark tool.

3. Abra um ticket

Se o desempenho ainda não for determinado por alguma investigação autodirigida, eu abriria um ticket no site do projeto . Pelo que pude reunir, o (s) desenvolvedor (es) é um pouco responsivo e provavelmente seria o melhor em resolver problemas com seu projeto.

obnamparece usar apenas SFTP, por isso deve ser bastante óbvio o que está causando o problema. Eu também consideraria a linha de base do desempenho do SFTP por si só, para que você possa ver qual deve ser o máximo teórico com sua conexão de rede do sistema + antes de tentar obter essas informações dos obnamtestes.

Pontos de dados adicionais

Encontrei este post no qual o autor fez uma comparação de várias opções nesta categoria. O artigo é intitulado: Comparando rsnapshot e obnam para backups grandes agendados .

O artigo destacou um desempenho muito ruim, o IMO, com o obnamque parece combinar com o que você está descrevendo.

desempenho obnam

Depois de fazer o backup / home completamente (o que levou vários dias!), Uma nova execução, vários dias depois, levou (tempo pelo comando time do Linux):

Backup de 3443706 arquivos, upload de 94,0 GiB em 127h48m49s com 214,2 KiB / s de velocidade média de 830 arquivos; 1,24 GiB (0 B / s) real 7668m56.628s usuário 4767m16.132s sys 162m48.739s

No arquivo de log obname:

   2012-11-17 12:41:34 INFO VFS: baseurl=/home read=0 written=0
   2012-11-21 23:09:36 INFO VFS: baseurl=/backups/backup_home read=2727031576964 written=150015706142 
   2012-11-21 23:09:36 INFO Backup performance statistics: 
   2012-11-21 23:09:36 INFO * files found: 3443706 
   2012-11-21 23:09:36 INFO * uploaded data: 100915247663 bytes (93.9846482715 GiB) 2012-11-21 23:09:36 INFO * duration: 460128.627629s 
   2012-11-21 23:09:36 INFO * average speed: 214.179341663 KiB/s
   2012-11-21 23:09:36 INFO Backup finished. 2012-11-21 23:09:36 INFO Obnam ends
   2012-11-21 23:09:36 INFO obnam version 1.2 ends normally

Então: ~ 5 dias para fazer backup de ~ 100 GB de dados alterados ... A carga não era alta nas máquinas, nem em termos de CPU, nem em termos de RAM. O uso de disco em / backups / backup_home foi de 5,7T, o uso de disco de / home foi de 6,6T, portanto, parece haver alguma redução de redundância.

desempenho do rsnapshot

Um backup completo de / home para (de acordo com o arquivo de log):

   [27/Nov/2012:12:55:31] /usr/bin/rsnapshot daily: started   
   [27/Nov/2012:12:55:31] echo 17632 > /var/run/rsnapshot.pid 
   [27/Nov/2012:12:55:31] mkdir -m 0700 -p /backups/backup_home_rsnapshot/    
   [27/Nov/2012:12:55:31] mkdir -m 0755 -p /backups/backup_home_rsnapshot/daily.0/ 
   [27/Nov/2012:12:55:31] /usr/bin/rsync -a --delete --numeric-ids --relative --delete-excluded /home /backups/backup_home_rsnapshot/daily.0/localhost/
   [28/Nov/2012:23:16:16] touch /backups/backup_home_rsnapshot/daily.0/
   [28/Nov/2012:23:16:16] rm -f /var/run/rsnapshot.pid
   [28/Nov/2012:23:16:16] /usr/bin/rsnapshot daily: completed successfully

Portanto: ~ 1,5 dias para um backup completo de 6,3 TB. Um backup incremental, um dia depois, levou:

     [29/Nov/2012:13:10:21] /usr/bin/rsnapshot daily: started
     [29/Nov/2012:13:10:21] echo 20359 > /var/run/rsnapshot.pid
     [29/Nov/2012:13:10:21] mv /backups/backup_home_rsnapshot/daily.0/ /backups/backup_home_rsnapshot/daily.1/
     [29/Nov/2012:13:10:21] mkdir -m 0755 -p /backups/backup_home_rsnapshot/daily.0/
     [29/Nov/2012:13:10:21] /usr/bin/rsync -a --delete --numeric-ids -- relative --delete-excluded --link-dest=/backups/backup_home_rsnapshot/daily.1/localhost/ /home/backups/backup_home_rsnapshot/daily.0/localhost/
     [29/Nov/2012:13:25:09] touch /backups/backup_home_rsnapshot/daily.0/
     [29/Nov/2012:13:25:09] rm -f /var/run/rsnapshot.pid
     [29/Nov/2012:13:25:09] /usr/bin/rsnapshot daily: completed successfully

Então: 15 minutos ... e os dados alterados totalizaram 21 GB.

Não é tão profundo, mas faz menção de que um dos contras de obnamé que ele é muito lento vs. attic.

Profissionais de Obnam:

• bem documentado
• lista de discussão ativa
• pacotes disponíveis

Contras de Obnam:

• muito devagar
• backups grandes

Profissionais do sótão:

• backups muito menores (mesmo sem redução de redundância)
• desduplicação muito melhor
• muito mais rapido

Contras do sótão:

• formato de repositório não documentado
• não é uma comunidade grande de usuários

Alguns dados de teste são mostrados, o que parece indicar que obnamé realmente muito lento.

Do SSD local ao HD remoto, por meio de uma conexão Wi-Fi mais ou menos:

    rsync:           0:24  0:01
    Attic ssh:       0:28  0:05
    Attic sshfs:     0:51  0:08
    Obnam sftp:      8:45  0:21
    Obnam sshfs:    25:22  0:22

Referências

• Obnam tweaks postagem no blog

A configuração padrão do Obnam (a partir de 08/02/2015) não funciona bem para fazer backup de diretórios com um grande número de arquivos pequenos. Eu tive exatamente o mesmo problema mencionado acima.

A solução para mim foi adicionar --lru-size = 8192 --upload-queue-size = 8192 à linha de comando. Isso resolveu o problema e transformou um frustrado em um usuário Obnam muito feliz. (Eu tenho essas configurações nos meus arquivos de configuração padrão agora.)

Infelizmente, o tutorial de Obnam não menciona antecipadamente a importância dessas configurações. O FAQ fornece mais detalhes. Definir os parâmetros de desempenho é realmente obrigatório em sistemas com muitos arquivos pequenos.