Reparando conjuntos de armazenamentos em um ambiente com um servidor de replicação e volumes do conjunto de armazenamento de cópia do contêiner após um desastre

Editar on-line

Se ocorrer um desastre em um servidor de replicação de origem, você pode reparar extensões de dados deduplicadas em um conjunto de armazenamento de container de diretório a partir de um servidor de replicação de destino ou de arquivos de fita de armazenamento de cópias de armazenamento de cópias em container.

Antes de iniciar

Conclua as tarefas a seguir:

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 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.

Ao reparar um conjunto de armazenamentos de contêiner de diretório a partir de conjuntos de cópias do contêiner, o comando REPAIR STGPOOL falhará quando ocorrer qualquer uma das condições a seguir:

O conjunto de armazenamentos de cópia de contêiner está indisponível.
O conjunto de armazenamentos de cópia de contêiner está danificado.
Os volumes do conjunto de armazenamento de cópia do contêiner estão indisponíveis ou danificados.

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
```
Se você protegeu o conjunto de armazenamento de contêineres de diretórios usando tanto onsite e offsite container-copy storage pools, emita o comando UPDATE STGPOOL para a cópia onsite das piscinas de armazenamento de cópias de container e especifique o parâmetro ACCESS=UNAVAILABLE .
Quando os volumes do conjunto de armazenamento de cópias do offsite estão de volta ao onsite, confira-os na biblioteca emitindo o comando CHECKIN LIBVOLUME e especificando o parâmetro STATUS=PRIVATE . Movendo os volumes de fita no local agora, você estará preparado para reparar extensões danificadas dos volumes de fita de cópia do contêiner se as extensões danificadas não puderem ser reparadas a partir do servidor de replicação de destino.
Atualize o status dos volumes emitindo o comando UPDATE STGPOOL e especificando o parâmetro ACCESS=READWRITE .
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 conjunto de armazenamentos que não existem no servidor de replicação de destino. Emita o comando DELETE STGPOOLDIRECTORY para excluir diretórios que não estão no servidor de replicação de destino.
Confirme que não há extensões danificadas adicionais emitindo o comando QUERY DAMAGED .
Se as extensões danificadas não puderem ser reparadas a partir do servidor de replicação de destino, será possível reparar as extensões danificadas a partir de conjuntos de armazenamento de cópia contêiner externos. Para obter instruções, consulte Reparando conjuntos de armazenamentos de volumes do conjunto de armazenamento de cópia do contêiner após um desastre..
Confirme que não há extensões danificadas adicionais pela reemissão do comando QUERY DAMAGED .
Se danos forem detectados e extensões deduplicadas não puderem ser reparadas por meio do servidor de replicação, existirá a possibilidade de elas serem reparadas. Em alguns casos, o nó cliente reenviará os dados durante uma operação de backup e as extensões danificadas serão reparadas.
Se algumas extensões deduplicadas não foram reparadas, aguarde dois ciclos de backup para permitir que os backups 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.