Restic: Lento, embora esteja apenas verificando os carimbos de data e hora
Eu tenho 164809 arquivos para fazer backup regularmente (cerca de 60GB)... Toda vez que eu executo "backup restic" o relatório não vai além de 33MB/s e verificando com strace ele está apenas fazendo chamadas lstat().
Isso renderiza cerca de 20 minutos por backup. Eu me pergunto o que o restic está fazendo, pois sendo quase todos os arquivos não modificados, ele mostra os 33MB/s constantes e entendo que ele precisa apenas lstat() deles, que é exatamente o que o restic já faz na primeira etapa do backup apenas para mostrar o tamanho total, em 6 ou 7 segundos.
É apenas o tempo de CPU gasto na verificação do conteúdo desse mesmo arquivo/timestamp que já está presente em um instantâneo anterior restic?
viric
Todos 5 comentários
No momento, os metadados dos arquivos e diretórios não são armazenados em cache, mas carregados (e descriptografados) do repositório. Isso é feito uma vez por diretório. Estou planejando armazenar metadados em cache localmente, o que ainda não foi implementado, mas deve acelerar bastante os backups "incrementais".
fd0
em 19 fev. 2016
Oi
Isso também pode causar baixo desempenho para backups incrementais em uma conexão WAN lenta?
Acabei de fazer backup de uma pasta com algo mais de 9000 arquivos e 250 MB para um servidor s3 remoto. Ambos os computadores estão conectados com uma conexão de internet assimétrica de 50/5 mbit/s para baixo e para cima.
O backup inicial levou cerca de 5 minutos e parecia bastante razoável. Mas um segundo backup logo depois levou quase o dobro do tempo! Uma pasta com menos arquivos parece ser muito mais rápida.
Kidswiss
em 13 ago. 2016
Sim, provavelmente esse será o motivo. Para este caso de uso específico, há uma solução alternativa: use a opção -f ( --force ) para o comando backup , que lerá todos os arquivos localmente novamente e não carregará metadados do repositório . Isso deve ser rápido.
fd0
em 13 ago. 2016
Muito obrigado! Funciona como um encanto!
Kidswiss
em 13 ago. 2016
Adicionamos um cache de metadados local (consulte #1040) no branch master, acho que esse problema foi resolvido e, portanto, estou fechando. Obrigado!
fd0
em 26 set. 2017
Questões relacionadas
rakor
·
5Comentários
RafaelAybar
·
3Comentários
fd0
·
3Comentários
McKael
·
4Comentários
kontakm
·
4Comentários
Comentários muito úteis
Sim, provavelmente esse será o motivo. Para este caso de uso específico, há uma solução alternativa: use a opção
-f(--force) para o comandobackup, que lerá todos os arquivos localmente novamente e não carregará metadados do repositório . Isso deve ser rápido.