Partilhar via

Restaurar usando a ferramenta Instantâneo Consistente de Aplicativo do Azure

  • Artigo

Este artigo fornece um guia para executar o comando restore da ferramenta Azure Application Consistent Snapshot que você pode usar com os Arquivos NetApp do Azure.

Nota

O comando restore só está disponível para a Instância Grande do Azure e os Arquivos NetApp do Azure. Todas as restaurações do Disco Gerenciado do Azure devem ser feitas usando o Portal do Azure ou a CLI do Azure.

Introdução

Fazer uma restauração de volume a partir de um instantâneo é feito usando o azacsnap -c restore comando.

Importante

Isso não executa uma recuperação de banco de dados, apenas uma restauração de volume(s) conforme descrito para cada uma das opções abaixo.

Opções de comando

O -c restore comando tem as seguintes opções:

  • --restore snaptovol Cria um novo volume com base em um instantâneo de volume. Este comando cria um novo volume "clonado" para cada volume no arquivo de configuração, usando por padrão o instantâneo de volume mais recente como base para criar o novo volume. Para volumes de dados, é possível selecionar um snapshot para clonar usando a opção --snapshotfilter <Snapshot Name>, isso só será concluído se TODOS os volumes de dados tiverem esse mesmo snapshot. Este comando não interrompe a replicação de armazenamento do primário para o secundário. Em vez disso, clones do snapshot são criados no mesmo local e os pontos de montagem recomendados do sistema de arquivos dos volumes clonados são apresentados. Se estiver usando no sistema de Instância Grande do Azure, esse comando deverá ser executado na região DR (ou seja, no sistema de failover de destino).

  • --restore revertvolume Reverte o volume de destino para um estado anterior com base em um instantâneo de volume. Usando este comando como parte do failover de DR na região de DR emparelhada. Esse comando interrompe a replicação de armazenamento do site primário para o local secundário e reverte o(s) volume(s) de DR de destino para seu instantâneo disponível mais recente nos volumes de DR, juntamente com os pontos de montagem recomendados do sistema de arquivos para os volumes de DR revertidos. Se estiver usando no sistema de Instância Grande do Azure, esse comando deverá ser executado na região DR (ou seja, no sistema de failover de destino).

    Aviso

    A opção revertvolume é destrutiva de dados, pois qualquer conteúdo armazenado nos volumes após o snapshot escolhido para reverter será perdido e não será recuperável.

    Gorjeta

    Depois de fazer um revertvolume, é recomendável que o volume seja remontado para garantir que não haja identificadores de arquivo obsoletos. Isto pode ser feito utilizando mount -o remount <mount_point>.

  • --dbsid <SAP HANA SID> é o SID do banco de dados, conforme especificado no arquivo de configuração ao qual aplicar os comandos de restauração de volume.

  • [--configfile <config filename>] é um parâmetro opcional que permite nomes de arquivo de configuração personalizados.

Executar um failover de DR de teste azacsnap -c restore --restore snaptovol

Esse comando é como o comando "full" DR Failover (--restore revertvolume), mas em vez de interromper a replicação entre o site primário e o site de recuperação de desastres, um volume de clone é criado a partir dos volumes de recuperação de desastres, permitindo a restauração do instantâneo mais recente no site de DR. Esses volumes clonados podem ser usados pelo cliente para testar a recuperação de desastres sem a necessidade de executar um failover completo do ambiente HANA que interrompa o contrato de replicação entre o local principal e o local de recuperação de desastres.

  • Vários pontos de restauração diferentes podem ser testados dessa forma, cada um com seu próprio ponto de restauração.
  • O clone é designado pelo carimbo de data/hora em que o comando foi executado e representa os dados mais recentes e outros instantâneos disponíveis quando executados.

Importante

Esta operação aplica-se apenas à Instância Grande do Azure.

  • Quando o comando this é executado, ele requer o e-mail de contato para que as operações entrem em contato antes da exclusão dos clones após 4 semanas.
  • Cada execução do comando this criará um novo clone que deve ser excluído pelo Microsoft Operations quando o teste for concluído.
  • Todos os volumes clonados criados serão excluídos automaticamente após 4 semanas.

O arquivo de configuração (por exemplo, ) deve conter apenas os volumes DR e não os volumes de produção, caso contrário, DR.jsonos volumes de produção poderiam ter clones criados.

Saída do azacsnap -c restore --restore snaptovol comando (para cenário de nó único)

> azacsnap --configfile DR.json -c restore --restore snaptovol --dbsid H80
* This program is designed for those customers who have previously installed the
  Production HANA instance in the Disaster Recovery Location either as a
  stand-alone instance or as part of a multi-purpose environment.
* This program should be executed from the Disaster Recovery location otherwise
  unintended consequences may result.
* This program is intended to allow the customer to simulate a Disaster Recovery
  failover without actually requiring a failover and subsequent failback.
* Any other restore points must be handled by Microsoft Operations.
* As part of the process, a clone is created of the each of the 'data' and 'other'
  volumes per the configuration file.

Do you wish to continue? (y/n) [n]: y

About to create clones of volumes based on the latest snapshot, these will be
kept for 4 weeks before being automatically deleted by Microsoft Operations.
Enter an email address to contact when deleting clones: <b>person@nowhere.com</b>
Checking state of HLI volumes for SID 'PEW'
Configured volumes (Data and Other) are not ready to clone, will retry in 00:00:10 seconds
Configured volumes (Data and Other) are not ready to clone, will retry in 00:00:10 seconds
Configured volumes (Data and Other) are not ready to clone, will retry in 00:00:10 seconds
Configured volumes (Data and Other) are not ready to clone, will retry in 00:00:10 seconds
Configured volumes (Data and Other) are not ready to clone, will retry in 00:00:10 seconds
Configured volumes (Data and Other) are not ready to clone, will retry in 00:00:10 seconds
Configured volumes (Data and Other) are not ready to clone, will retry in 00:00:10 seconds
Displaying Mount Points by Volume as follows:
10.50.251.34:/hana_data_h80_sapprdhdb80_mnt00001_t020_xdp_rwclone_20200916_0256  /hana/data/H80/mnt00001 nfs  rw,bg,hard,timeo=600,vers=4,rsize=1048576,wsize=1048576,intr,noatime,lock 0 0
10.50.251.36:/hana_log_backups_h80_sapprdhdb80_t020_xdp_rwclone_20200916_0256  /hana/log_backups/H80/01 nfs  rw,bg,hard,timeo=600,vers=4,rsize=1048576,wsize=1048576,intr,noatime,lock 0 0
*******************  HANA Test DR Restore Steps  ******************************
* Complete the following steps to recover your HANA database:           *
* 1. Ensure ALL the target mount points exist to mount the snapshot clones.    *
*    e.g. mkdir /hana/logbackups/H99_SOURCE                                    *
* 2. Add Mount Point Details from 'Displaying Mount Points by Volume' as       *
*    output above into /etc/fstab of DR Server.                                *
* 3. Mount newly added filesystems.                                            *
* 4. Perform HANA Snapshot Recovery using HANA Studio.                         *
********************************************************************************
*  These snapshot copies (clones) are kept for 4 weeks before                  *
*  being automatically removed.                                                *
*  Please contact Microsoft Operations to delete them earlier.                 *
********************************************************************************

Importante

A saída "Exibindo pontos de montagem por volume" é diferente para os vários cenários.

Execute failover de DR completo azacsnap -c restore --restore revertvolume

Este comando interrompe a replicação de armazenamento do site primário para o site secundário, restaura o instantâneo mais recente nos volumes DR e fornece os pontos de montagem para os volumes DR.

Este comando DEVE ser executado no servidor DR usando um arquivo de configuração (por exemplo, DR.json) com volumes DR APENAS!

Execute um failover para o site DR, executando o comando azacsnap -c restore --restore revertvolume. Este comando requer que um SID seja adicionado como parâmetro. Este é o SID da instância HANA, que precisa ser recuperado no local de DR.

Importante

Execute este comando apenas se estiver planejando executar o exercício de DR ou um teste. Este comando interrompe a replicação. Você deve entrar em contato com o Microsoft Operations para reativar a replicação.

No alto nível, aqui estão as etapas para executar um failover de DR:

  • Você deve desligar a instância HANA no site primário . Essa ação é necessária somente se você estiver realmente fazendo o failover para o site de DR para evitar inconsistências de dados.
  • Desligue a instância HANA no nó DR para o SID de produção.
  • Execute o comando azacsnap -c restore --restore revertvolume no nó DR com o SID a ser recuperado.
    • O comando quebra o link de replicação de armazenamento do site primário para o local de DR
    • O comando restaura os volumes "dados" e "outros" conforme configurado. Normalmente, essa operação seria para os volumes para o /hana/data e /hana/logbackups sistemas de arquivos. O /hana/shared sistema de arquivos NÃO é recuperado, mas usa o existente /hana/shared para SID no local DR.
    • Monte os /hana/data e /hana/logbackups volumes – certifique-se de que eles sejam adicionados ao /etc/fstab arquivo
  • Restaure o instantâneo HANA SYSTEMDB. O estúdio HANA mostra apenas o instantâneo HANA mais recente disponível sob o instantâneo de armazenamento restaurado como parte da execução do comando azacsnap -c restore --restore revertvolume snapshot.
  • Recupere o banco de dados do locatário.
  • Inicie a instância HANA no site de DR para o SID de produção (exemplo: H80 neste caso).
  • Execute qualquer teste de banco de dados.

Próximos passos