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

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

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