A solução para este problema foi, para mim, parar de usar o s3cmd e começar a usar a ferramenta aws.
em vez de s3cmd sync ... , agora uso aws s3 sync ... . Isso funciona como um encanto. Eu gostaria de nunca ter encontrado o s3cmd.
Como parte de uma solução de backup, estou usando o s3cmd para transferir uma carga de arquivos.
Eu tenho quatro trabalhos diferentes com diretórios de diferentes tamanhos e arquivos de tamanhos diferentes.
Três dos trabalhos funcionam bem. O último trabalho, no entanto, trava na mensagem:
Retrieving list of remote files for <...>
E quando digo que trava, quero dizer que não vai mais longe. Ele ficou congelado assim por uma semana inteira em uma conexão de internet de escritório 100% estável.
Agora, o diretório que ele está tentando enviar é grande. Cerca de 306 GB. Este é de longe o maior dos empregos.
Eu vi um post no StackOverflow com um problema semelhante (não idêntico) a este, e a resposta aceita dizia editar o .s3cfg e definir um socket_timeout maior. Eu mudei de 10 para 180, mas isso não fez diferença.
Alguma ideia do que tentar em seguida? Eu falhei no googling.
À medida que o diretório de destino se torna grande, o tempo para recuperar a lista de md5 e os dados de tamanho aumentam.
Para mim, backups semelhantes estão concluindo essa etapa em menos de vinte minutos. Percebo que tenho o socket_timeout configurado para 300.
Você também pode evitar a varredura md5 de cada arquivo no intervalo de destino usando --no-check-md5, mas não achei necessário fazer isso.