Fazendo backup e restaurando dados

Use os procedimentos a seguir para fazer backup e restaurar dados em IBM Watson® Discovery.

IBM Cloud Pak for Data IBM Software Hub

Essas informações se aplicam apenas a implementações instaladas.

Você usa o mesmo conjunto de scripts de backup e restauração para fazer backup e restaurar dados em qualquer um dos caminhos de upgrade suportados. O script de backup armazena o número da versão do serviço com dados para backup a partir da implementação existente. O script de restauração detecta a versão do serviço que está instalada na nova implantação e, em seguida, segue as etapas apropriadas para restaurar os dados para a versão detectada.

A tabela a seguir lista os caminhos de atualização que são suportados pelos scripts.

Caminhos de upgrade suportados
Versão em uso	Versão para a qual é possível fazer upgrade
5.1.x	Versões posteriores do site 5.1.x, 5.2.0
5.0.x	Versões posteriores de 5.0.x, 5.1.x, 5.2.0
4.8.8, 4.8.9	5.1.1 ou versões posteriores
4.8.7	Versões posteriores de 4.8.x, 5.1.x, 5.2.0
4.8.6	Versões posteriores de 4.8.x, 5.0.3, 5.1.x, 5.2.0
4.8.x	Versões posteriores de 4.8.x, 5.0.x, 5.1.x, 5.2.0
4.7.x	4.8.x, 5.0.x, 5.1.x
4.6.x	4.8.x, 5.0.x, 5.1.x
4.5.x	4.8.x, 5.0.x, 5.1.x
4.0.x	4.8.x, exceto 4.8.0

Se estiver fazendo upgrade para 5.2.x, uma maneira mais simples de concluir o upgrade é descrita nos tópicos a seguir:

Se estiver fazendo upgrade para 5.1.x, uma maneira mais simples de concluir o upgrade é descrita nos tópicos a seguir:

Se você estiver fazendo upgrade para 5.0.x, uma maneira mais simples de concluir o upgrade será descrita nos tópicos a seguir:

Se você usar as APIs do IBM Cloud Pak for Data Red Hat OpenShift para o backup e o utilitário de restauração do Data Protection (OADP) para fazer backup off-line e restaurar um cluster inteiro, algumas etapas extras serão necessárias. Para obter mais informações, consulte Usando OADP para fazer backup de um cluster no qual o Discovery está instalado. Para obter informações sobre o backup e a restauração on-line do OADP, consulte Cloud Pak for Data backup e restauração on-line.

É possível executar um upgrade no local de uma versão 4.8.x para uma versão 4.8.y mais recente. Para obter mais informações, consulte Fazendo upgrade do Watson Discovery da Versão 4.8.x para uma atualização 4.8 posterior.

É possível executar um upgrade no local de uma versão 4.7.x para uma versão 4.7.y mais recente. Para obter mais informações, consulte Fazendo upgrade do Watson Discovery da Versão 4.7.x para uma atualização 4.7 posterior.

É possível fazer um upgrade no local de uma versão 4.6.x para uma versão 4.6.y mais recente. Para obter mais informações, consulte Fazendo upgrade do Watson Discovery da Versão 4.6.x para uma atualização 4.6 posterior.

Você pode fazer um upgrade em local a partir de uma versão 4.5.x para uma versão posterior 4.5.y. Para mais informações, consulte Atualizando Watson Discovery para a atualização mais recente da Versão 4.5.

Você pode fazer um upgrade em local a partir de uma versão 4.0.x para uma versão posterior 4.0.y. Para mais informações, consulte Atualizando Watson Discovery para uma atualização mais recente 4.0.

Visão geral do processo

Em um alto nível, o processo inclui as seguintes etapas:

Faça backup de seus dados Discovery usando o script de backup.
Instale a versão mais recente do site IBM Cloud Pak for Data.
Instale a versão mais recente do serviço Discovery no cluster.
Restauita os dados backed-up Discovery usando o script de restauração.

Limitações de backup e restauração

Não é possível migrar os seguintes dados:

Modelos de sugestões de dicionário. Esses modelos são criados quando se constrói um dicionário. O dicionário está incluído no backup, mas o modelo de sugestões de termo não é. Reprocessar as coleções migradas para habilitar sugestões de termo de dicionário.
Não é possível fazer backup e restaurar curações ou migrá-las porque as curações são um recurso beta.

Você pode fazer backup e restaurar alguns dados usando os scripts de backup e restauração, mas deve fazer backup e restaurar outros dados manualmente. Os seguintes dados devem ser apoiados manualmente:

Pastas e documentos do sistema de arquivos local nos quais é possível efetuar crawl usando a origem de dados do Sistema de arquivos local.

As atualizações a seguir são feitas quando as suas coleções são restauradas:

Qualquer coleção que contenha documentos que foram criados por upload de dados são automaticamente recauchutados e reindexados quando restaurados. Esses documentos recebem novos números de identificação de documentos nas coleções restauradas.
As coleções que foram usadas em projetos Content Mining são automaticamente recrafadas e reindexadas quando restauradas. Apenas os documentos que são adicionados por upload de dados são atribuídos novos números de ID do documento nas coleções restauradas.

Métodos de backup e restauração

Você pode fazer backup e restaurar sua instância de Discovery manualmente ou usando scripts.

Usando os scripts de backup
Usando os scripts de restauração
Fazendo backup de dados manualmente
Restaurando dados manualmente

Você deve ter acesso Administrativo à instância Discovery no seu cluster Discovery (onde os dados a serem apoiados são armazenados) e o acesso administrativo à nova instância (onde os dados serão restaurados para).

Os scripts de backup e restauração concluem muitas operações e podem levar algum tempo para executar. Para evitar problemas de tempo limite, execute uma ferramenta que previne os tempos de timeouts, como nohup.

Usando os scripts de backup

Como as alterações nos dados armazenados em IBM Watson® Discovery durante um backup podem fazer com que o backup fique corrompido e inutilizável, não são permitidas solicitações em voo durante o período de backup.

Uma solicitação em voo é qualquer ação IBM Watson® Discovery que processa dados, incluindo as seguintes ações:

Crawl de origem (agendado ou não programado)
Alimentar documentos
Treinar um modelo de consulta treinado

A quantidade de armazenamento que está disponível no nó onde você executa o script de backup deve ser 3 vezes maior do que o maior arquivo de backup da loja de dados que você planeja fazer backup. Se o seu armazenamento de dados for grande, considere usar uma reclamação de volume persistente em vez de contar com o armazenamento efêmero do nó. Para obter mais informações, consulte Configurando empregos para usar o PVC.

Conclua as etapas a seguir para fazer backup dos dados do IBM Watson® Discovery usando os scripts de backup:

Insira o comando a seguir para configurar o namespace atual no qual sua instância do Discovery está implementada:
```
oc project <namespace>
```
Obter o script de backup a partir do repositório GitHub.

Você precisa de todos os arquivos do repositório para completar um backup e restauração. Siga as instruções em GitHub Help para clonar ou fazer download de um arquivo compactado do repositório.
Torne cada script um arquivo executável executando o comando a seguir:
```
chmod +x <name-of-script>
```
Substitua <name-of-script> pelo nome do script..
Execute o scriptall-backup-restore.sh.
```
./all-backup-restore.sh backup [ -f backup_file_name ] [--pvc]
```
O parâmetro -f backup_file_name é opcional. O nome watson_discovery_<timestamp>.backup é usado se você não especificar um nome.

O parâmetro --pvc é opcional. Para obter mais informações sobre quando utilizá-lo, consulte Configurando empregos para usar o PVC. Por padrão, os scripts de backup e restauração criam um diretório tmp no diretório atual que o script usa para extração ou compressão de arquivos de backup.

Se você tiver problemas com o backup, execute novamente o comando de backup e inclua o parâmetro --use-job Este parâmetro instrui o script de backup a usar uma tarefa Kubernetes para fazer backup do ElasticSearch e MinIO além de Postgres, que usa um trabalho Kubernetes por padrão. Se o tamanho dos dados em ElasticSearch e MinIO for grande e o armazenamento efêmero for insuficiente, inclua a opção --pvc. Quando você o faz, o script usa a reclamação de volume persistente que é especificado com a opção --pvc em vez do armazenamento efêmero emptyDir como o diretório de trabalho temporário para a tarefa.

Extraindo arquivos do arquivo de arquivo de backup

Os scripts geram um arquivo de arquivo, incluindo os arquivos de backup dos serviços que estão listados na Etapa 1.

Você pode extrair arquivos do arquivo de arquivo executando o seguinte comando:
```
tar xvf <backup_file_name>
```

Configurando empregos para usar o PVC

O processo de backup e restauração usa os empregos Kubernetes. Os empregos utilizam volumes efêmeros que utilizam o armazenamento efêmero. Trata-se de uma montagem temporária de armazenamento no pod que usa o armazenamento local de um nó. Em casos raros, o armazenamento efêmero não é grande o suficiente. Você pode, opcionalmente, instruir o trabalho para montar uma Reclamação De Volume Persistente (PVC) em seu pod para usar para armazenar os dados de backup. Para isso, especifique a opção --pvc quando você executar o script. Os scripts usam emptyDir de Kubernetes caso contrário.

Na maioria dos casos, você não precisa usar um volume persistente. Se você optar por utilizar um volume persistente, o volume deve ser 3 vezes maior que o maior arquivo de backup na loja de dados. O tamanho do arquivo de backup da loja de dados depende do uso. Depois de criar um backup, é possível extrair arquivos do arquivo de arquivo para verificar os tamanhos de arquivo.

Além disso, deve-se ter 2 vezes mais espaço em disco disponível no sistema local do que o tamanho do armazenamento de dados porque o archive dos dados é dividido e, em seguida, recombinado para evitar problemas que, de outra forma, podem ocorrer ao copiar arquivos grandes do nó do cluster para o sistema local.

Mapeando clusters multilocatários

Ao restaurar dados que foram submetidos a backup de uma versão anterior à 4.0.6 para qualquer liberação posterior e a implementação submetida a backup tinha mais de uma instância do serviço provisionado, uma etapa extra é necessária. Você deve criar um arquivo JSON que mapeia os IDs de instância de serviço entre o cluster backed-up e o cluster onde os dados estão sendo restaurados.

Essa etapa de mapeamento não é necessária se os IDs de instância não alteraram entre as etapas de back up e restore. Por exemplo, você pode pular esta etapa se estiver restaurando dados para o mesmo cluster onde foi feito o backup ou se você está restaurando dados para um novo cluster da marca que não tem instâncias Discovery.

Para criar um mapeamento, conclua as etapas a seguir:

Extraia o arquivo de template de mapeamento a partir do arquivo de arquivo de backup.
```
tar xf <backup_file_name> tmp/instance_mapping.json -O > <mapping_file_name>
```
Faça uma lista com os nomes e IDs de instância das instâncias de serviço que são provisionados para o cluster onde os dados estão sendo restaurados.

O ID da instância faz parte do URL que é especificado na página de resumo da instância. No menu principal do cliente Web IBM Cloud Pak for Data, expanda Services (Serviços) e clique em Instances (Instâncias). Encontre sua instância e, em seguida, clique nele para abrir sua página de resumo. Role até a seção Informações de acesso da página e procure o ID da instância no campo URL campo.

Por exemplo, https://<host_name>/wd/<namespace>-wd/instances/<instance_id>/api.

Repita essa etapa para fazer uma nota do ID da instância para cada instância que for provisionada.

Edite o arquivo de mapeamento.

Inclua os IDs de instância para as instâncias de serviço de destino que você listou na etapa anterior. O trecho a seguir é um exemplo de um arquivo de mapeamento.

{
  "instance_mappings": [
    {
      "display_name": "discovery-1",
      "source_instance_id": "1644822491506334",
      "dest_instance_id": "<new_instance_id>"
    },
    {
      "display_name": "discovery-2",
      "source_instance_id": "1644822552830325",
      "dest_instance_id": "<new_instance_id>"
    }
  ]
}

Quando você executar o script de restauração, inclua o parâmetro --mapping opcional para aplicar este arquivo de mapeamento quando os dados são restaurados.

Fazendo backup de dados manualmente

Faça backup manualmente de dados que não são apoiados por meio do uso dos scripts.

Para fazer backup manualmente dos dados de uma instância do Discovery, conclua as etapas a seguir:

Insira o comando a seguir para efetuar logon em seu cluster do Discovery:

oc login https://<OpenShift administrative console URL> \
-u <cluster administrator username> -p <password>

Insira o comando a seguir para alternar para o namespace apropriado:
```
oc project <discovery-install namespace>
```
Insira oc get pods|grep crawler.

Insira o comando a seguir:

oc cp <crawler pod>:/mnt <path-to-backup-directory>

Usando os scripts de restauração

Se você estiver restaurando dados de uma versão anterior à 4.0.6 e estiver restaurando um cluster de diversos locatários para um cluster de diversos locatários, deverá executar uma etapa extra antes de iniciar. Para obter mais informações, consulte Mapeando clusters de diversos locatários

Conclua as etapas a seguir para restaurar os dados em IBM Watson® Discovery usando os scripts de restauração:

Insira o comando a seguir para configurar o namespace atual no qual sua instância do Discovery está implementada:
```
oc project <namespace>
```
Se você ainda não tiver, obtenha o script de restauração a partir do repositório GitHub.

Você precisa de todos os arquivos do repositório para completar um back up e restore. Siga as instruções em GitHub Help para clonar ou fazer download de um arquivo compactado do repositório.
Torne cada script um arquivo executável executando o comando a seguir:
```
chmod +x <name-of-script>
```
Substitua <name-of-script> pelo nome do script..
Restaure os dados do arquivo de backup em seu sistema local para a nova implementação do Discovery executando o seguinte comando:
```
./all-backup-restore.sh restore -f backup_file_name [--pvc] [--mapping]
```
O parâmetro --pvc é opcional. Para obter mais informações sobre quando utilizá-lo, consulte Configurando empregos para usar o PVC.

O parâmetro --mapping é opcional. Para obter mais informações sobre quando utilizá-lo, consulte Mapeando clusters de multilocatários.

Por padrão, os scripts de backup e restauração criam um diretório tmp no diretório atual que o script usa para extração ou compressão de arquivos de backup. Se você usou o parâmetro --use-job quando fez backup dos dados, especifique-o novamente quando restaurar os dados. Este parâmetro instrui o script de backup a usar um trabalho Kubernetes para fazer backup do ElasticSearch e MinIO.

Os pods gateway, ingestion, orchestrator, hadoop worker e controller são reiniciados automaticamente.

Restaurando dados manualmente

Restaurar manualmente dados que não podem ser restaurados usando o script.

Para restaurar manualmente dados de uma instância do Discovery, conclua as etapas a seguir:

Insira o comando a seguir para efetuar logon em seu cluster do Discovery:

oc login https://<OpenShift administrative console URL> \
-u <cluster administrator username> -p <password>

Insira o comando a seguir para alternar para o namespace apropriado:
```
oc project <discovery-install namespace>
```
Insira oc get pods|grep crawler.

Insira o comando a seguir:

oc cp <path-to-backup-directory> <crawler pod>:/mnt

Usando OADP para fazer backup off-line de um cluster no qual o Discovery está instalado

Se você planeja fazer backup offline e restaurar uma instância inteira do IBM Cloud Pak for Data usando o utilitário de backup e restauração do IBM Cloud Pak for Data Red Hat OpenShift APIs para Data Protection (OADP), deve-se executar algumas etapas adicionais na ordem correta para que o utilitário funcione corretamente quando o Discovery estiver presente. Consulte backup e restauração off-line doCloud Pak for Data(utilitárioOADP).

Fazendo backup de um cluster off-line

Para fazer backup off-line de um cluster, conclua as etapas a seguir:

Execute o Discovery script de backup..
Use o OADP backup utility para fazer backup do cluster.

Restaurando um cluster off-line

Para restaurar um cluster off-line, conclua as etapas a seguir:

Use o OADP backup utility para restaurar o cluster.
Desinstale Discoverye, em seguida, instale Discovery novamente no cluster restaurado.

A reinstalação é necessária porque o utilitário nem sempre reinstala Discovery corretamente.
Execute Discovery script de restauração para restaurar seus dados.