Restic: Backup super lento para B2

Ei, que largura de banda upstream você tem disponível? Qual é a sua localização (em termos de rede)? B2 não é o serviço mais rápido, a latência para a API (pelo menos da Europa) é bastante alta.

Como você executou o Restic exatamente?

Você verificou a largura de banda usada com ferramentas externas?

Qual taxa de transferência você obtém usando outros programas como rclone ?

anedota: eu faço backup de dois servidores idênticos, um em Nova Jersey e um na Alemanha. O primeiro leva cerca de 20 minutos e o último 90 minutos voltando para o B2.

Oi,
Adicionando meu feedback aqui. Meu servidor está em Amsterdã, a velocidade de upload é de cerca de 100 Mb / s.
Restic versão 0.7.3

Estou fazendo backup da minha pasta de dados nextcloud, com cerca de 65-70 GB de arquivos não criptografados de vários tamanhos
Criei para repositórios, um local e outro no B2. O local parece processar os dados a cerca de 5 MB / s

restic backup -r ./resticbackup /srv/nextcloud
scanned 6320 directories, 47379 files in 0:00
[2:53] 1.12%  4.326 MiB/s  748.373 MiB / 65.470 GiB  619 / 53699 items  0 errors  ETA 4:15:47

Quando eu executo o mesmo backup inicial para o B2, após uma pequena explosão, a velocidade diminui rapidamente

Esperei alguns minutos para que a velocidade diminuísse após o estouro e ficou em torno de 1 MB / s. É confirmado usando a ferramenta "nethogs" para monitorar a largura de banda por processo, o restic parece oscilar entre 500KB / se 2000KB / s

Em seguida, usei o rclone sem opções especiais para fazer upload de uma estrutura de pasta semelhante ao repositório de backup e obtive as mesmas velocidades

Ele oscilou principalmente entre 500 e 1500 KB / s durante meus testes

Então, imho, o problema não é com o restic em si, mas com o B2.

Editar:

Tentei novamente o backup com enormes conexões B2 (-o b2.connections = 50) e a velocidade aumentou drasticamente.
Atualmente estou fazendo backup a quase 10 MB / s (entre 6,5 MB e 10 MB por segundo), então o limite parece ser por conexão com a API

Isso é interessante, obrigado por nos reportar!

Acho que encontrei meu problema ao tentar um ISP diferente e receber resultados muito diferentes. Eu me pergunto, há lógica no restic para detectar conexões "mortas"?

B2 é conhecido por ter largura de banda limitada por conexão, eu também vi esse mesmo problema com outro software de backup. A solução é sempre usar várias conexões para fazer upload. Estou feliz por ter encontrado este tópico porque não sabia sobre a opção b2.connections . Onde todas as opções estão documentadas?

Eu concordo com a solução com b2.conexões, de 0,5 a 15 MB / s é um bom alívio :-)

Restic definitivamente tem potencial, mas não tenho certeza se está pronto para o horário nobre, especialmente com Backblaze.
Quando eu backup para Backblaze B2 com duplicidade, é incrivelmente rápido.
-------------- [Estatísticas de backup] --------------
StartTime 1511881648.02 (terça-feira, 28 de novembro, 10:07:28 de 2017)
EndTime 1511881650.63 (terça, 28 de novembro, 10:07:30 2017)
ElapsedTime 2,60 (2,60 segundos)
SourceFiles 10915
SourceFileSize 7991047699 (7,44 GB)

Fazer backup no Azure usando o restic é rápido, mas não tão bom quanto a duplicidade:
[0:00] 96 diretórios, 10819 arquivos, 7,441 GiB
examinou 96 diretórios, 10819 arquivos em 0:00
[0:08] 100,00% 0B / s 7,441 GiB / 7,441 GiB 10915/10915 itens 0 erros ETA 0:00
duração: 0:08, 861,53 MiB / s

E agora, para o mais lento do grupo, está fazendo backup para Backblaze B2 usando restic:
digitalizou 4 diretórios, 2.781 arquivos em 0:00
[0:23] 100,00% 24,855 MiB / s 571,663 MiB / 571,663 MiB 2785/2785 itens 0 erros ETA 0:00
duração: 0:23, 24,60 MiB / s

Não tenho armazenamento suficiente em minha conta para fazer backup do diretório de 7,4 GB no último teste como nos dois primeiros exemplos, mas de qualquer forma, você pode ver que usar duplicidade para fazer backup no Backblaze é o mais rápido.

E até mesmo ficar nervoso em 23 segundos, tive que usar as opções de conexão e especificar conexões de 500 b2.

@CurtWarfield, você pode tentar novamente com rclone e relatar de volta?

@CurtWarfield 2.6GiB / s para B2 parece meio alto. Você pode confirmar que isso é para um conjunto de dados que ainda não foi parcialmente copiado? Demora mais do que 2,5s para percorrer uma árvore de diretórios stat desse tamanho.

Se a duplicidade realmente está obtendo esse tipo de desempenho, gostaria de fazer alguns testes.

Sem kurin, essa velocidade com duplicidade está em uma ressincronização sem novos dados.

Acabei de executar um novo backup de diretório de 570 MB para B2 usando rclone conforme solicitado. O novo backup demorou 10 minutos no total, o que parece mais rápido do que com o restic.

Os backups estáticos listados também são sincronizados?

sim kurin. Leva apenas 2,6 segundos de duplicidade para uma ressincronização e o restic no Azure leva 8 segundos e o restic no B2 leva 23 segundos.
Acabei de verificar a ressincronização do B2 com rclone. rclone está mais alinhado com o desempenho do Azure.

28/11/2017 16:58:20 INFO:
Transferido: 0 Bytes (0 Bytes / s)
Erros: 0
Cheques: 2781
Transferido: 0
Tempo decorrido: 8,7 s

Ok, entendi. Eu não sou um especialista em restic internals (estou aqui para muckery B2). Acho que há um desempenho a ser extraído da transferência de dados real, mas isso não ajudaria em seus exemplos.

No entanto, seus exemplos provavelmente destacam o caso de uso mais comum, que é o backup de um conjunto de dados que está 95% + inalterado, com muitos arquivos pequenos. Seria bom se o restic pudesse identificar e pular esses arquivos rapidamente.

Devemos provavelmente dividir isso em dois bugs, um sendo específico para a largura de banda do B2, o outro sendo restic manipulando dados inalterados (se isso ainda não existir).

Ele pula os arquivos, apenas demora 12 vezes mais no B2 do que a duplicidade.
Infelizmente, o backup inicial também é lento. Mesmo usando as opções de conexões b2.

A largura de banda do B2 ainda é muito lenta usando o restic, não apenas para lidar com dados inalterados, mas também para o backup inicial.

Temos dados sobre quanto tempo o Duplicity leva para falar com o B2? 570MB em 10min é ~ 8mbps, o que já está em linha com as velocidades que vejo de restic para b2 hoje.

Vou executar o mesmo teste para um novo backup com duplicidade e postar os resultados aqui.

Obrigado!

A prova está no pudim !!!!
Então eu fiz backup do mesmo diretório do meu servidor para o MESMO balde B2 usando restic e duplicidade.
O Restic levou cerca de 12 minutos para fazer backup

Duplicidade levou apenas 4 minutos para fazer backup do mesmo diretório para o mesmo depósito B2
Data do último backup completo: nenhuma
Reutilize a PASSPHRASE configurada como SIGN_PASSPHRASE
Nenhuma assinatura encontrada, alternando para backup completo.
-------------- [Estatísticas de backup] --------------
StartTime 1511908655.75 (terça, 28 de novembro, 17:37:35 de 2017)
EndTime 1511908907.31 (terça, 28 de novembro, 17:41:47 de 2017)
ElapsedTime 251.57 (4 minutos e 11.57 segundos)
SourceFiles 2785
SourceFileSize 599784317 (572 MB)
NewFiles 2785
NewFileSize 599784317 (572 MB)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 2785
RawDeltaSize 599432061 (572 MB)
TotalDestinationSizeChange 297380160 (284 MB)
Erros 0

Executar meu script de backup pela segunda vez no balde B2 foi novamente muito mais rápido do que o restic. Portanto, não é Backblaze que é lento. De todos os meus serviços de nuvem que uso, o Backblaze é mais rápido do que todos eles. Isso inclui AWS e Google Cloud.

Data do último backup completo: terça-feira, 28 de novembro, 17:37:34 de 2017
Reutilize a PASSPHRASE configurada como SIGN_PASSPHRASE
-------------- [Estatísticas de backup] --------------
StartTime 1511909417.28 (terça, 28 de novembro, 17:50:17 de 2017)
EndTime 1511909417.76 (terça, 28 de novembro, 17:50:17 de 2017)
ElapsedTime 0,48 (0,48 segundos)
SourceFiles 2785
SourceFileSize 599784317 (572 MB)
NewFiles 0
NewFileSize 0 (0 bytes)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 0
RawDeltaSize 0 (0 bytes)
TotalDestinationSizeChange 716 (716 bytes)
Erros 0

Isso é ~ 20 Mbps, o que é totalmente alcançável hoje em dia no Restic com B2 (acabei de obter 750 Mbps de uma instância do GCE em um único arquivo grande).

Eu acredito que a maior parte disso está no manuseio de árvores de diretórios pelo Restic. Mas isso não explica a diferença entre o Azure e o B2.

@CurtWarfield desculpe por não ter perguntado isso antes: Qual versão do restic você usou em seus testes? Qual é a saída de restic version ?

O pano de fundo é que com o Restic 0.8.0, lançado há poucos dias, adicionamos um cache local para metadados. Antes disso (por exemplo, com o restic 0.7.3), ele consultaria por padrão a API do B2 para cada diretório que encontrasse, pelo menos para backups não iniciais. Então, isso é lento apenas porque a API do B2 tem uma alta latência para obter pequenos pedaços de dados.

Você se importaria de executar novamente seus testes com o restic 0.8.0 ou o branch master?
Você pode encontrar binários compilados do branch master do restic aqui: https://beta.restic.net/?sort=time&order=desc

@ fd0 tenho certeza de que ele está usando 0.8.0. Será interessante ver o que acontece quando ele usa a compilação do branch master.

Olá,
Sim, estou usando 0.8.0 :-)

Hm, eu tive pelo menos um teste de integração no Travis que falhou devido a um teste de back-end do B2 muito lento, então suponho que algo no B2 está / estava errado.

Eu gostaria de mudar todos os meus backups de duplicidade para restic, mas B2 está muito lento agora :-(

Só fiz mais alguns testes. Duplicidade e rclone são praticamente iguais no AWS, Google Cloud, Azure e B2. É apenas o B2 que apresenta desempenho de repouso lento. Até agora, preciso usar a duplicidade ou o rclone para meus baldes B2. Mas para meu AWS, nuvem do Google e baldes do Azure, posso converter em restic.

Quantas conexões b2 você configurou para usar o Restic?

Em 29 de novembro de 2017, às 20h29, "Curt Warfield" [email protected] escreveu:

Só fiz mais alguns testes. Duplicidade e rclone são praticamente iguais em
AWS, Google Cloud, Azure e B2. É apenas B2 que tem repouso lento
atuação. Até agora, preciso usar a duplicidade ou o rclone para
meus baldes B2. Mas, para minha nuvem AWS e Google, posso converter para restic.

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/restic/restic/issues/1383#issuecomment-348053433 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AHuypeS33viZDG2ols54qpdD-4m9hLhBks5s7gTfgaJpZM4QFFnO
.

Eu tentei de tudo de 1 a 500

@CurtWarfield você pode colar a invocação e a saída do restic para cada serviço?

Oh, espere, vejo que você tem um do Azure acima.

Não tenho certeza se isso é útil, mas aqui está um ponto de dados adicional
restic 0.8.0 (v0.8.0-35-g9d0f13c4)
construído a partir da fonte com go 1.9.2 linux / arm em rpi3 usando a opção -p 4

./restic -o b2.connections = 100 backup ~ / bin
Começa com largura de banda de upload saturada (~ 2-3 MiB / s) e cai rapidamente para 100-200 KiB / s para o restante do upload.

_scanned 6 diretórios, 68 arquivos em 0:00[2:19] 100,00% 137,554 KiB / s 18,672 MiB / 18,672 MiB 74/74 itens 0 erros ETA 0:00duração: 2:19, 0,13 MiB / s_

O comportamento intermitente é causado pelo fato de que a lib do cliente b2 armazena a saída antes de enviá-la (porque ele precisa enviar o hash sha1 como parte da solicitação). Para ficar tranquilo, isso se parece com uma conexão _realmente rápida_ e, em seguida, um único Write () ou Close () que bloqueia por um tempo.

No meu caso, ele funciona na velocidade de linha por exatamente 45 megas e eles diminuem a velocidade. Eu entendo que isso é buffer, mas isso é uma limitação do Restic?

Não acredito, mas não tenho certeza. Posso dizer que todos os testes que tentei em meu VPS (alguns arquivos grandes, muitos arquivos pequenos, uma quantidade média de arquivos grandes) não foram capazes de produzir uma diferença marcante para B2 em comparação com GCS, seja para uploads novos ou dados inalterados. B2 é o mais lento, mas é mais lento em uma quantidade constante, geralmente 2-5s, porque viagens de ida e volta para B2 (por exemplo, para pegar um cadeado ou gravar um instantâneo) não são tão rápidas.

.13MiB / s é pouco mais de 1Mbps, o que não é ótimo, mas é verossímil para uma conexão doméstica, e esse número deve ser bastante preciso no final do upload.

Também pode haver problemas de conexão dos quais o Restic está se recuperando automaticamente. Se você puder produzir um log de depuração (lembre-se de limpar PII), eu poderia dar uma olhada nele.

Você pode esclarecer como esse log de depuração deve ser criado?

Sim, desculpe, se você conseguir construir a partir da fonte, verifique a tag "v0.8.0" e siga as instruções em https://github.com/restic/restic/blob/master/CONTRIBUTING.md para construir um depurar binário,

• vá executar build.go -tags debug
• DEBUG_LOG = / tmp / restic-debug.log ./restic [...]

Esteja ciente de que o arquivo de log terá informações confidenciais, incluindo tokens de autenticação. Execute sed -i -e '/Authorization:.*/d' /tmp/restic-debug.log para remover informações de autenticação e sed -i -e 's/\(GET\|POST\) [^ ]\+/\1 <redacted>/' -e '/X-Bz-File-Name/d' restic-debug.log para remover nomes de arquivos, se forem confidenciais.

restic-debug_clean_scrubbed.log

Kurin,
Anexei logs de depuração que mostram o desempenho lento do B2.

Obrigado, Curt. @ fd0 deve dar uma olhada nisso também, caso haja algo acontecendo dentro do restic. Vejo muitas viagens de ida e volta do B2 à primeira vista; parece que ele está enviando muitos blocos de dados.

Uma coisa que notei são 282 solicitações de "Range: 0-0", que suspeito ser efetivamente uma chamada Stat. Eu poderia muito bem acreditar que algumas centenas deles são responsáveis ​​por empurrar um backup de segundos para minutos.

Não consigo ver nada fora do normal, desculpe. Você tentou --limit-upload ainda? Recentemente, mesclamos uma alteração que melhora muito a limitação da largura de banda ... Talvez haja algum bufferbloat em algum lugar, então algumas solicitações HTTP estão atrasadas ...

Você pode executar o teste de bufferbloat aqui? http://www.dslreports.com/speedtest

fd0,
Você pode especificar como usar a opção --limit-upload?

Uhm, como a ajuda diz:

      --limit-upload int       limits uploads to a maximum rate in KiB/s. (default: unlimited)

Para a conexão DSL em casa, tenho largura de banda de upstream de 40 Mbits (então ~ 5 MiB / s), então eu poderia especificar --limit-upload 4500 para limitar a largura de banda de upstream a ~ 4,4 MiB / se não saturar completamente o upstream.

Tentei diferentes combinações de --limit-upload e ficou pior!

Eu me pergunto se o Restic está ativando algum tipo de modelagem de tráfego de ISP. Fiquei irritado o suficiente e mudei de um provedor DSL para um cabo e não tenho mais problemas com upload.

Eu duvido que haja algum tipo de modelagem de tráfego de ISP porque é lento no trabalho (internet de nível empresarial) e em casa (300/20 TWC). Nenhuma diferença entre os dois locais. Além disso, lembre-se de que a duplicidade é extremamente rápida para Backblaze (B2)

Existem outras coisas que podem ser feitas para determinar por que existe tal discrepância de desempenho?

Talvez alguém possa dar uma olhada no código de duplicidade para ver quais chamadas estão fazendo para ter um desempenho tão rápido com B2

@curtwarfield Já que nem eu nem @kurin podemos reproduzir o que você está vendo, é possível obter acesso temporário a uma VM ou contêiner Linux em sua rede para que eu possa tentar reproduzi-lo lá? Caso contrário, não tenho nenhuma ideia de como depurar isso mais ...

Infelizmente, não tenho como fazer isso acontecer na minha localização. Então, de sua localização, a sincronização com o B2 funciona normalmente?

Sim, posso facilmente saturar minha largura de banda upstream (Alemanha) para B2 (nos EUA).

Eu apoio isso. Local: Polônia, Orange, FTTH.

@curtwarfield Existe alguma maneira de @ fd0 obter acesso temporário para reproduzir o problema? Não tenho certeza de que outra forma poderíamos progredir depurando isso.

Basta se inscrever no BackBlaze , você obtém 10 GB de armazenamento gratuito. Não tenho certeza se eles cobram por chamadas de API, mas de qualquer forma é muito mais barato do que o AWS.

Receio que seja um problema B2. Tentei o mesmo com o cliente oficial deles e a velocidade foi patética. Fora dos EUA é inútil.

er1z, eu discordo respeitosamente porque quando eu uso duplicidade com criptografia GPG para B2 é extremamente rápido. Se fosse um problema B2, seria lento com duplicidade também. Não me entenda mal. Acho que o restic é uma ótima solução para outros back-ends de nuvem, mas ainda não está pronto para o suporte B2.

@ er1z Eu também discordo. Pode ser um problema com o B2, também pode ser um caso secundário não tratado corretamente em algum lugar (biblioteca do cliente B2, biblioteca padrão Go, kernel do Linux, ...) que desencadeia esse comportamento, mas não sabemos ainda.

Deixe-me resumir este problema:

• Em certas situações (talvez dependendo da rede, mas provavelmente também da localização geográfica) backup com restic para B2 é lento
• Com duplicidade, na mesma rede, o backup para B2 é rápido
• Em outras situações (por exemplo, a conexão com a Internet em minha casa na Alemanha), sou capaz de saturar meu uplink de 40 MBit / s ao enviar novos dados de backup para o B2, então também é rápido.

Então, precisamos descobrir o que a duplicidade faz de forma diferente do restic e quais fatores influenciadores (região, rede, ...) existem. @kurin e eu tentamos fazer isso, mas sem ter acesso a essa situação de rede e ser capaz de depurar um pouco, não obteremos mais informações.

Alguém tem alguma ideia de como depurar isso ainda mais? Caso contrário, estou inclinado a encerrar este problema por enquanto. Pensamentos?

Estou no Reino Unido e, para mim, B2 para mim é mais rápido no upload inicial de um instantâneo (o primeiro) de 230 GB, mas se eu CTRL + C o upload e o inicio de novo, o progresso é muito lento quando ele chega para o estágio de upload.

Eu habilitei a depuração e uso DEBUG_FILES = b2.go, mas a saída da depuração simplesmente para e o processo parece travar (ou está indo muito devagar). Eu tenho um sistema com memória muito limitada (512 MB), então talvez seja isso.

Tentei usar DEBUG_LOG = / tmp / restic-debug.log, mas isso apenas sobrecarregou meu disco IO e tudo ficou tão lento que o sistema travou. É um ReadyNAS R102, então não é a melhor caixa de especificações.

Estou a usar:

$ restic version
debug enabled
restic 0.8.1 (2debb5c)
compiled with go1.9.2 on linux/amd64

Além de b2.go, de quais outros arquivos eu poderia obter informações de depuração relevantes?

Dito isso, eu tenho uma caixa Ubuntu 16.04 totalmente atualizada e que está na mesma rede e que funciona bem ... mas é apenas o upload de 8 GB de dados, então não é realmente muito.

Nas vezes em que tive muito pouca memória, tive um travamento em vez de apenas um travamento, então não sei se isso é relevante para você, mas você pode tentar fazer restic mais agressivamente GC definindo a variável de ambiente GOGC por exemplo, 20 quando você executa o repouso. Isso é o que eu uso em uma VM com restrição de memória onde estou executando o Restic.

Afinal de contas, o novo backup de hoje para o B2 está indo bem. Excluí o Bucket antigo e comecei do zero. Mesmo com o log de depuração indo para um arquivo tmp, as coisas estão se movendo muito bem. Eu atualizo meu binário restsic do mestre por meio de uma compilação jenkins, então sempre que você atualizar o código, meu próximo backup usará essa versão. A alteração do " Teste de tempo limite de backend Relax " ajudou?

Nas últimas 18 horas, carreguei 65 GB, o que significa cerca de 8 Mbps. Até agora, gastei $ 0,24 em transações Classe B e $ 0,10 em armazenamento.

Em meus logs de depuração, vi muitos erros "404 Not Found", seguidos por um upload desse mesmo objeto. É o mesmo no log postado anteriormente neste tópico.

Certamente isso não pode estar certo?

É assim que estamos usando a biblioteca cliente B2 agora:
https://github.com/restic/restic/blob/4eb9df63cf416c9654224cffc841a8e16a179915/internal/backend/b2/b2.go#L199 -L205

Não tenho certeza se essa é a maneira mais eficiente. Também estamos nos certificando de que o arquivo ainda não existe antes de gravá-lo.

Talvez @kurin possa dar uma olhada de onde vêm as transações de classe B ...

24c em transações de classe B é ~ 600k transações, o que parece alto. Eu sei que restic chunks de dados, mas se você assumir ~ 5 MB / chunk, deve haver apenas ~ 13k chunks em um conjunto de dados de 65 GB. As únicas transações de classe B são funções semelhantes a "stat" (get_file_info ou download_file, que usamos em vez de get_file_info por boas razões que me escapam atm). Portanto, emitir 600k deles durante uma sessão de upload parece muito. @ fd0 , o restic faz alguma manutenção em segundo plano durante o upload de blocos? Malabarismo com fechaduras, etc?

Durante o upload, não há muita coisa acontecendo. Um pouco de malabarismo de bloqueio, mas isso é como um arquivo a cada cinco minutos ou mais, deve ser insignificante. Para cada arquivo a ser carregado, Attrs() é chamado, seguido pela gravação do próprio arquivo. Hm. Não deveria haver tantas transações ...

Posso ter encontrado uma chamada redundante para uma das APIs de classe B. Vou tentar confirmar e consertar esta noite.

Os noturnos estáticos têm algumas correções que podem ajudar com esse problema: https://beta.restic.net/restic-v0.8.2-19-g9f060576/

Eu estaria interessado em ver que diferença isso faz, se houver.

Para registro, os PRs são: # 1634 # 1623

Acho que esse problema foi resolvido com 0.8.2 ou posterior, então vou fechá-lo por enquanto. Deixe um comentário se você ainda tiver uploads muito lentos com o B2 com 0.8.2 ou posterior. Obrigado!

Posso confirmar que 0.8.2 é o mais rápido para mim. A velocidade de upload varia com o B2, da mesma forma agora como faz com o S3.

No momento, estou enviando 0,01% a cada 18 segundos. Estou enviando 224 GB.

Demorou 21 horas para carregar 62%, o que é cerca de 138 GB.

Ei agora !!! Acabei de testar o 0.8.3 e finalmente está funcionando conforme o esperado !!!! Bom trabalho para os desenvolvedores.
Ainda não sei por que as pessoas não tiveram problemas com a 0.8.2, mas essa versão era definitivamente lenta para o B2. Mas estou agradavelmente satisfeito com o 0.8.3. Acabei de fazer backup de 600 MB consistindo de 2.800 arquivos em apenas 3 minutos e 20 segundos !!!!! Mais uma vez parabéns e GRANDE TRABALHO a todos os responsáveis. Você tem um vencedor!

Incrível, obrigado pelo feedback :)

Estou usando o restic há cerca de duas semanas, voltando para o B2 ( 300 GB de dados em cerca de 41.000 arquivos armazenados em um Raspberry Pi 3 B + que tem um disco USB 2TB Western Digital anexado. Minha conexão com a Internet é LTE, tenho velocidades de upload de cerca de 20-40 Mbit / s . Os primeiros 240 GB funcionaram bem em menos de um dia. Como atualmente estou reconstruindo toda a minha rede e servidores, tive que interromper o backup em cerca de 240 GB. Desde então, tentei iniciá-lo algumas vezes. Os primeiros 240GB levam cerca de 3-4 horas, não há uploads feitos, acho que só verifica os arquivos e se eles existem no balde B2. Isso é bom para uma framboesa, eu acho, pois acho que tudo se trata de calcular hashes, o que provavelmente é muito lento em um Pi. Assim que chega a arquivos novos onde os uploads são feitos, é muito lento. Isso significa cerca de 15 horas para 1 GB (os primeiros 240 GB levaram quase o mesmo tempo). Eu verifiquei quais arquivos o Restic abriu usando o lsof. Havia alguns arquivos pequenos de 3-5 MB e um arquivo grande de 2,5 GB. restic trabalhou nesses pequenos arquivos nos últimos três dias, e também o arquivo de 2,5 GB está feito. Agora ele está trabalhando apenas em arquivos grandes, cada um com cerca de 3-6 GB de tamanho, com a mesma "velocidade".

Isso soa como @ richard-scott comentou: https://github.com/restic/restic/issues/1383#issuecomment -365862475 - seu backup também estava lento quando atingiu os uploads. Acho que poderia resolver isso excluindo todos os instantâneos desse servidor e reiniciando como fez Richard-scott. Mas, enquanto meu backup estiver lento, talvez eu possa fornecer algumas informações de depuração.

Um dstat 20 poderia ser útil?

Os primeiros 240GB levam cerca de 3-4 horas, não há uploads feitos, acho que só verifica os arquivos e se eles existem no balde B2.

Aproximadamente, sim.

Havia alguns arquivos pequenos de 3-5 MB e um arquivo grande de 2,5 GB. restic trabalhou nesses pequenos arquivos nos últimos três dias, e também o arquivo de 2,5 GB está feito. Agora ele está trabalhando apenas em arquivos grandes, cada um com cerca de 3-6 GB de tamanho, com a mesma "velocidade".

Isso pode ser causado por várias coisas diferentes:

• As leituras do restic de arquivos grandes podem ter muita duplicação (por exemplo, contém apenas bytes nulos), então o restic lê um bloco de dados, então detecta que este bloco já está no repo, então ele segue para o próximo bloco sem carregar nada
• Às vezes, B2 é lento, não sabemos por quê, então talvez seja um limite na extremidade de recepção em B2 ...

Você pode testar o seguinte:

• Observe a largura de banda IO para o disco rígido, por exemplo, usando iostat . Isso muda com o tempo, quando o Restic chega ao ponto de ler novos arquivos?
• Você pode criar um segundo repo no B2 e fazer backup de alguns dados para ver se o Restic carrega mais rápido do que
• Talvez tente o branch master mais recente, nós retrabalhamos o código do arquivo completamente desde 0.8.3. Você pode encontrar binários compilados do branch master do restic aqui: https://beta.restic.net/?sort=time&order=desc

As observações de Richards podem estar relacionadas, mas isso foi com uma versão muito mais antiga do restic (0.8.1), nós melhoramos muito o manuseio de B2 desde então.

Se isso ainda for um problema, abra um novo problema para que possamos discuti-lo.

@netdesk Você já tentou definir isto:

--option b2.connections=50

Acho que o padrão é algo como 5 conexões paralelas.

Tentei a versão dev mais recente, conforme sugerido por @ fd0. Foi um pouco mais rápido (e gosto dos novos detalhes de saída) e o resto dos 300 GB estão prontos agora depois de um dia, então não posso realmente reproduzi-los. Mas antes (0.8.3 normal) o lsof mostrava dez arquivos abertos, usando a versão dev, ele abria apenas 2-3 arquivos ao mesmo tempo. Não sei quantas conexões com o B2 ele abriu. Eu fiz log iostat e vnstat a cada minuto durante o backup com a versão dev. Vou verificar os arquivos e relatar um novo problema se encontrar algo.

Agora mesmo tentei um restic check que falhou porque dizia que havia um cadeado criado há cinco dias. Esse foi o dia e a hora em que a primeira tentativa do backup de 300 GB foi interrompida. Não consigo imaginar se aquele bloqueio poderia retardar o processo de backup, apenas algo que encontrei. Como é provavelmente difícil de reproduzir agora, cavar no escuro não vale o tempo, eu acho. Como @ fd0 disse, abrirei outro problema se ocorrer novamente.

Oi,

Estou usando o Restic para fazer backup no b2, e é dolorosamente lento. Um backup de 300 GB que iniciei há cerca de 24 horas atrás ainda nem terminou. Estou usando -o b2.connections = 200, mas posso ver no máximo 4 conexões abertas e elas estão ociosas a maior parte do tempo.

Tentei hackear um pouco o código e encontrei isso . Então, fiz alguns benchmarks.

Fiz esses benchmarks nas seguintes condições:

• fast.com mediu minha velocidade de upload em 300 Mbps
• Estou fazendo backup de um disco rígido girando a 7200 RPM. hdparm reporta 175 MB / s para leituras não armazenadas em cache. Não sei medir a latência de busca, mas posso verificar se quiser.
• Estou fazendo backup de 2,8 GB, 2413 diretórios e 16155 arquivos. Quando carregados para o balde, eles ocupam apenas 1,2 GB, acho que isso se deve à compressão do Restic.
• Eu moro na França e faço upload para o b2 na região dos EUA (não fiz benchmarks completos na região da UE, mas os números pareciam ser os mesmos)
• Eu usei -o b2.connections = 200 porque mesmo com isso, o Restic usa muito poucas conexões de qualquer maneira
• Cada teste é executado em um repositório vazio
• Eu executei o restic com --no-cache, mas fui informado que caches não são compartilhados entre repositórios, então isso não deve mudar nada.
• Compilei o commit 5a7c27dd do master
• Estou usando um instável debian com linux 5.4.0

Eu ajustei duas das variáveis ​​no código vinculado acima e obtive estes resultados:

| FileRead | SaveBlob | SaveTree | Tempo total |
| --- | --- | --- | --- |
| 2 | 16 16 20 |
16 | 16 20 | 2min27s |
| 16 64 64 * 20 | 2min33s |

Parece que 2 não é um valor tão bom para este parâmetro FileRead. Se for realmente algo que dependa, talvez deva ser configurado na linha de comando. Ou talvez seja e eu perdi, por favor me diga.

Também fiz alguns testes em um SSD, mas com condições diferentes, e vi uma mudança semelhante. Alterá-lo de 2 para 8 alterou o tempo de backup de 52 minutos para 19 minutos.

Por fim, estou postando isso aqui porque acontece que estou usando o b2 e todo mundo reclamando de velocidade está usando o b2 também, então pensei que isso estivesse relacionado. Se alguém puder fazer um benchmark semelhante em outro serviço de armazenamento, poderemos saber se essa configuração realmente não é ideal para todos e não apenas para os clientes b2.

Por favor, me diga se meu raciocínio está errado ou se você tem alguma sugestão para tornar meus backups mais rápidos.

EDIT: adicionado o tamanho real do balde após o backup
EDIT2: adicionada nota sobre --no-cache
EDIT3: esclareceu que cada execução é feita em um novo repositório

O backup em um repositório de backup local muda alguma coisa em relação ao tempo necessário para o backup?

@blastrock PL aqui e mudar DC para EU aumenta drasticamente a velocidade. As velocidades dos EUA para meus sistemas eram de aproximadamente 30 KiB / s (no uplink de 20 Mbps).

Portanto, o alvo DC é o assunto mais importante.

O backup em um repositório de backup local muda alguma coisa em relação ao tempo necessário para o backup?

Um backup local da mesma pasta do HDD para o mesmo HDD, com as configurações padrão, leva 27s. Com FileReadConcurrency definido como 16, leva 19s. A diferença é menor aqui, e este teste também prova que o tempo de leitura dos arquivos é insignificante em comparação com o tempo de todo o backup para b2.

@blastrock PL aqui e mudar DC para EU aumenta drasticamente a velocidade. As velocidades dos EUA para meus sistemas eram de aproximadamente 30 KiB / s (no uplink de 20 Mbps).

Na verdade, o backup de que falo no primeiro parágrafo estava sendo feito na região da UE. Eu me confundi com as contas e fiz o benchmark nos EUA. Posso tentar executar o mesmo benchmark na região da UE, apenas para ter números comparáveis.

A diferença é menor aqui, e este teste também prova que o tempo de leitura dos arquivos é insignificante em comparação com o tempo de todo o backup para b2.

O que não entendo a esse respeito é que para SaveBlob=16 o número de FileReaders faz uma grande diferença. O upload real para o B2 está acontecendo nos encadeamentos do SaveBlob, portanto, se o upload do B2 for o gargalo, eu esperaria que o número de FileReaders não fizesse uma grande diferença.

Em que sentido --no-cache ajuda a garantir execuções comparáveis? Se você começar com um novo repositório, então não há cache para esse repositório e se o repositório já contém os dados de backup, então você apenas mede a rapidez com que o restic pode escanear o conjunto de dados de backup, caso em que o upload para B2 não seria mais o gargalo. Você liberou o cache do sistema de arquivos entre as variantes de backup ou executou uma execução de backup de aquecimento para preparar o cache do sistema de arquivos?

O que não entendo a esse respeito é que para SaveBlob = 16 o número de FileReaders faz uma grande diferença. O upload real para o B2 está acontecendo nos encadeamentos do SaveBlob, portanto, se o upload do B2 for o gargalo, eu esperaria que o número de FileReaders não fizesse uma grande diferença.

Eu concordo, mas eu realmente não sei como o Restic funciona internamente. Com SaveBlob = 16 e b2.connections = 200, só consigo ver 4-5 conexões do Restic, e a maioria delas está ociosa. Portanto, meu palpite era que a parte "salvando" não estava recebendo dados suficientes e, de alguma forma, a parte "lendo" estava esperando que a parte "salvando" concluísse seu trabalho em vez de apenas enviar mais.

Se você começar com um novo repositório, então não há cache para esse repositório

Ai, que coisa, pensei que alguma parte do cache fosse compartilhada entre repositórios, como carimbos de data / hora de modificação de arquivo. Comecei com um novo repositório para cada teste. Vou editar minha postagem para esclarecer isso.

Você liberou o cache do sistema de arquivos entre as variantes de backup ou executou uma execução de backup de aquecimento para preparar o cache do sistema de arquivos?

Eu não pensei sobre isso na verdade ^^
Acabei de executar novamente o mesmo teste com FileRead = 2 duas vezes (para ter certeza de que o cache está aquecido) e obtive 6min12s e 6min00s desta vez. Não exatamente nos mesmos tempos de antes, mas ainda assim ruim. Executei novamente o teste logo depois disso com FileRead = 16 e consegui 2min00s.

Acho que isso é de fato um problema de desempenho em repouso. Cada file_saver divide um arquivo em pedaços e os passa para o blob_saver. Um file_saver só continua com o próximo arquivo depois que todos os fragmentos foram carregados. O armazenamento de um blob pode ser rápido, se o pacote ainda não estiver concluído, ou lento, se o pacote for finalizado e carregado. Ou em outras palavras, o file_saver e o blob_saver não estão completamente separados. Para arquivos pequenos, o paralelismo efetivo carregado é limitado a FileRead .

Em minha opinião, isso justifica seu próprio problema, por favor, você poderia abrir um novo problema e adicionar suas observações a ele? Você também poderia tentar quanto tempo leva para fazer upload de um arquivo de 1 GB contendo dados aleatórios (por exemplo, dd if=/dev/urandom of=test bs=1m count=1024 )? Eu esperava que isso acabasse na faixa de 2 minutos.