O Que Verificar Após a Execução da Recuperação do Sistema

O procedimento de recuperação recria o sistema antigo usando os dados de quorum. Entretanto, algumas coisas não podem ser restauradas, tais como os dados em cache ou os dados do sistema gerenciando E/S em andamento. Essa última perda de estado afeta matrizes RAID que gerenciam armazenamento interno. O mapa detalhado sobre onde os dados estão fora de sincronização foi perdido, o que significa que todas as informações de paridade precisam ser restauradas e que os pares espelhados precisam ser sincronizados novamente. Normalmente, esta ação resulta em dados antigos ou obsoletos sendo usados, de modo que apenas gravações em andamento são afetadas. Entretanto, se a matriz tiver perdido redundância (tal como o status em sincronização, comprometido ou RAID crítico) antes do erro que requer recuperação do sistema, então, a situação é mais grave. Nessa situação, é necessário verificar o armazenamento interno:

• As matrizes de paridade provavelmente serão sincronizadas para restaurar a paridade; elas não têm redundância quando essa operação continua.
• Como não há redundância nesse processo, bloqueios inválidos podem ser criados onde os dados não estão acessíveis.
• As matrizes de paridade podem ser marcadas como corrompidas. Isso indica que a extensão dos dados perdidos é mais ampla do que a E/S em andamento; para colocar a matriz on-line, a perda de dados deve ser reconhecida.
• As matrizes RAID6 que foram realmente degradadas antes da recuperação do sistema podem requerer uma restauração completa do backup. Por esse motivo, é importante ter, no mínimo, uma correspondência de capacidade sobressalente disponível.

Esteja ciente destas diferenças sobre a configuração recuperada:

• Mapeamentos FlashCopy são restaurados como idle_or_copied com progresso de 0%. Ambos os volumes devem ser restaurados para seus grupos de E/S originais.
• O ID de gerenciamento é diferente. Quaisquer scripts ou programas associados que se referem ao ID do sistema de gerenciamento do sistema devem ser alterados.
• Todos os mapeamentos FlashCopy que não estavam no estado idle_or_copied com 100% de progresso no ponto de desastre têm dados inconsistentes nos seus discos de destino. Esses mapeamentos devem ser reiniciados.
• As parcerias e os relacionamentos intersistema não são restaurados e devem ser recriados manualmente.
• Os grupos de consistências não são restaurados e devem ser recriados manualmente.
• Relacionamentos do Metro Mirror intrassistema serão restaurados se todas as dependências tiverem sido restauradas para seus grupos de E/S originais.
• Os volumes com capturas instantâneas de nuvem que foram ativados antes da recuperação precisam ter as capturas instantâneas de nuvem reativadas manualmente.
• Se o hardware foi substituído antes da recuperação, o certificado SSL poderá não ser restaurado. Se ele não for restaurado, um novo certificado autoassinado será gerado com uma validade de 30 dias. Siga o Directed Maintenance Procedures (DMP) para obter uma resolução permanente.
• O fuso horário do sistema pode não ter sido restaurado.
• Quaisquer volumes secundários Global Mirror no sistema recuperado podem ter dados inconsistentes se ocorreu E/S de replicação do volume primário que foi armazenado em cache no sistema secundário no ponto de desastre. Uma sincronização completa é necessária ao recriar e reiniciar esses relacionamentos.
• Imediatamente após a execução do processo de recuperação T3, que são discos compactados que não conhecem o valor correto de sua capacidade usada. Os discos inicialmente configuram a capacidade como a capacidade real inteira. Quando a E/S continua, a capacidade é reduzida para o valor correto.

  Um comportamento semelhante ocorre quando você usa a opção -autoexpand nos volumes. A capacidade real de um disco pode aumentar ligeiramente devido ao mesmo tipo de comportamento que afeta os volumes compactados. Novamente, a capacidade é reduzida conforme a E/S para o disco continua.

Antes de usar os volumes, conclua as tarefas a seguir:

• Inicie os sistemas host.
• Ações manuais podem ser necessárias nos hosts para acioná-los para varrer novamente os dispositivos. É possível concluir essa tarefa ao desconectar e reconectar os cabos Fibre Channel em cada porta do adaptador de barramento de host (HBA).
• Verifique se todos os volumes mapeados podem ser acessados pelos hosts.
• Execute verificações de consistência do sistema de arquivos.
  Nota: Os dados que estavam no cache de gravação do sistema no momento da falha são perdidos.
• Execute verificações de consistência do aplicativo.

Mapeamentos de FlashCopy não são restaurados para VVols. As implicações são as seguintes.

• Os mapeamentos que descrevem os relacionamentos de captura instantânea da VM são perdidos. No entanto, os Volumes Virtuais que estão associados a essas capturas instantâneas ainda existem e as capturas instantâneas ainda podem aparecer no Web client do vSphere. Esse resultado pode ter implicações em sua solução de backup VMware.
  • Não tente reverter para capturas instantâneas.
  • Use o Web client do vSphere para excluir quaisquer capturas instantâneas para VMs em um armazenamento de dados VVol para liberar espaço em disco que estiver sendo usado desnecessariamente.
• Os destinos de qualquer relacionamento FlashCopy de 'clone' pendente poderão não funcionar conforme esperado (mesmo que o vSphere Web Client tenha recentemente relatado operações de clone como concluídas). Para quaisquer VMs, que são destinos de operações de clone recentes, conclua as seguintes tarefas.
  • Execute as verificações de integridade de dados conforme recomendado para volumes convencionais.
  • Se os clones não funcionarem conforme esperado ou se mostrar sinais de dados corrompidos, obtenha um clone atualizado da VM de origem para garantir que a integridade de dados seja mantida.