Por que é que a sincronização remota copia novamente uma pasta inteira após a reconexão?

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

A sincronização remota recopia uma pasta inteira quando o cliente já não consegue provar que os ficheiros locais e remotos são os mesmos.

Após um portátil, NAS, partilha montada ou par remoto se reconectar, o motor de sincronização pode reconstruir o seu índice, ver uma identidade de sistema de ficheiros diferente, perder hashes armazenados, detetar carimbos de data/hora alterados, tratar ficheiros renomeados como novos objetos ou comparar com uma base de dados desatualizada. O diagnóstico correto protege ambas as cópias primeiro, depois determina se o cliente está a reexaminar, recalcular hashes, a fazer novo download ou a retransmitir dados antes de reiniciar qualquer biblioteca.

Confirme se o Cliente Está a Examinar, Calcular Hashes ou a Transferir

Registe o débito de rede, leituras de disco, uso da CPU, estado do cliente e mensagens de registo durante a aparente recópia. Uma verificação completa ou passagem de soma de verificação pode parecer ocupada durante horas sem enviar a pasta completa pela internet.

Uma discussão do rclone descreve como o modo de soma de verificação pode repetir o processamento de somas de verificação em cada execução. Esse comportamento consome armazenamento e CPU, mas difere de uma verdadeira retransmissão pela rede.

Use contadores de transferência por ficheiro ou totais de pacotes para classificar o evento. Se apenas metadados e hashes forem lidos, otimize o estado da verificação; se bytes completos do conteúdo forem transferidos novamente, continue com os testes de identidade, índice, carimbo de data/hora e renomeação.

Verifique se a Base de Dados ou Índice de Sincronização Foi Reconstruído

Inspecione os registos do cliente em torno da reconexão para mensagens de migração de base de dados, corrupção, índice em falta, reinício, nova verificação ou primeira execução. Compare o diretório de configuração do cliente e o carimbo de data/hora da base de dados com a última sincronização bem-sucedida.

Um caso de suporte do Syncthing explica que uma base de dados de índice corrompida pode precisar ser reconstruída, fazendo o dispositivo comportar-se como se as pastas tivessem sido adicionadas de novo e potencialmente causando uma grande nova verificação inicial.

Faça uma cópia de segurança da base de dados antes de a eliminar ou reiniciar. Se a recópia começou imediatamente após reinstalar a aplicação, recriar o contentor, reiniciar o perfil ou perder a base de dados, preserve os dados bons e use o fluxo de trabalho suportado do cliente para reconectar a uma pasta existente.

Compare a Identidade do Ficheiro Além do Nome

Selecione vários ficheiros que o cliente quer recopiar e compare tamanho, hora de modificação, soma de verificação, permissões, propriedade, maiúsculas/minúsculas, atributos estendidos e caminho em ambos os lados. Registe qual o campo que difere.

Utilizadores do FreeFileSync discutem armazenar somas de verificação porque tamanho e carimbos de data/hora sozinhos podem não provar sempre que os ficheiros emparelhados permanecem idênticos, enquanto bases de dados de somas de verificação adicionam os seus próprios requisitos de estado. Isto ilustra porque os metadados de comparação de ficheiros são importantes após a reconexão.

Se os hashes de conteúdo coincidirem mas os carimbos de data/hora ou permissões forem diferentes, corrija o relógio, a preservação de metadados ou as definições de comparação em vez de retransmitir o conteúdo. Se os hashes forem diferentes, identifique qual o lado que é autoritário antes de permitir a sobreposição automática.

-15% OFF

Verifique se a Pasta se Reconectou com uma Identidade Diferente

Compare o caminho montado, UUID do sistema de ficheiros, nome da partilha de rede, letra da unidade, identificador do volume, montagem de contentor ou sensibilidade a maiúsculas/minúsculas antes e depois da desconexão. Um caminho de pasta familiar pode apontar para uma montagem diferente ou um diretório local vazio.

As ferramentas de sincronização frequentemente armazenam a identidade da pasta numa base de dados local em vez de confiar apenas no caminho apresentado. Uma partilha NAS remontada, disco USB substituído, volume Docker alterado ou perfil do cliente recriado pode assim parecer um destino completamente novo.

Pare a sincronização se a montagem esperada estiver ausente ou a pasta apontar para armazenamento local de reserva. Restaure a montagem original e verifique ficheiros de amostra antes de reconectar a biblioteca para evitar eliminações ou downloads duplicados.

Teste se Movimentos e Renomeações Estão a Ser Detetados

Escolha uma pasta pequena, renomeie-a enquanto ambos os pares estão conectados e observe se o cliente executa um movimento de metadados ou carrega cada ficheiro como conteúdo novo. Repita após uma desconexão e reconexão.

Uma discussão sobre funcionalidades do Syncthing nota que movimentos ou renomeações podem ser tratados como novas transferências quando a ferramenta não consegue corresponder os caminhos alterados através do seu índice existente, produzindo comportamento de eliminação e novo carregamento.

Se a recópia seguir uma renomeação de pasta a nível superior, deixe o cliente completar a troca do índice antes de fazer mais alterações. Para bibliotecas grandes, evite renomeações em massa simultâneas em múltiplos pares e mantenha a versão ou proteção de backup ativada.

Reconecte com Segurança Sem Reiniciar a Cópia Boa

Crie uma cópia de segurança ou instantâneo do lado autoritário, pause a sincronização e teste uma subpasta pequena usando a função de pasta existente ou relink do cliente. Não clique num botão genérico de reinício ou ressincronização antes de compreender a sua direção.

O guia ZimaSpace para restaurar uma pasta partilhada com segurança fornece o mesmo princípio de contenção para proteger dados não afetados.

O problema só está resolvido quando a reconexão preserva o índice, compara ficheiros existentes sem transferência de conteúdo, aplica apenas alterações genuínas e sobrevive a outra desconexão. Se a base de dados se corromper ou desaparecer repetidamente, corrija o armazenamento, desligamento, persistência do contentor ou problema de instalação do cliente em vez de aceitar sincronizações completas recorrentes.

Suporte e Dicas

Mais para Ler

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.