Reparando conjuntos de armazenamentos a partir de um servidor de replicação de destino após um desastre

Editar on-line

Em caso de desastre em um servidor de replicação de origem, é possível reparar as extensões de dados deduplicados em um conjunto de armazenamentos de contêiner de diretório a partir de um servidor de replicação de destino.

Antes de iniciar

Execute as seguintes etapas:

Faça backup do banco de dados do servidor IBM Storage Protect usando um dos métodos a seguir:
- Na página Operations Center Overviews , clique em Servidores, selecione um servidor e clique em Backup.
- Emita o comando administrativo BACKUP DB.
Revise as informações mais recentes sobre como reparar e recuperar dados na nota técnica 2013682.
Para planejar as próximas etapas, revise as restrições a seguir sobre o uso do comando AUDIT CONTAINER.
Atenção:
- Se você emitir o comando AUDIT CONTAINER com a configuração ACTION=MARKDAMAGED para um conjunto de armazenamentos inteiro, os dados referenciados ficarão indisponíveis para operações de restauração até que o conjunto de armazenamentos ser reparado. Dependendo do tamanho do banco de dados, a largura da banda da rede, a velocidade de mídia e outros fatores, o comando REPAIR STGPOOL pode ser executado por horas ou dias. Por essa razão, se alguns dos dados no conjunto de armazenamentos estão disponíveis ou o status dos dados no conjunto de armazenamentos é desconhecido, siga estas diretrizes:
  1. Considere executar o comando AUDIT CONTAINER com a configuração ACTION=SCANALL primeiro. A configuração ACTION=SCANALL identifica os registros do banco de dados que se referem a inconsistências nas extensões de dados. Somente essas extensões de dados são marcadas como danificadas no banco de dados.
  2. Após as extensões serem marcadas como danificadas, é possível executar o comando REPAIR STGPOOL.
- Se você planeja executar o comando AUDIT CONTAINER com a configuração ACTION=REMOVEDAMAGED, siga estas diretrizes:
  1. Considere executar o comando QUERY DAMAGED primeiro para determinar o escopo de extensões de dados danificados no conjunto de armazenamentos.
  2. Depois disso, é possível executar o comando REPAIR STGPOOL para reparar extensões danificadas no conjunto de armazenamentos.
  3. Finalmente, é possível executar o comando AUDIT CONTAINER com a configuração ACTION=REMOVEDAMAGED para remover quaisquer extensões de dados danificados que permanecem no conjunto de armazenamentos.

Sobre esta tarefa

Use o procedimento para reparar os tipos de dano grave a seguir:

Perda completa de todos os conjuntos de armazenamentos de contêiner no servidor de replicação de origem
Perda completa do site primário

As suposições a seguir são feitas para este cenário de recuperação de desastre:

Você estava usando o comando PROTECT STGPOOL ou uma ou mais regras de armazenamento de replicação para fazer backup de dados de um servidor de replicação de origem para um servidor de replicação de destino. O servidor de replicação de destino está em execução em seu site de recuperação.
Você estava usando o comando PROTECT STGPOOL ou uma ou mais regras de armazenamento de replicação para fazer backup de dados para conjuntos de armazenamentos de cópia em contêiner externo.
Se você replicar dados usando regras de armazenamento de replicação, os dados são replicados em um conjunto de armazenamentos de contêiner e não são dispostos em camadas por meio do conjunto de armazenamentos de contêiner no servidor de replicação de destino.
Se você usou o IBM Storage Protect Blueprints para configurar o servidor de replicação de origem IBM Storage Protect , também usará os scripts de configuração de blueprint para restaurar o ambiente configurando um novo servidor de replicação de destino em um site de recuperação. Os scripts copiaram versões de backup do banco de dados IBM Storage Protect , do arquivo de opções do servidor (dsmserv.opt), do arquivo histórico do volume (volhist.out) e do arquivo de configuração do dispositivo (devconfig.out) para seus locais originais no servidor de recuperação. Após a execução dos scripts, você verá os diretórios vazios recém-criados no servidor de recuperação.

Ao tentar reparar um conjunto de armazenamentos de contêiner de diretório a partir de um servidor de replicação de destino, o comando REPAIR STGPOOL falhará se ocorrer qualquer uma das condições a seguir:

O servidor de replicação de destino está indisponível.
O conjunto de armazenamentos de destino está danificado.
Uma indisponibilidade de rede ocorre.

Restrição: Para extensões de dados que foram replicadas usando regras de armazenamento de replicação, se os dados foram replicados para um conjunto de armazenamento sem contêiner ou dados foram tirados do conjunto de armazenamento de contêineres no servidor de replicação de destino, essas extensões de dados não serão recuperáveis.

Procedimento

Marque todas as extensões de dados no conjunto de armazenamento de contêineres como danificado, emitindo o comando AUDIT CONTAINER para o conjunto de armazenamento de container no nível do conjunto de armazenamento, e especificando o parâmetro ACTION=MARKDAMAGED .
Por exemplo, para auditar um conjunto de armazenamentos denominado STGPOOL1 e marcá-lo como danificado, emita o comando a seguir:
```
audit container stgpool=stgpool1 action=markdamaged
```
Repare o conjunto de armazenamentos executando uma das ações a seguir:
- Se você replicou dados usando o comando REPLICATE NODE, emita o comando REPAIR STGPOOL e especifique o parâmetro SRCLOCATION=REPLSERVER.
Por exemplo, para reparar um conjunto de armazenamentos denominado STGPOOL1 a partir de um servidor de replicação de destino, emita o comando a seguir:
```
repair stgpool stgpool1 srclocation=replserver
```
Ao emitir o comando REPAIR STGPOOL, as extensões danificadas são excluídas do volume imediatamente após elas serem reparadas. As extensões danificadas não são retidas de acordo com o valor especificado pelo parâmetro REUSEDELAY.
- Se você usou regras de armazenamento de replicação para replicar dados, emita o comando REPAIR STGPOOL e especifique o nome do servidor de replicação de destino para o parâmetro SERVER.
Por exemplo, para reparar um conjunto de armazenamento denominado STGPOOL2 de um servidor de replicação que é denominado SERVER2, emita o comando a seguir:
```
repair stgpool stgpool2 server=server2
```
Se você não usou scripts de configuração Blueprint para configurar o servidor de replicação de destino, a estrutura do arquivo no servidor de replicação de destino pode não corresponder às informações armazenadas no banco de dados.
Opcionalmente, remova os diretórios do pool de armazenamento que não existem no servidor de replicação de destino, emitindo o comando DELETE STGPOOLDIRECTORY .
Confirme que não há extensões danificadas adicionais emitindo o comando QUERY DAMAGED .
Se danos forem detectados e extensões deduplicadas não puderem ser reparadas por meio do servidor de replicação de destino, ainda existirá a possibilidade de reparo. Em alguns casos, o nó cliente reenviará os dados durante uma operação de backup e as extensões danificadas serão reparadas.
Se as extensões não forem reparadas, aguarde dois ciclos de backup para permitir que as operações de backup do cliente ocorram. Após dois ciclos de backup, conclua as etapas a seguir:
1. Para confirmar se o dano é reparado, reemita o comando QUERY DAMAGED .
2. Para remover objetos que se referem a dados danificados, emita o comando AUDIT CONTAINER e especifique o parâmetro ACTION=REMOVEDAMAGED .
  Por exemplo, para auditar um conjunto de armazenamentos de contêiner de diretório denominado STGPOOL1 e remover objetos danificados, emita o comando a seguir:
```
audit container stgpool=stgpool1 action=removedamaged
```
Repita este procedimento para reparar todos os seus conjuntos de armazenamentos.