Perguntas frequentes – Fazer 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.

Hoje, trabalhos de backup bem-sucedidos não geram alertas. Os alertas ocorrem somente para trabalhos de backup com falha. Saiba como usar o portal do Azure para exibir alertas de backup.

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

1. Trabalhos de backup: o Backup do Azure mostra todos os trabalhos disparados manualmente na seção Trabalhos de backup no portal do Azure.
   
   Os trabalhos que você vê no portal do Azure incluem as operações de descoberta e registro de banco de dados e as operações de registro de backup e restauração. Os trabalhos agendados, incluindo backups de log, não são mostrados nesta seção. Os backups disparados 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 do SAP HANA. Eles ajudam você a se concentrar nos eventos necessários, eliminando assim o esforço de verificar com frequência a 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 dos trabalhos de backup. Seus resultados serão os seguintes:

   

   

   Saiba mais sobre Como configurar relatórios de Backup do Azure.

4. Clientes nativos do SAP HANA: se você é um cliente do SAP HANA, também pode usar o HANA Studio, um dos clientes mais comuns do HANA. Neste cliente, navegue até o Console de Backup ->Catálogo de Backup para ver o Status do Backup.

   

O menu Trabalho de Backup mostrará apenas trabalhos de backup sob demanda que estão em andamento, tiveram êxito 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 é retido até o momento em que você mantém o Delta dependente (diferencial ou incremental) e os backups de log. Quando você excluir o último backup dependente nesse 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 é disparado: o backup de log deve ser bem-sucedido independentemente de um backup completo contínuo. A menos que o backup completo disparado tenha sido uma correção completa para lidar com qualquer quebra de cadeia LSN.
• O backup de log está em andamento e um backup completo é disparado: ambos os backups devem ser executados simultaneamente e bem-sucedidos.

Não, não há suporte no momento.

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

Um banco de dados renomeado é tratado como um novo. Portanto, o serviço tratará essa situação como se o banco de dados não tivesse sido encontrado, e haverá falha nos backups. O banco de dados renomeado será exibido como um novo e deverá ser configurado para ter proteção.

Confira o tutorial com 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.

Confira 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 do guia de solução de problemas.

No momento, não é possível configurar a solução em um IP virtual ou Proxy. Precisamos de uma máquina virtual para executar a solução.

Você pode disparar 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 do SAP.

Você pode remover o catálogo do 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 do SAP.

Atualmente, o Backup do Azure não entende configurações do HSR. Isso significa que os nós primário e secundário do HSR serão tratados como duas VMs individuais não relacionadas. Primeiro, você precisará configurar o backup no nó primário. Quando ocorre um failover, é necessário configurar o backup 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 dos dados do nó ativo (primário) a qualquer momento, você pode alternar a proteção para o nó secundário, que agora se tornará o primário após o failover.

Para realizar a alternância de proteção, siga estas etapas:

• Interrompa 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 os backups neles

É necessário realizar as etapas manualmente após cada failover. Você pode realizá-las por meio de 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 da execução da alternância de proteção:

Neste exemplo, há dois nós na configuração do HSR: o nó 1 (primário) e o nó 2 (secundário). Os backups são configurados no nó 1. Conforme mencionado acima, não tente ainda configurar backups no nó 2.

Quando o primeiro failover ocorre, o nó 2 torna-se o primário. E, em seguida,

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

Em seguida, um primeiro backup completo é disparado no nó 2 e, após a conclusão, os backups de log são iniciados.

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

1. Interrompa a proteção do nó 2 com a opção de retenção dos dados.
2. Execute o script de pré-registro no nó 1 (que agora é o primário novamente)
3. Em seguida, retome o backup no nó 1 com a política necessária (já que os backups foram interrompidos anteriormente no nó 1).

Em seguida, um backup completo é disparado no nó 1 novamente e, após a conclusão, os backups de log são iniciados.

1. Na HSR (replicação do sistema HANA), o nó secundário não aceita nenhuma conexão. Após a configuração do backup, o serviço de Backup do Azure executa pings periodicamente e falha. Às vezes, essas tentativas com falha refletem no nó primário. Depois de 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 do bloqueio de usuários no nó primário quando a conexão do usuário falha no nó secundário.

2. Após executar o script de pré-registro, as informações do usuário são atualizadas com a nova senha no nó primário. Em seguida, a conexão para tentar o 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 não sejam feitas tentativas de conexão e o usuário não seja bloqueado) e retome a proteção nele, assim que ele se tornar primário. Se você não enfrentar essa situação de bloqueio em suas configurações da HSR e estiver acostumado com os alertas sendo gerados, é possível configurar backups nos dois nós para que o serviço trate da tomada de controle e do failback.

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

Para configurar seu sistema HANA para aproveitar o desempenho melhorado, use os recursos a seguir:

• Escolha um tipo de disco para VMs IaaS do Azure – discos gerenciados
• Níveis de desempenho para discos gerenciados do Azure
• Série M
• Configurações de armazenamento de máquina virtual do SAP HANA no Azure

No momento, 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 fluxo único em vários fluxos para aprimorar o desempenho.

Atualmente, somente backups baseados em Backint têm suporte para HSR. Os instantâneos ainda não têm suporte.

Execute uma nova detecção de instância no servidor que está marcado como "Não Pronto" para atualizar o status.

Você pode executar, no máximo, 10 restaurações por sistema ou instância do HANA 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 direcionar a instância SAP HANA são atendidos. Para obter mais informações, confira 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 a Nota 1642148 do SAP HANA para ver quais tipos de restauração têm suporte no momento.

Sim, você pode usar backups de streaming disparados em um banco de dados HANA em execução no SLES para restaurá-lo em um sistema do RHEL HANA e vice-versa. Ou seja, a restauração entre sistemas operacionais é possível usando backups de streaming. No entanto, é necessário que os sistemas HANA de origem e de destino da restauração sejam ambos compatíveis com a restauração segundo a SAP. Veja quais tipos de restauração são compatíveis na nota 1642148 do SAP HANA.

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

Sim, você precisa desabilitar a HSR (Replicação do Sistema HANA) no sistema de destino e executar a restauração. Você não pode restaurar um sistema habilitado por HSR, de acordo com o SAP.

Antes de criar uma política, você deve ter certeza sobre o RPO (Objetivo de Ponto de Recuperação) e o RTO (Objetivo de Tempo de Recuperação) necessários e as implicações de custo relevantes.

O RPO indica o nível de perda de dados que é aceitável para o usuário ou cliente. Isso é determinado pela frequência de backup de log. Backups de log mais frequentes indicam RPO inferior, e o valor mínimo com suporte pelo serviço do Backup do Azure é 15 minutos. Portanto, a frequência de backup de log pode ser de 15 minutos ou mais.

O RTO indica em quanto tempo os dados devem ser recuperados para o último ponto disponível após perda de dados. Isso depende da estratégia de recuperação usada pelo HANA, que geralmente depende de quantos arquivos são necessários para a restauração. Isso também afeta o custo, e a tabela abaixo ajuda a compreender todos os cenários e as implicações.

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

Você deve observar alguns princípios ao determinar o impacto da modificação de política de um item de backup da política 1 (P1) para a política 2 (P2) ou de editar a política 1 (P1).

• Todas as alterações também são aplicadas retroativamente. A política de backup mais recente também é aplicada aos pontos de recuperação feitos anteriormente. Por exemplo, suponha que a retenção completa diária seja de 30 dias e 10 pontos de recuperação foram feitos de acordo com a política ativa no momento. Se a retenção diária completa for alterada para 10 dias, a hora de expiração do ponto anterior também será recalculada como hora de início + 10 dias e excluída se tiver expirado.
• O escopo da alteração também inclui o dia do backup, o tipo de backup e a retenção. Por exemplo: se uma política for alterada de diário completo para semanal completo aos domingos, todos os completos anteriores que não foram realizados aos domingos serão marcados para exclusão.
• Um pai não é excluído até que o filho esteja ativo/não 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" posteriores. Um "diferencial" e um "log" não são pais para ninguém. Um "incremental" pode ser um pai para um "incremental" subsequente. Mesmo que um "pai" seja marcado para exclusão, ele só será excluído se os "diferenciais" ou os "logs" do filho expirarem. Por exemplo, se uma política for alterada de diário completo para semanal completo aos domingos, todos os completos anteriores que não foram realizados aos domingos serão marcados para exclusão. Mas eles não serão realmente excluídos até que os logs que foram feitos diariamente antes tenham expirado. Em outras palavras, eles são mantidos de acordo com a duração do log mais recente. Depois que os logs expirarem, os logs e esses completos serão excluídos.

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

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

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

Próximas etapas

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