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.
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

How to Reduce Plex Database Contention on a Busy Docker Host
A Plex configuration guide for busy hosts that treats the database as local application state and reduces I/O contention without inventing a shared DB...

How to Prevent Duplicate Plex Scans and Imports
A prevention guide for duplicate Plex scans and imports that removes overlapping triggers instead of disabling library updates entirely.

How to Recover Plex After Its App-Data Volume Fills Up
A recovery ladder for full Plex app-data volumes that protects the database first and avoids deleting unknown files just to make the service start.

