Porque é que uma tarefa de sincronização com a cloud volta a carregar ficheiros anteriormente eliminados depois de a respetiva base de dados de estado ser restaurada?
Uma base de dados de sincronização restaurada pode voltar a carregar ficheiros eliminados quando já não contém os registos de eliminação que distinguiam a remoção intencional de dados locais recentemente detetados.
A sincronização bidirecional depende de mais do que dos ficheiros atualmente visíveis. Mantém um índice ou uma base de dados com caminhos anteriores, versões, IDs de dispositivos, marcadores de eliminação e o estado da sincronização. Restaurar uma base de dados antiga mantendo ficheiros locais mais recentes ou o estado da cloud cria um desfasamento temporal: o cliente pode analisar uma cópia local sobrevivente como nova ou interpretar a eliminação remota como um conflito. Coloque todos os participantes da sincronização em pausa antes de decidir qual linha temporal é a autoridade.
Confirme Que Base de Dados e Árvore de Ficheiros Foram Restauradas
Registe a hora da cópia de segurança da base de dados, a hora da árvore de ficheiros local, o estado da cloud, a configuração do cliente, a identidade do dispositivo e o primeiro evento de novo carregamento. Verifique se a base de dados e os ficheiros vieram do mesmo ponto de recuperação.
O procedimento de restauro do Nextcloud exige o restauro da base de dados e do diretório de dados como um sistema consistente, porque restaurar apenas uma camada cria metadados que deixam de corresponder aos ficheiros armazenados.
Se a base de dados for anterior à eliminação, mas a árvore local contiver uma cópia sobrevivente mais antiga, um novo carregamento é previsível. Preserve os três estados antes de permitir outra passagem de sincronização automática.
Verifique Se os Marcadores de Eliminação Foram Revertidos
Identifique se o estado restaurado contém o evento de eliminação, a versão do ficheiro, o ID do item remoto e o dispositivo que removeu originalmente o ficheiro. Compare os registos imediatamente anteriores e posteriores à eliminação.
O Syncthing mantém uma base de dados de índice local e avisa que uma reposição da base de dados força uma análise completa e uma nova sincronização; se uma árvore de ficheiros montada mais antiga aparecer posteriormente, podem resultar versões inconsistentes.
Uma eliminação que existia apenas na base de dados mais recente fica ausente após a reversão. A análise seguinte deteta o ficheiro restante, mas não dispõe das informações históricas que indicavam que este deveria permanecer eliminado.
Reveja os Ficheiros de Listagem do Bisync ou da Sincronização Bidirecional com Estado
Para ferramentas como o Rclone Bisync, localize ambas as listagens anteriores, o diretório de trabalho, o estado do bloqueio e a última execução bem-sucedida. Não trate uma nova sincronização como equivalente à continuação a partir de um estado válido.
A documentação do Rclone indica que o Bisync mantém o estado entre execuções sucessivas e armazena os dados de trabalho separadamente das pastas sincronizadas.
Restaurar ou eliminar essas listagens pode apagar a distinção entre “eliminado desde a última execução” e “existe apenas deste lado”. Utilize uma execução de teste e guarde ambas as listagens antes de reconstruir o estado.
Atualize a Impressão Digital do Servidor Após Restaurar a Base de Dados
Verifique se a plataforma do servidor disponibiliza um marcador de recuperação que indique aos clientes que a base de dados foi restaurada. Aplique-o antes de os clientes estabelecerem novamente a ligação.
O ownCloud instrui os administradores a executar maintenance:data-fingerprint após o restauro, para que os clientes de computador e móveis possam reconhecer o estado recuperado do servidor.
Sem uma impressão digital de recuperação alterada, os clientes podem continuar a partir de pressupostos criados com base na base de dados posterior. Isto pode gerar conflitos, novos carregamentos ou tentativas de eliminar objetos restaurados no servidor.
Identifique as Cópias Locais Que Sobreviveram à Eliminação na Cloud
Pesquise em todos os dispositivos sincronizados, pastas offline, caminhos excluídos, reciclagens, diretórios de conflitos e pastas temporárias de recuperação cópias do ficheiro eliminado.
O Dropbox explica que eliminar um item pode removê-lo dos dispositivos sincronizados, mas as cópias pertencentes a outro local ou que já não participem no mesmo estado sincronizado podem permanecer.
Um ficheiro local sobrevivente torna-se candidato a carregamento quando a base de dados restaurada já não o reconhece como o objeto antigo eliminado. Calcule o hash e coloque-o em quarentena fora da raiz de sincronização antes da reconciliação.
Coloque os Clientes em Pausa Antes de Repor ou Reconstruir o Estado da Sincronização
Pare os processos de sincronização do servidor e coloque em pausa todos os clientes de sincronização de computador, móveis, contentores e tarefas agendadas. Ligue primeiro um único ponto final autorizado.
O procedimento de reposição do OneDrive da Microsoft indica que o cliente reconstrói o ficheiro DAT local, ilustrando por que motivo uma reposição altera o estado do cliente sem decidir qual versão histórica do ficheiro deve ser considerada a autoridade.
A reposição não substitui a escolha da linha temporal correta. Se vários clientes fizerem uma nova análise em simultâneo, um pode carregar uma cópia local antiga enquanto outro propaga a eliminação.
Reconcilie Uma Pasta com uma Execução de Teste e uma Cópia de Segurança Independente
Exporte a base de dados restaurada, copie todos os ficheiros locais em conflito para fora das raízes de sincronização, escolha o estado autorizado e teste uma pasta pequena antes de retomar toda a biblioteca.
O guia de cópia de segurança 3-2-1 da ZimaSpace estabelece o limite adjacente: o estado da sincronização não é uma cópia de recuperação independente quando pode repetir uma eliminação ou voltar a carregar dados obsoletos.
O problema fica resolvido quando os ficheiros eliminados permanecem eliminados, os ficheiros sobreviventes intencionais são carregados uma vez, os conflitos ficam documentados e uma segunda sincronização controlada não produz qualquer reaparecimento inesperado.
Perguntas Frequentes
Restaurar a base de dados também restaura o histórico de eliminações?
Apenas até à data da cópia de segurança da base de dados. As eliminações registadas depois desse momento ficam ausentes, a menos que outro registo ou ponto final as preserve.
Todos os clientes de sincronização devem permanecer ligados durante a recuperação?
Não. Coloque-os em pausa e ligue primeiro um único ponto final autorizado, para que os clientes mais antigos não possam reintroduzir imediatamente ficheiros obsoletos.
Uma análise completa resolverá o problema com segurança?
Uma nova análise reconstrói o que existe atualmente, mas não consegue inferir intenções históricas ausentes. Pode voltar a carregar ficheiros sobreviventes, a menos que o estado autorizado seja escolhido primeiro.
Produtos recomendados
Suporte e Dicas
Mais para Ler
Por que motivo o restauro de um volume Docker recria o conteúdo dos ficheiros, mas elimina os atributos estendidos?
Um diagnóstico da restauração de volumes que abrange o inventário de xattr, as opções do tar e do Rsync, os namespaces, o suporte do...
Porque é que um contentor em execução mantém o limite de memória antigo depois de o ficheiro Compose ser alterado?
Um diagnóstico dos limites de memória que abrange cgroups ativos, reinício versus recriação, campos do Compose, limites rígidos e flexíveis, âmbitos superiores, swap e...
Porque é que reiniciar um proxy reverso invalida todas as sessões de uma aplicação auto-hospedada?
Um diagnóstico da perda de sessão que abrange o âmbito do reinício, a propriedade dos cookies, a rotação de segredos, as sessões suportadas por...
