Problemas com DFSR - Não Replica
Autor: Robson Del Angelo | Publicado: 2012-11-22T11:45:00-02:00

Dia desses consegui um problema FDP. Simplesmente os servidores de arquivo não estavam mais realizando a sincronização entre as pastas compartilhadas. O meu ambiente estava configurado da seguinte forma: 2 servidores de arquivo, executando "NAMESPACE"&nbsp; e "Replicação DFS", nomeados a partir de agora de fs1 e fs2. Nestes servidores tenho vários "GRUPOS DE REPLICAÇÃO".

Meu problema era seguinte: apenas um "GRUPO DE REPLICAÇÃO" não funcionava e o mais estranho, apenas em uma via, ou seja, quando fazia a alteração no fs2 ela era replicada imediatamente para o fs1, mas o contrário não acontecia.

Realizei os seguintes passos:

1 - Chequei a topologia. OK, estava tudo conectado e pronto para replicação;

2 - Criei um "Relatório de Diagnóstico" para verificar obtive um erro;

3 - De olho no "Event Viewer" observei vários eventos 4304* (Violação de Compartilhamento);


4 - Como tive alguns problemas com o Symantec Backup Exec e Replicaçaõ DFSR, minha primeira tentiva foi "PARAR" o "Agente do Backup Exec". Em seguinda reiniciei o "Serviço de Replicação". Nada aconteceu;

5 - Próximo, sincronizei os horários dos "Servidores de Arquivos" com o "Controlador de Dóminio". Nada;

6 - Parei o serviço de Anti-Vírus. NADA.

7 - Nesse ponto, precisa realmente saber o que estava acontecendo, ou seja, monitorar a "Replicação DFS". Fui para Internet e encontrei um programa chamado DfsrMon (no site tem um How to), e através dele consegui descobir que "Backlog" do fs1 para o fs2 estava com mais de 10000 versões sem atualização, ou seja, havia mais de 10000 arquivos para serem replicados.

8 - Neste ponto, eu precisava saber quais eram estes arquivos. Com algumas pesquisas descobri que existe o cmdlet dfsrdiag, um "irmão" do dcdiag. Com um simples leitura no Help dele no próprio CMD, consegui executar os comandos abaixo que me ajudaram na tarefa de saber quais arquivos estavam "entupindo" a replciação.

8.1 - Verifica o backlog da Pasta replicada entre o SenderServer e ReceiverServer
dfsrdiag backlog /SendingMember:fs1 /ReceivingMember:fs2 /RGName:Deptos /RFName:"Deptos" /v

8.2 - Verifica arquivos que esão sendo "baixados" e arquivos que estão na "lista de espera"
dfsrdiag replicationstate /Member:fs1 /V 

9 - Quando executei o arquivos acima percebi que havia uma série de arquivos *.mp3; *.wav, etc aguardando o envio. Neste momento liguei os pontos. Como havia configurado "COTA" e "TRIAGEM" para os arquivos, poderia ser este o problema.

10 - Chequei todas as "COTAS" e incrementei as que estavam "penduradas".

11 - Marquei a "Triagem de Arquivos" para tipo "PASSIVO" (apenas avisa, mas não bloqueia).

12 - Executei o comando para visuarlizar a lista de arquivos "presos" mencionado acima no CMD e percebi nas primeira linhas que alguns deles estava com o sufixo ("Baixando").

13 - Através da Ferramenta DfsrMon, pude confirmar que o "BackLog" começou a baixar rapidamente. UFA.

14 - De olho os Logs do "Event Viewer" recebi mais um evento diferente (4202). Esse evento comunicava algo relacionado com "Espaço de Preparação está acima da marca d´água alta". Como havia pesquisado muita coisa antes, este problema foi fácil de resolver.

14.1&nbsp; - Na ferramenta "Gerenciamento DFS" no grupo "Replicação", marque o "Grupo de Replicação" com problema e navegue para a ABA "Associações" no painel central. Você irá visualizar uma tal de "Cota de Preparação". É este "cara" que deve ser alerado. Clique com o botão da diretita sobre a "Pasta Replicada" e escolha "Propriedades". Vá para aba "Preparação" e incremente um pouco mais a "Cota". No meu caso aumentei de 4GB para 6GB.

Até a próxima.

* Em pesquisas realizadas, descobri que este evento ocorre quando se tem um número muito grande de "alterações" nos arquivos e estas alterações não têm tempo suficiente para serem replicadas.