Perguntas frequentes – Faça backup de bancos de dados SAP HANA em VMs do Azure

Você pode ter um backup completo agendado e vários backups sob demanda em um dia.

Atualmente, os trabalhos de backup bem-sucedidos não geram alertas. Os alertas são gerados apenas para trabalhos de backup que falham. Saiba como usar o portal do Azure para exibir alertas de backup.

Você pode verificar o status de seus backups (agendados/sob demanda) de qualquer um dos seguintes locais:

1. Trabalhos de backup: o Backup do Azure mostra todos os trabalhos acionados manualmente na seção Trabalhos de backup no portal do Azure.
   
   Os trabalhos que você vê no portal do Azure incluem operações de descoberta e registro de banco de dados e operações de backup e restauração. Os trabalhos agendados, incluindo backups de log, não são mostrados nesta seção. Os backups acionados manualmente dos clientes nativos do SAP HANA (Studio/Cockpit/DBA Cockpit) também não são mostrados aqui.

   

   

2. Alertas de backup: os alertas ajudam a monitorar backups de bancos de dados SAP HANA. Isso ajuda você a se concentrar nos eventos necessários, eliminando assim o esforço de verificar com frequência uma infinidade de eventos gerados por um backup. Para obter mais detalhes, consulte Exibir alertas de backup.

3. Relatórios de backup: os relatórios são outra maneira de exibir o status de suas tarefas de backup. Os seus relatórios serão os seguintes:

   

   

   Saiba mais sobre como configurar relatórios do Backup do Azure.

4. Clientes SAP HANA nativos: Se você é um cliente SAP HANA, também pode usar o HANA Studio, um dos clientes HANA mais comuns. Neste cliente, navegue até Backup Console ->Backup Catalog para ver o status do backup.

   

O menu Trabalho de backup mostrará apenas os trabalhos de backup sob demanda que estão em andamento, foram bem-sucedidos ou falharam. Para trabalhos agendados, use o Azure Monitor.

O Backup do Azure não define um período de retenção explícito nos backups completos de recuperação automática. Esse backup é mantido até o momento em que você mantém os backups Delta (diferencial ou incremental) e Log dependentes. Depois de excluir o último backup dependente desse backup de recuperação automática, o backup de recuperação automática também será excluído.

Sim, um backup completo e um backup de log podem ser executados simultaneamente. Esta instância ocorre de uma das seguintes maneiras:

• O backup completo está em andamento e um backup de log é acionado: o backup de log deve ser bem-sucedido independentemente de um backup completo contínuo. A menos que o backup completo acionado fosse uma correção completa para lidar com qualquer quebra de cadeia LSN.
• O backup de log está em andamento e um backup completo é acionado: ambos os backups devem ser executados simultaneamente e bem-sucedidos.

Não, isso não é suportado no momento.

Se um banco de dados for descartado de uma instância do SAP HANA, os backups do banco de dados ainda serão tentados. Isso implica que o banco de dados excluído começa a aparecer como não íntegro em Itens de backup e ainda está protegido. A maneira correta de parar de proteger esse banco de dados é executar Stop Backup com dados de exclusão nesse banco de dados.

Um banco de dados renomeado é tratado como um novo banco de dados. Portanto, o serviço tratará essa situação como se o banco de dados não fosse encontrado e falhará nos backups. O banco de dados renomeado aparecerá como um novo banco de dados e deve ser configurado para proteção.

Consulte o tutorial para obter um guia passo a passo para começar a usar o Backup do Azure para bancos de dados SAP HANA. Você também pode usar a CLI para configurar e gerenciar backups.

Consulte os pré-requisitos para usar o Backup do Azure com SAP HANA.

Consulte esta seção do guia de solução de problemas.

Consulte esta seção no guia de solução de problemas.

Atualmente não temos a capacidade de configurar a solução contra um IP ou proxy virtual. Precisamos de uma máquina virtual para executar a solução.

Você pode acionar um backup sob demanda usando clientes nativos do SAP HANA para o sistema de arquivos local em vez de Backint. Saiba mais sobre como gerenciar operações usando clientes nativos SAP.

Você pode remover o catálogo HANA usando métodos recomendados pelo SAP, como instruções BACKUP CATALOG DELETE ou HANA Studio/Cockpit. Saiba mais sobre como gerenciar operações usando clientes nativos SAP.

Atualmente, o Backup do Azure não tem a capacidade de entender uma configuração de HSR. Isto significa que os nós primário e secundário do HSR serão tratados como duas VMs individuais e não relacionadas. Primeiro, você precisará configurar o backup no nó principal. Quando ocorre um failover, o backup deve ser configurado no nó secundário (que agora se torna o nó primário). Não há failover automático de backup para o outro nó.

Para fazer backup de dados do nó ativo (principal) em qualquer point-in-time, você pode alternar a proteção para o nó secundário que agora se tornou o principal após o failover.

Para executar essa proteção de switch, execute estas etapas:

• Parar a proteção (com retenção de dados) no primário
• Execute o script de pré-registro no nó secundário
• Descubra os bancos de dados no nó secundário e configure backups neles

Essas etapas devem ser executadas manualmente após cada failover. Você pode executar essas etapas por meio da linha de comando / HTTP REST além do portal do Azure. Para automatizar essas etapas, você pode usar um runbook do Azure.

Aqui está um exemplo detalhado de como a proteção do switch deve ser executada:

Neste exemplo, você tem dois nós - Nó 1 (primário) e Nó 2 (secundário) na configuração HSR. Os backups são configurados no Nó 1. Como mencionado acima, ainda não tente configurar backups no Nó 2.

Quando o primeiro failover acontece, o Nó 2 se torna o principal. Em seguida,

1. Pare a proteção do Nó 1 (primário anterior) com a opção reter dados.
2. Execute o script de pré-registro no Nó 2 (que agora é o principal).
3. Descubra bancos de dados no Nó 2, atribua políticas de backup e configure backups.

Em seguida, um primeiro backup completo é acionado no Nó 2 e, depois que isso é concluído, os backups de log são iniciados.

Quando o próximo failover acontece, o Nó 1 torna-se primário novamente e o Nó 2 torna-se secundário. Agora repita o processo:

1. Pare a proteção do Nó 2 com a opção de retenção de dados.
2. Execute o script de pré-registro no Nó 1 (que se tornou o principal novamente)
3. Em seguida, retome o backup no Nó 1 com a política necessária (pois os backups foram interrompidos anteriormente no Nó 1).

Em seguida, o backup completo será novamente acionado no Nó 1 e, depois que isso for concluído, os backups de log serão iniciados.

1. Para replicação do sistema HANA (HSR), o nó secundário não aceita nenhuma conexão. Depois que o backup é configurado, o serviço de Backup do Azure executa pings periodicamente e falha. Às vezes, essas tentativas fracassadas refletem no nó primário. Após várias falhas, o usuário é bloqueado e, em seguida, o nó primário começa a falhar com ODBCConnectionError.
   
   Observamos que todos os usuários não enfrentam esse problema. Recomendamos que você/SAP investigue a causa dos usuários ficarem bloqueados no nó primário quando a conexão do usuário falhar no nó secundário.

2. Depois de executar o script de pré-registro, as informações do usuário são atualizadas com uma nova senha no nó principal. Em seguida, a conexão para tentar backup será restabelecida. Mas, você pode experimentar novamente o mesmo cenário.

3. Além disso, os backups (backups completos) que falham no nó secundário criam alertas.

Para evitar os problemas acima, recomendamos que você interrompa a proteção de um nó depois que ele se tornar secundário (para que as conexões não sejam tentadas e o usuário não seja bloqueado) e retome a proteção nele, uma vez que ele se torne primário. Se você não enfrentar essa situação de bloqueio em suas configurações de HSR e se sentir confortável com alertas sendo gerados, poderá configurar backups em ambos os nós para que o serviço lide com a tomada de controle e failback.

Consulte o desempenho da taxa de transferência de backup e restauração que o Backup do Azure fornece para cargas de trabalho HANA.

Para configurar seu sistema HANA para aproveitar o desempenho aprimorado, use os seguintes recursos:

• Selecione um tipo de disco para VMs IaaS do Azure - discos gerenciados
• Camadas de desempenho para discos gerenciados do Azure
• Série M
• Configurações de armazenamento de máquina virtual do SAP HANA Azure

Atualmente, o Backup do Azure para SAP HANA aceita 1 como o valor da propriedade parallel_backup_using_backint. No entanto, o Backup do Azure divide esse único fluxo em vários fluxos para obter um melhor desempenho.

Atualmente, apenas backups baseados em Backint são suportados para HSR. Os instantâneos ainda não foram.

Você precisa executar a nova deteção de instância no servidor marcado como "Não pronto" para atualizar seu status.

Você pode executar um máximo de 10 restaurações por sistema HANA ou instância em um dia. Observe que, se uma restauração for cancelada ou falhar, ela também será considerada uma tentativa de restauração.

Verifique se todos os pré-requisitos para a restauração para a instância do SAP HANA de destino foram atendidos. Para obter mais informações, consulte Pré-requisitos - Restaurar bancos de dados SAP HANA na VM do Azure.

Verifique se a opção Forçar substituição está selecionada durante a restauração.

Consulte o 1642148 de notas do SAP HANA para ver quais tipos de restauração são suportados atualmente.

Sim, você pode usar backups de streaming acionados em um banco de dados HANA em execução no SLES para restaurá-lo em um sistema RHEL HANA e vice-versa. Ou seja, a restauração cruzada do sistema operacional é possível usando backups de streaming. No entanto, você terá que garantir que o sistema HANA para o qual deseja restaurar e o sistema HANA usado para restauração sejam compatíveis para restauração de acordo com o SAP. Consulte o SAP HANA Note 1642148 para ver quais tipos de restauração são compatíveis.

Sim, você pode baixar arquivos parcialmente conforme documentado aqui.

Sim, você precisa desabilitar a replicação do sistema HANA (HSR) no sistema de destino e, em seguida, executar a restauração. Não é possível restaurar um sistema habilitado para HSR, de acordo com o SAP.

Antes de criar uma política, você deve ser claro sobre os requisitos de RPO e RTO e suas implicações de custo relevantes.

RPO (Recovery-point-objective) indica quanta perda de dados é aceitável para o usuário/cliente. Isso é determinado pela frequência de backup de log. Backups de log mais frequentes indicam RPO mais baixo e o valor mínimo suportado pelo serviço de Backup do Azure é de 15 minutos. Portanto, a frequência de backup de log pode ser de 15 minutos ou mais.

RTO (Recovery-time-objective) indica a rapidez com que os dados devem ser restaurados para o último point-in-time disponível após um cenário de perda de dados. Isso depende da estratégia de recuperação empregada pelo HANA, que geralmente depende de quantos arquivos são necessários para restauração. Isso também tem implicações de custo, e a tabela a seguir deve ajudar a entender todos os cenários e suas implicações.

Portanto, você pode selecionar a variante de política com base em objetivos de RPO e RTO e considerações de custo.

Alguns princípios devem ser mantidos em mente ao determinar o impacto da mudança da política de um item de backup da Política 1 (P1) para a Política 2 (P2) ou da edição da Política 1 (P1).

• Todas as alterações também são aplicadas retroativamente. A política de backup mais recente também é aplicada nos pontos de recuperação tomados anteriormente. Por exemplo, suponha que a retenção total diária é de 30 dias e 10 pontos de recuperação foram tomados de acordo com a política atualmente ativa. Se a retenção do total diário for alterada para 10 dias, o tempo de expiração do ponto anterior também será recalculado como hora de início + 10 dias e excluído se tiver expirado.
• O escopo da alteração também inclui dia de backup, tipo de backup e retenção. Por exemplo: se uma política for alterada de diária completa para semanal completa aos domingos, todas as cheias anteriores que não estiverem aos domingos serão marcadas para exclusão.
• Um pai não é excluído até que a criança esteja ativa/não tenha expirado. Cada tipo de backup tem um tempo de expiração de acordo com a política ativa no momento. Mas um tipo de backup completo é considerado como pai para "diferenciais", "incrementais" e "logs" subsequentes. Um 'diferencial' e um 'log' não são pais de mais ninguém. Um «incremental» pode ser um progenitor do «incremental» subsequente. Mesmo que um "pai" esteja marcado para exclusão, ele não será realmente excluído se os "diferenciais" ou "logs" da criança não tiverem expirado. Por exemplo, se uma política for alterada de diária completa para semanal completa aos domingos, todas as cheias anteriores que não estiverem aos domingos serão marcadas para exclusão. Mas eles não são realmente excluídos até que os logs que foram feitos diariamente anteriormente estejam expirados. Em outras palavras, eles são retidos de acordo com a duração do log mais recente. Quando os logs expirarem, tanto os logs quanto esses registros completos serão excluídos.

Com esses princípios, você pode ler a tabela a seguir para entender as implicações de uma mudança de política.

Você pode gerenciar o espaço na pasta raiz usando uma das seguintes opções:

• Crie um LV próprio para /opt/msawb.
• Crie um link simbólico de soft link/para outro local/pasta no mesmo disco/diferente.
• Aumente o espaço na partição raiz.

Próximos passos

• Saiba como fazer backup de bancos de dados SAP HANA em execução em VMs do Azure.
• Saiba como solucionar problemas de backup de banco de dados SAP HANA.