Eu tenho brincado com o obnam nesses últimos dias, e embora pareça muito promissor e parece oferecer basicamente tudo que eu sempre quis em uma ferramenta de backup, estou bastante desapontado com seu desempenho. Na verdade, é tão lento, eu estou suspeitando que o obnam não está mesmo em falta aqui, mas algo no meu ambiente está causando isso.
Então, estou pensando principalmente se alguém mais está usando o obnam ou conhece seus componentes internos bem o suficiente para talvez identificar o problema.
Pelo que eu pude dizer até agora, o obnam parece utilizar um processo gpg individual para cada arquivo que é submetido a backup. 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) estão praticamente inativas abaixo de 20% de utilização.
Meu backup é de aproximadamente 500.000 arquivos com um total de 170 GiB de dados. Portanto, para cada execução de backup, o gpg é bifurcado 500.000 vezes. Na verdade, não estou surpreso que isso leve quase um dia inteiro para a execução inicial e mais de três horas para outra execução com a maioria dos arquivos inalterados. Mas isso é realmente o desempenho que os usuários do obnam devem esperar? Para comparação: uma execução incremental de 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 que significativo.
Então, para perguntar claramente: a máquina de todo mundo não é capaz de rodar o gpg (criptografando um pequeno pedaço de dados) mais de 50 vezes por segundo, tornando o obnam uma ferramenta quase inutilmente lenta? Ou é só eu?
(FWIW, minha máquina é um Core i5-2500 com 8G de RAM e unidades SSD, executando o Gentoo. O backup é feito em um HDD, mas não consegui observar nenhuma diferença em fazer backup no SSD, já que não é I / O-bound.)
Aqui está uma boa leitura sobre como acelerar o obnam (pode ser executado até 10 vezes mais rápido): link
Resumo: adicione "--lru-size = 1024 --upload-queue-size = 512" à sua linha de comando ou arquivo de configuração. Note que aumenta um pouco o uso de memória do obnam.
Acho que atacaria esse problema de várias maneiras. Para começar, eu tentaria diagnosticar eu mesmo usando as seguintes metodologias.
Para começar, você pode registrar mensagens de obnam da seguinte forma:
$ obnam --log obnam.log
Você também pode aumentar o nível de registro usando a opção --log-level 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)
Você também pode obter um perfil do que o obnam está fazendo como segue neste trecho nas FAQs do projeto :
If the
OBNAM_PROFILEenvironment variable contains a file name, the profiling data gets stored there, and can be viewed later withobnam-viewprof:$ OBNAM_PROFILE=obnam.prof obnam ... obnam-viewprof obnam.prof | lessPerformance issues that are not related to a particular setup can also be observed using the
obnam-benchmark tool.
Se o desempenho ainda não for determinado fazendo uma investigação auto-dirigida, eu abro um ticket no site do projeto . Pelo que pude reunir, o (s) desenvolvedor (es) são (m) bastante sensíveis (as) e provavelmente seriam os melhores para erradicar problemas em seu projeto.
obnam parece usar apenas o SFTP, por isso deve ser bastante óbvio o que está causando o problema. Eu também consideraria baselining o desempenho do SFTP por si só, para que você possa ver qual deve ser o máximo teórico com o seu sistema + conexão de rede antes de tentar obter essas informações de obnam testes.
Encontrou este post do blog em que o autor fez uma comparação de várias opções nesta categoria. O artigo é intitulado: Comparando rsnapshot e obnam para agendamento grandes backups .
O artigo destacou um desempenho muito ruim, IMO, com obnam que parece combinar com o que você está descrevendo.
desempenho do obnam
After backing up /home completely (which took several days!), a new run, several days later took (timing by the Linux time command):
Backed up 3443706 files, uploaded 94.0 GiB in 127h48m49s at 214.2 KiB/s average speed830 files; 1.24 GiB (0 B/s) real 7668m56.628s user 4767m16.132s sys 162m48.739s
From the obname log file:
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 normallySo: ~5 days for backing up ~100 GB of changed data… Load was not high on the machines, neither in terms of CPU, nor in terms of RAM. Disk usage in /backups/backup_home was 5.7T, disk usage of /home was 6.6T, so there is some dedup, it seems.
desempenho do rsnapshot
* sótão vs. obnamA full backup of /home to (according to the log file):
[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 successfullySo: ~1.5 days for a full backup of 6.3TB. An incremental backup a day later took:
[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 successfullySo: 15 minutes... and the changed data amounted to 21GB.
Não tão completo, mas menciona que um dos contras de obnam é que ele é muito lento vs. attic .
Obnam pros:
- well documented
- active mailing list
- packages available
Obnam cons:
- very slow
- large backups
Attic pros:
- much smaller backups (even without deduplication)
- much better deduplication
- much faster
Attic cons:
- repository format not documented
- not a large user community
Alguns dados de teste são exibidos, o que parece indicar que obnam é realmente muito lento.
From local SSD to remote HD, over a so-so wifi connection:
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
Configuração padrão do Obnam (a partir de 2015-02-08) não funciona bem para fazer o 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-fila-tamanho = 8192 para a linha de comando. Isso resolveu o problema e transformou um frustrado em um usuário muito feliz da Obnam. (Eu tenho essas configurações em 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.
Tags performance backup