Restaurar backups retidos de longo prazo

É possível recuperar backups retidos de longo prazo diretamente dos seus buckets do Cloud Storage usando um utilitário independente, garantindo o acesso aos dados mesmo sem dispositivos ativos do Backup e DR.

Neste documento, descrevemos como usar esse utilitário de recuperação independente para descobrir, verificar, montar e restaurar imagens de backup do Backup e DR OnVault e do Compute Engine.

Visão geral

Os backups retidos por longo prazo são armazenados em buckets do Cloud Storage usando políticas do OnVault para conformidade e arquivamento. Para garantir a acessibilidade dos dados independentemente da infraestrutura de backup, use um utilitário de recuperação independente para descobrir, verificar e restaurar esses dados diretamente do bucket de armazenamento. Isso é fundamental para cenários de recuperação de desastres ou desativação em que o dispositivo de backup/recuperação de origem pode não estar disponível.

Antes de começar

Antes de começar a restaurar backups retidos por longo prazo, conclua as seções a seguir.

Acessar os papéis necessários

Para receber as permissões necessárias para restaurar backups retidos por longo prazo, peça ao administrador para conceder a você o papel do IAM de Operador do Cloud Storage do Backup e DR (roles/backupdr.cloudStorageOperator) no bucket de destino do Cloud Storage. Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Também é possível conseguir as permissões necessárias usando papéis personalizados ou outros papéis predefinidos.

Outros pré-requisitos

Antes de restaurar backups retidos por longo prazo, verifique se você atende aos seguintes pré-requisitos:

  1. Antes de iniciar uma recuperação, confirme se os dados estão disponíveis no armazenamento do OnVault. Verifique os backups atuais no pool de dispositivos de backup/recuperação e migre-os para o OnVault atribuindo a política de proteção relevante do OnVault.

  2. Para cenários de recuperação que envolvem snapshots de disco permanente, verifique se todos os metadados de backup foram replicados para o bucket de destino do Cloud Storage. O utilitário de recuperação depende desses metadados para catalogar e processar imagens de snapshots. Para facilitar a transferência de dados e confirmar que os metadados estão presentes no bucket do Cloud Storage, entre em contato com o Cloud Customer Care.

  3. Verifique se o sistema host em que você executa essa ferramenta atende aos seguintes requisitos:

    • CLI gcloud: instalada e acessível na variável de ambiente PATH (especificamente gcloud storage).
    • Autenticação: configurada com credenciais ativas executando gcloud auth login ou usando Application Default Credentials (ADC) ou chaves de conta de serviço.

  4. Identifique e mantenha uma lista de nomes de bucket do Cloud Storage e os IDs dos projetos Google Cloud correspondentes para usar com o utilitário de recuperação.

Implantar o utilitário de recuperação

Configure uma instância de VM para servir como um proxy de recuperação ou como o host do aplicativo de destino e implante a ferramenta de recuperação independente.

Descobrir aparelhos, hosts e imagens

O utilitário de recuperação independente aceita um par de valores de bucket e projeto (--bucket e --project) para comandos. O utilitário é compatível com as seguintes operações:

  • Listar aplicativos
  • Listar backups
  • Expirar backups
  • Montar uma imagem de backup
  • Desmontar uma imagem de backup

Montar a imagem de backup

Para fazer uma montagem de recuperação, primeiro identifique o nome da imagem de backup.

Liste os backups disponíveis para identificar o nome da imagem de backup:

python3 ~/gcbdr-onvault-cli/python/gcbdr_onvault.py \
  --bucket BUCKET_NAME \
  --project PROJECT_ID \
  --cluster APPLIANCE_NAME \
  --host HOST_NAME \
  --app APPLICATION_NAME \
  --list-images

Em seguida, para realizar uma montagem de recuperação não interativa, use um comando semelhante ao exemplo a seguir para montar a imagem de backup selecionada diretamente no proxy de recuperação designado ou no servidor de banco de dados de destino:

python3 ~/gcbdr-onvault-cli/python/gcbdr_onvault.py \
  --bucket BUCKET_NAME \
  --project PROJECT_ID \
  --cluster APPLIANCE_NAME \
  --host HOST_NAME \
  --app APPLICATION_NAME \
  --image IMAGE_NAME \
  --mountpoint MOUNT_POINT \
  --auto-mount

Substitua:

  • BUCKET_NAME pelo nome do bucket do Cloud Storage.
  • PROJECT_ID: o ID do projeto Google Cloud .
  • APPLIANCE_NAME: o nome ou ID do dispositivo de backup/recuperação.
  • HOST_NAME: o nome do host ou ID do host de origem.
  • APPLICATION_NAME: o nome ou ID do aplicativo protegido.
  • IMAGE_NAME: o nome da imagem de backup ativa a ser montada.
  • MOUNT_POINT: (opcional) o caminho do diretório local em que o backup é ativado. O padrão é /tmp/recovery_folder.

Depois que a extração for concluída, você poderá ver os dados armazenados em backup no diretório do ponto de montagem.

Restaurar aplicativos

Para acessar arquivos de banco de dados brutos, acesse MOUNT_POINT/restored_data/. Selecione o caminho de recuperação para seu tipo de carga de trabalho e configuração de montagem:

Microsoft SQL

  1. Localizar arquivos: identifique os arquivos principais do banco de dados .mdf e .ldf no diretório db_volume/.
  2. Anexação direta (mesmo host): pare a instância do banco de dados de destino. Abra o SQL Server Management Studio, selecione Anexar banco de dados e especifique os caminhos de arquivo que apontam para os arquivos de dados e de registro no diretório do ponto de montagem de recuperação.
  3. Copiar e anexar (host diferente): pare a instância do banco de dados de destino. Transfira os arquivos .mdf e .ldf para as unidades de armazenamento local do servidor de destino e anexe-os usando o SQL Server Management Studio.

Oracle

  1. Localizar arquivos: o utilitário detecta automaticamente arquivos init.ora ou spfile e arquivos de dados .dbf enquanto coloca o backup do banco de dados RMAN e os grupos de volumes Archive log on-line.
  2. Recuperar banco de dados: desligue a instância de destino do Oracle ou inicie-a no modo NOMOUNT. Atualize os parâmetros de inicialização (como arquivos de controle) para apontar para os arquivos .dbf montados para validação direta ou copie os arquivos .dbf para o armazenamento local ou o gerenciamento automático de armazenamento (ASM, na sigla em inglês) para recuperação permanente.
  3. Abrir banco de dados: coloque a instância no status MOUNT, aplique os registros de recuperação necessários do grupo de volumes TransactionLog montado e abra o banco de dados.

VM do VMware Engine

Além da recuperação de aplicativos de banco de dados, a proteção de máquina virtual do Google Cloud VMware Engine (VMware Engine) abrange toda a configuração de hardware, além das extensões de disco virtual.

  1. Montar e localizar arquivos: monte a imagem de backup conforme descrito em Montar a imagem de backup. O utilitário gera o disco virtual esparso (vol00.raw) no caminho de montagem principal. Em seguida, ele anexa o disco para expor o sistema de arquivos do sistema operacional convidado no diretório db_volume/, enquanto os metadados de configuração do VMware (incluindo .ovf, .vmx e Catalog.xml) são organizados na pasta log_files/.
  2. Restaurar a VM diretamente: desative a VM de destino para proteger o disco de base dela para análise do manifesto. Um processo de worker lê blocos de dados do armazenamento local, grava-os no VMDK usando bibliotecas do VMware Virtual Disk Development Kit (VDDK) e reinicia automaticamente a VM.

Snapshots de DP do Compute Engine

Ao contrário dos backups do OnVault montados como sistemas de arquivos locais, os snapshots do Persistent Disk do Compute Engine são restaurados inicializando novos discos permanentes e anexando-os diretamente a uma instância de destino do Compute Engine.

  1. Identifique o backup e os metadados de destino: confirme se o arquivo de catálogo de metadados do snapshot do Persistent Disk (pdsnapshot_catalog.json) está presente no bucket do Cloud Storage. Use o utilitário do gerenciador de disco permanente para revisar os backups disponíveis listados no catálogo e selecione o IMAGE ID específico destinado à recuperação.
  2. Restaurar e anexar volumes: use o comando attach para automatizar a geração de discos permanentes de snapshots de backup. Essa única ação processa a criação e a conexão de todos os volumes relevantes à máquina virtual de destino.
  3. Montar dispositivos no nível do sistema operacional: depois que a conexão for concluída, conecte-se à instância de destino do Compute Engine para identificar os dispositivos de bloco recém-mapeados usando ferramentas como lsblk. Monte manualmente os sistemas de arquivos para acessar os dados recuperados ou inicie o processo de recuperação de aplicativos.

SAP HANA PD

Ao contrário dos backups do OnVault, que são montados diretamente como sistemas de arquivos locais, a restauração de snapshots de disco permanente do SAP HANA envolve o provisionamento de novos discos permanentes e a anexação deles à instância de destino do Compute Engine.

  1. Verifique os metadados e localize a imagem de backup: confira se o arquivo de catálogo de metadados do snapshot do Persistent Disk está disponível no bucket do Cloud Storage. Use a ferramenta de gerenciamento de disco permanente para inspecionar os backups catalogados e escolher o IMAGE ID necessário para recuperação.
  2. Provisione discos e anexe volumes: execute o comando attach para automatizar a geração de discos permanentes do snapshot de backup escolhido. Essa etapa cria todos os volumes necessários e os anexa à máquina virtual de destino em uma única operação.
  3. Montar dispositivos no nível do sistema operacional: depois que os discos forem anexados, conecte-se à VM de destino do SAP HANA e verifique se há novos dispositivos de bloco atribuídos usando ferramentas como lsblk. Ative os sistemas de arquivos manualmente para acessar os dados recuperados ou iniciar a restauração no nível do aplicativo.
  4. Recuperar o SAP HANA: depois de montar os volumes de dados, registros e registros de arquivo do SAP HANA, inicie o banco de dados do sistema (incluindo recuperação pontual, se necessário), seguido da recuperação e inicialização dos bancos de dados do locatário.

IBM Db2 DP

Ao contrário dos backups do OnVault, que são montados diretamente como sistemas de arquivos locais, a restauração de snapshots Persistent Disk do IBM Db2 exige o provisionamento de novos discos permanentes e a anexação deles à instância de destino do Compute Engine.

  1. Localize a imagem de backup e valide os metadados: verifique se o arquivo de catálogo de metadados do snapshot do Persistent Disk está presente no bucket designado do Cloud Storage. Use a ferramenta de gerenciamento de disco permanente para inspecionar os backups catalogados e identificar e selecionar o IMAGE ID de destino necessário para a recuperação.
  2. Anexe volumes e provisione discos: execute o comando attach para criar automaticamente discos permanentes do instantâneo de backup especificado. Essa única etapa provisiona todos os volumes necessários e os anexa diretamente à máquina virtual de destino.
  3. Montar sistemas de arquivos do sistema operacional: depois de anexar os discos, conecte-se à VM de destino do IBM Db2 para identificar dispositivos de bloco recém-mapeados usando ferramentas como lsblk. Monte manualmente os sistemas de arquivos para acessar os dados restaurados ou prossiga com a recuperação do aplicativo.
  4. Recuperar o banco de dados do aplicativo: depois de montar os volumes de dados, registros de transações e registros de arquivamento do Db2, catalogue cada instância do banco de dados do Db2, faça a recuperação do banco de dados conforme necessário e coloque o banco de dados on-line.

MySQL/MariaDB

  1. Localizar arquivos: localize o diretório de dados principal em db_volume/, que contém bancos de dados do usuário, esquema do sistema e espaços de tabela do InnoDB.

  2. Restaurar banco de dados: pare o serviço ativo do MySQL ou MariaDB. Para testar diretamente, ajuste a entrada datadir em my.cnf para segmentar a pasta de montagem de recuperação. Para uma restauração permanente, copie os arquivos do banco de dados para o armazenamento local (como /var/lib/mysql/) e verifique se a propriedade e as permissões do sistema de arquivos estão corretas.

  3. Colocar on-line e recuperar: reinicie o serviço de banco de dados. Se houver registros de transações binárias, faça uma recuperação pontual usando o utilitário mysqlbinlog.

PostgreSQL

  1. Localizar arquivos: no diretório db_volume/, identifique os recursos PGDATA, incluindo bancos de dados principais (base/, global/ e pg_wal/) e o arquivo de configuração postgresql.conf.

  2. Restaurar banco de dados: desligue a instância de destino do PostgreSQL. Para validação diretamente da montagem, aponte a variável de ambiente data_directory ou PGDATA para o caminho de recuperação. Para restaurar permanentemente, transfira a estrutura completa do diretório para o armazenamento local do host de destino.

  3. Abrir banco de dados: reinicie o serviço para colocar a instância on-line. Se for necessária a recuperação pontual, aplique os registros WAL arquivados da pasta log_files/ definindo um arquivo recovery.conf ou configurando o restore_command em postgresql.conf (para PostgreSQL 12 e versões mais recentes) e, em seguida, coloque o banco de dados on-line.

SAP ASE

  1. Localizar arquivos: identifique o dispositivo principal, além do banco de dados de usuários e dos dispositivos de registro específicos, localizados na pasta db_volume/ montada.

  2. Restaurar banco de dados: desligue a instância de destino do SAP ASE. Para a montagem direta, atualize a configuração RUN_server para redirecionar o parâmetro do dispositivo principal (como -d) para o caminho de recuperação. Ou transfira todos os recursos do dispositivo para os locais de armazenamento permanentes.

  3. Abrir banco de dados: inicia o processo do servidor de dados do SAP ASE. Se os registros de transações estiverem presentes, execute a operação LOAD TRAN para fazer a recuperação pontual antes de colocar o banco de dados on-line.

SAP MaxDB

  1. Localizar volumes: acesse o caminho de montagem db_volume/ para encontrar os arquivos de dados e de registros principais do SAP MaxDB.

  2. Restaurar ou redirecionar a configuração: pare o processo de destino do SAP MaxDB. Use o Gerenciador de banco de dados (dbmcli) para atualizar parâmetros como DataVolumeName e apontar para a ativação de recuperação ou copie os arquivos diretamente para o armazenamento local para uma restauração completa.

  3. Iniciar e colocar on-line: inicie a instância do banco de dados e defina o status operacional dela como ONLINE usando o Database Manager.

SAP IQ

  1. Localizar arquivos: acesse o diretório db_volume/ para identificar o armazenamento principal do SAP IQ, o armazenamento de catálogo (.db) e todos os ativos de armazenamento temporário associados.

  2. Restaurar banco de dados: desligue a instância de destino do SAP IQ. Para fazer a validação direta da montagem de recuperação, modifique os parâmetros de inicialização para referenciar o arquivo de catálogo montado. Para restauração permanente, transfira todos os volumes de armazenamento para o armazenamento local e verifique se a propriedade e as permissões adequadas do sistema de arquivos são mantidas.

  3. Abrir banco de dados: execute o utilitário start_iq para colocar a instância on-line e verificar a integridade de dados.

LVM/dump do IBM Db2

  1. Localizar arquivos: acesse os caminhos de montagem db_volume/ e log_files/. Com base no método de proteção, identifique os volumes de dados e de registros do LVM ou os recursos específicos da imagem de backup para recuperação baseada em despejo.
  2. Recuperar banco de dados (LVM): desligue a instância de destino do Db2. Transfira os dados do banco de dados e os volumes de registros de transações ativas da montagem de recuperação para o armazenamento local de destino, garantindo a propriedade correta do sistema de arquivos para o usuário e o grupo do Db2.
  3. Restaurar banco de dados (completo e incremental com base em despejo): interrompa as conexões ativas e exclua o banco de dados de destino, se ele existir. Use a ferramenta db2ckrst com o carimbo de data/hora específico do backup para catalogar a sequência incremental necessária. Execute a operação RESTORE para cada imagem na ordem prescrita.
  4. Abrir banco de dados: inicie a instância do Db2. Se o banco de dados permanecer em um estado pendente ou exigir recuperação pontual, aplique os registros de transações usando o utilitário db2 rollforward para concluir a recuperação e colocar a instância on-line.

Limpar recursos

Depois de copiar ou separar todos os arquivos de banco de dados necessários do mecanismo de banco de dados, desmonte com segurança os volumes ativos, separe os dispositivos de loop associados e remova os diretórios de preparo locais para evitar bloqueios residuais ou referências órfãs.

Para desmontar volumes e limpar o diretório de recuperação, execute os seguintes comandos:

python3 ~/gcbdr-onvault-cli/python/gcbdr_onvault.py \
  --mountpoint MOUNT_POINT \
  --unmount
rm -rf MOUNT_POINT

Substitua:

  • MOUNT_POINT: o caminho do diretório local em que o backup foi montado, como /tmp/recovery_folder.

A seguir