O rollback da replicação DFS está causando perda de arquivos e estado de backup desatualizado no Windows Server.

Question

O rollback da replicação DFS está causando perda de arquivos e estado de backup desatualizado no Windows Server.

Zenio Elando 0

Estou lidando com um problema sério em um ambiente corporativo de compartilhamento de arquivos onde usamos a Replicação DFS entre dois servidores: DC-FS01 executando o Windows Server 2008 R2 Enterprise e DC-FS02 executando o Windows Server 2019 Standard. A configuração estava funcionando normalmente em produção para compartilhamentos de arquivos departamentais até recentemente, sendo considerada estável.

Após uma reinicialização planejada de ambos os servidores em 22/02, algo inesperado aconteceu. Várias pastas replicadas por DFS pareciam ter revertido para um estado anterior, de aproximadamente 08/02. Os usuários imediatamente começaram a relatar documentos ausentes e versões antigas de arquivos sendo restauradas, o que gerou preocupações sobre uma possível perda de dados ou reversão da replicação.

O que torna essa situação ainda mais confusa é que nosso sistema de backup mostra o mesmo estado de arquivo desatualizado, mesmo nas execuções de backup bem-sucedidas mais recentes. Isso sugere que os backups também estão capturando o mesmo conjunto de dados antigo, apesar de os usuários terem criado e modificado arquivos ativamente após essa data em operações normais.

Estou tentando entender se a Replicação DFS apresenta algum comportamento relacionado a versionamento, resolução de conflitos, preparação ou latência de replicação que possa causar a sobrescrita de alterações mais recentes ou a sua não preservação adequada. Também gostaria de saber se as cópias de sombra ou os mecanismos do DFSR podem, de alguma forma, expor ou reter versões mais recentes que não são visíveis por meio da navegação normal de arquivos ou backups, e se existe alguma maneira viável de recuperar as alterações perdidas a partir da própria Replicação DFS.

Não consegui encontrar uma explicação clara para esse tipo de comportamento de "reversão para um estado anterior", então estou tentando determinar se isso está relacionado à configuração, a uma falha de replicação ou a algo mais profundo na arquitetura do DFSR.

0 comentários

2 respostas

Sua resposta

Answer 1

VPHAN 47,435 Assistente Independente

Hi Zenio Elando,

How is your issue going? Has it been resolved yet? If it has, please consider accepting the answer as it helps others sharing the same problem benefit too. Thank you :)

VP

0 comentários

Answer 2

Oi Zenio Elando,

A situação que você está descrevendo é certamente crítica, mas não é resultado do comportamento nativo de Replicação de Sistema de Arquivos Distribuído. O DFSR opera usando o diário NTFS Update Sequence Number para rastrear alterações de arquivos e não possui recursos inerentes de versionamento ou rollback que possam reverter um conjunto de dados inteiro simplesmente devido a uma reinicialização do servidor. Quando ocorre uma reversão massiva exatamente após um ciclo de reinicialização, a causa raiz aponta quase exclusivamente para a infraestrutura subjacente do hipervisor. A explicação mais provável é que um ou ambos os servidores são máquinas virtuais rodando em um snapshot, e um disco delta ativo foi descartado ou revertido durante a reinicialização. O sistema operacional então inicializava completamente sem saber que o tempo havia passado, apresentando exatamente o estado do sistema de arquivos de semanas atrás. Essa teoria de reversão de snapshot também explica sua anomalia de backup, já que o software de backup pode ter capturado o disco base congelado em vez dos arquivos de snapshot ativos onde os dados recentes dos usuários estavam sendo escritos.

Dentro da arquitetura DFSR, não há um repositório oculto que retenha semanas de dados válidos. As áreas de staging e o diretório local DfsrPrivate\ConflictAndDeleted são projetados exclusivamente para armazenar blocos temporários de arquivos em trânsito ou os arquivos perdidos devido a edições simultâneas dos usuários. Eles não podem reconstruir uma linha do tempo apagada no nível de armazenamento de blocos. Você precisa investigar imediatamente o Registro de Eventos de Replicação DFS em ambos os servidores para identificar o ID de Evento 2213 ou ID de Evento 4612. Esses eventos específicos indicam que o serviço DFSR detectou um rollback da USN, o que significa que o banco de dados interno percebe que o diário de mudanças do disco viajou inesperadamente para trás no tempo. Quando o DFSR detecta essa viagem no tempo em nível de hardware, ele intencionalmente para a replicação para evitar que o servidor desatualizado sobrescrita seu parceiro saudável.

Se apenas um dos seus servidores experimentou a reversão snapshot, os arquivos recentes dos usuários podem ainda existir intactos no outro servidor, desde que o serviço tenha se pausado a tempo. Tentar forçar o DFSR a retomar a replicação agora sem verificar qual servidor possui os dados mais precisos pode resultar em perda permanente de dados. Você deve isolar o servidor que armazena os arquivos corretos, fazer backup imediatamente e então ditar esse servidor como autoritativo assim que o problema de armazenamento subjacente for resolvido. Se ambos os servidores refletirem os dados perdidos, seu único caminho para a recuperação é analisar os arquivos de dados do hipervisor em busca de arquivos delta de disco rígido virtual órfãos. Executar uma topologia de replicação com o Windows Server 2008 R2 não suportado introduz riscos operacionais severos nesse cenário, pois carecem de salvaguardas modernas de virtualização VM-GenerationID projetadas para detectar e lidar com elegância com rollbacks de banco de dados induzidos pelo hipervisor.

Espero que essa resposta tenha trazido algumas informações úteis. Se sim, por favor, clique em "aceitar resposta". Se tiver alguma dúvida, fique à vontade para deixar um comentário.

VP