Data Domain: O file system do DDFSY entra em pane se a replicação de MTREE estiver configurada para a unidade de armazenamento Veeam DDBOOST

Ao usar o VEEAM ou qualquer outro aplicativo de backup que usa o BOOST para realizar backups, ele cria novos backups a partir dos existentes, unindo partes dos backups anteriores no DD e, em seguida, adiciona as diferenças. Os backups anteriores usados para a combinação são chamados de "arquivos de base".

A maioria dos aplicativos de backup lerá, mas não modificará os arquivos de base usados para o synthesizing de novas imagens de backup. No entanto, o VEEAM funciona de maneira diferente. Ao realizar backups, ele sobregrava partes dos arquivos de base já em disco.

Quando a replicação de saída de MTree é configurada para esse LSU/MTree do VEEAM, é possível que um arquivo de backup que está sendo replicado seja modificado pelo BOOST durante a duplicação de novos arquivos de backup. Se o DD de origem estiver executando o DDOS 6.x e a replicação de receita estiver ativada (uma opção de otimização de velocidade/desempenho no DDOS 6.x e posterior), isso poderá resultar na chegada de checksums incorretos no DD de destino, o que pode fazer com que o FS (File System) falhe repetidamente com mensagens como as seguintes:

27 fev 04:05:19 mtree-repl-dd.example.com ddfs[10654]: ERROR: MSG-INTRNL-00001: PANIC: ddr/repl/mrepl_replica.c: mrepl_finish_file_transfer_common: 3712: ! (orig_chksum == repl_chksum).

A maneira como o VEEAM sintetiza novos backups a partir dos existentes, pode haver sobregravações de algumas partes dos arquivos que estão sendo replicados quando usados como um arquivo base para o synthesizing de novas imagens de backup. Isso cria confusão para a replicação de receita quando a unidade de armazenamento VEEAM também está configurada para ser usada como parte da replicação de MTree, possivelmente causando o DD de destino para PANIC.

Observe que esse defeito só se aplica à extremidade de destino para replicação de MTree quando a origem é:

• Executar o DDOS 6.0.1.0 ou anterior (por exemplo, todos os DDOS 6.0.0.x seriam afetados)
• Executando o DDOS 6.x anterior ao DDOS 6.0.2.0 ou 6.1.1.1
• Executando backups do VEEAM em um LSU/MTree, e esse mesmo MTree está sendo replicado para o destino usando a replicação de MTree
• Backups do BOOST com sintéticos virtuais ativados são executados na mesma LSU/MTree
•  Quando esse defeito é encontrado, isso pode fazer com que o MTree de destino replicado se torne indisponível com várias reinicializações do processo de FS. Aqueles que podem estar usando essa configuração ou planejam configurar seus sistemas dessa maneira são incentivados a empregar a solução temporária explicada abaixo ou fazer upgrade para o DDOS 6.0.2.0 ou 6.1.1.1 fixo (ou qualquer versão posterior).

Nota: é possível que a mesma string PANIC na extremidade de destino para replicação de MTree possa ocorrer para problemas diferentes desse, pois o erro simplesmente indica que um checksum no snapshot de replicação de MTree não correspondeu. Em caso de dúvidas sobre o problema descrito aqui ou sobre como contornar um problema, entre em contato com o provedor de suporte contratado e consulte o número deste artigo da base de conhecimento 491049 .

A engenharia do DD identificou a causa raiz dos PANICs do FS no nó de destino e comprometeu-se com uma correção nas seguintes versões:

• DDOS 6.0.2.0 e posterior
• DDOS 6.1.1.1 e posterior

Qualquer pessoa afetada por esse defeito ou que esteja planejando configurar uma configuração semelhante é aconselhada a fazer upgrade do DD de origem para as versões mencionadas o quanto antes.

Para aqueles que não estão dispostos a fazer upgrade ou que enfrentam o problema antes que a versão fixa se torne disponível, há uma solução temporária.
Ele consiste em desativar a otimização da replicação de receita no sistema DDOS 6.x de origem.
Essa otimização só está presente no DDOS 6.x e posterior, a única desvantagem de desativá-la seria reduzir as velocidades de replicação para ser igual às alcançadas no DDOS 5.7.

Antes da implementação, você deve primeiro confirmar se essa solução temporária seria aplicável à configuração atual:

1. Verifique se o DD de origem está executando o DDOS 6.x antes da versão que corrigiu esse problema (bug corrigido no DDOS 6.0.2.0 e 6.1.1.1 em diante)
2. Confirme se o DD configurado para backups do VEEAM também está configurado para replicação de MTree para o LSU/MTree sujeito como origem (verificar um ASUP recente seria a maneira mais fácil de confirmar), por exemplo:

CTX: Modo 20: origem Destino: mtree://destination-dd.example.com/data/col1/destination_MTree Ativado: sim

 Se todas essas condições acima se aplicarem, esse sistema pode estar sujeito aos defeitos mencionados anteriormente e pode fazer com que o FS de replicação de destino eventualmente trave.

Para aplicar a solução temporária, é necessário primeiro garantir que não haja backups de replicação ou BOOST em execução e, em seguida, fazer a alteração da configuração do registro, o que não requer tempo de inatividade. Antes de iniciar esse processo, leia a declaração DE CUIDADO localizada abaixo da etapa final deste procedimento.

1. Certifique-se de que a replicação do DD para o DD esteja desativada no DD de origem que executa o DDOS 6.x:

# replicação desabilitar tudo

2. Além disso, certifique-se de que não haja backups do BOOST em andamento nem MFR do VEEAM LSU/MTree possivelmente com problema antes de aplicar a configuração do registro. Se necessário, desative temporariamente os backups e a MFR para ou a partir desta LSU:

# ddboost file-replication show active all
# ddboost file-replication show stats

3. Essa alteração de registro requer privilégios de modo SE.

4. No modo SE, altere a configuração do registro para desativar o uso da replicação de receita:

# se sysparam set RECIPE_REPL_ENABLED=FALSE

5. Confirme se o parâmetro do sistema foi definido corretamente e está sendo exibido como "FALSE" (desativado)

# se sysparam show RECIPE_REPL_ENABLED
Substituição padrão atual da descrição do nome
-------------------   ------------------------------------------------   -------   -------   --------
RECIPE_REPL_ENABLED habilitar a replicação de receita (aplicar apenas à origem) FALSE TRUE rpc
-------------------   ------------------------------------------------   -------   -------   --------

6. Agora você pode reativar o DD para a replicação do DD e retomar os backups do BOOST e a MFR do BOOST para ou a partir da LSU:

# replicação habilitar tudo

CUIDADO: Se o processamento de receitas tiver sido desativado em um sistema de origem do Data Domain que também esteja configurado como uma extremidade de destino para replicação, os sistemas de origem para esses contextos também precisarão ter o processo acima executado (replicação de receita desativada).

Observe também que, após o upgrade para uma versão fixa (DDOS 6.0.2.0 ou 6.1.1.1), a configuração precisará ser restaurada para que a replicação de receita possa ser aproveitada, o upgrade não redefinirá a chave de registro. Depois de concluir o upgrade, reativar a replicação de receita fazendo log-in no DD, entre no modo de privilégio se e execute:

  # se sysparam reset RECIPE_REPL_ENABLED

Se não tiver certeza do processo descrito acima, entre em contato com seu provedor de suporte contratado e consulte este artigo da KB 491049 artigo.

Há sempre a possibilidade de que os PANICs sejam devido a um problema diferente e a solução temporária aplicada pode não funcionar enquanto as PANEs do FS no DD de destino continuam.

Nesse caso, a recomendação é ter os DDs de origem e destino atualizados para código seguro (versões do DDOS mencionadas acima) e que os contextos de replicação com defeito sejam quebrados (não configurados), os snapshots existentes expirados e os contextos de replicação sejam adicionados e reinicializados novamente. Como esse é um processo potencialmente demorado e pode haver vários contextos de replicação que podem ser a causa do problema, entre em contato com seu provedor de suporte contratado e consulte o número deste artigo da KB e todas as ações realizadas até o momento para obter assistência.