Resultado de restic version

restic 0.8.2

Como você executou o Restic exatamente?

% restic -r /tmp/restictest backup $SSHFSMOUNT/directory

O diretório de backup é um sistema de arquivos montado sshfs.
O comando é executado várias vezes para fazer vários instantâneos.
Neste caso, há uma grande quantidade de dados (1 TB +) no diretório remoto.

Qual backend / servidor / serviço você usou para armazenar o repositório?

Sistema de arquivos ext4 local.

Comportamento esperado

Espero que o primeiro backup seja lento e transfira muitos dados pela LAN, enquanto os próximos backups devem ser bem rápidos e não devem usar muita largura de banda.

Comportamento real

Todos os backups levam horas (se não dias), mesmo que nenhum arquivo tenha sido alterado.

Passos para reproduzir o comportamento

• execute um backup
• desmontar sistema de arquivos sshfs
• remontar o sistema de arquivos sshfs
• execute um novo backup

Não é 100% reproduzível mas mesmo com uma pequena quantidade de dados consegui reproduzi-lo.

Os logs do servidor SFTP mostram que os arquivos são completamente recuperados, mesmo quando não foram alterados.

Você tem alguma ideia do que pode ter causado isso?

Sim: o restic compara os inodes para verificar se os arquivos foram modificados (mensagem de depuração "timestamp, tamanho ou inode alterado", restic/node.go:551restic.(*Node).IsNewer11node ).

No entanto, os inodes podem mudar nas montagens do sistema de arquivos com sshfs (e provavelmente alguns outros sistemas de arquivos).

Você tem uma ideia de como resolver o problema?

Comentar a verificação de inode resolveu o problema para mim.

Eu gostaria de ter uma maneira de desabilitar essa verificação; talvez um sinalizador de linha de comando?

O restic o ajudou ou o fez feliz de alguma forma?

Claro, é um bom software! Estou ainda mais satisfeito porque encontrei uma solução alternativa ...
Mantenha o bom trabalho!