Você pode usar a tecnologia NetApp Snapshot para criar backups de banco de dados em minutos. O tempo necessário para criar uma cópia de Snapshot é independente do tamanho do banco de dados, pois uma cópia de Snapshot não move nenhum bloco de dados físico na plataforma de armazenamento. Além disso, o uso da tecnologia Snapshot não afeta o desempenho do sistema SAP em produção, uma vez que todas as operações são executadas no sistema de armazenamento. Portanto, você pode agendar a criação de cópias de instantâneo sem levar em consideração os períodos de pico de diálogo ou atividade em lote. Os clientes SAP on NetApp normalmente agendam vários backups de Snapshot online durante o dia; por exemplo, a cada seis horas é comum. Esses backups instantâneos são normalmente mantidos por três a cinco dias no sistema de armazenamento primário antes de serem removidos ou transferidos para um armazenamento mais barato para retenção a longo prazo.

As cópias instantâneas também oferecem vantagens importantes para operações de restauração e recuperação. Uma operação de restauração recupera os dados no sistema de arquivos com base no estado de um backup. Uma operação de recuperação é usada para restaurar o estado do banco de dados para um ponto específico no tempo, utilizando backups dos logs do banco de dados.

A tecnologia NetApp SnapRestore permite a restauração de um banco de dados inteiro ou, alternativamente, apenas de uma parte dele, com base nos backups Snapshot disponíveis no momento. O processo de restauração é concluído em poucos segundos, independentemente do tamanho do banco de dados. Como vários backups instantâneos online podem ser criados durante o dia, o tempo necessário para o processo de recuperação é significativamente reduzido em comparação com a abordagem tradicional de backup uma vez por dia. Como é possível realizar uma restauração com uma cópia de Snapshot que tenha no máximo algumas horas (em vez de até 24 horas), menos registros de transação precisam ser aplicados durante a recuperação. O tempo necessário para restauração e recuperação é significativamente reduzido em comparação com os backups de streaming tradicionais.

Como os backups de Snapshot são armazenados no mesmo sistema de disco que os dados online ativos, a NetApp recomenda usar as cópias de backup de Snapshot como um complemento, e não como uma substituição, para backups em um local secundário. A maioria das ações de restauração e recuperação são gerenciadas usando o SnapRestore no sistema de armazenamento primário. A restauração a partir de um local secundário só é necessária se o sistema de armazenamento primário que contém as cópias do Snapshot não estiver disponível. Você também pode usar o backup secundário caso seja necessário restaurar um backup que não esteja mais disponível no armazenamento primário.

O backup para um local secundário é baseado em cópias de snapshot criadas no armazenamento primário. Dessa forma, os dados são lidos diretamente do sistema de armazenamento primário sem gerar carga no servidor de banco de dados SAP e em sua rede. O armazenamento primário comunica-se diretamente com o armazenamento secundário e replica os dados de backup para o destino usando a funcionalidade de backup SnapVault ou ANF.

O SnapVault e o backup ANF oferecem vantagens significativas em comparação com os backups tradicionais. Após uma transferência inicial de dados, onde todos os dados são transferidos da origem para o destino, todos os backups subsequentes replicam apenas os blocos alterados para o armazenamento secundário. Portanto, a carga no sistema de armazenamento primário e o tempo necessário para um backup completo são significativamente reduzidos. Como apenas os blocos alterados são armazenados no destino, qualquer backup completo adicional do banco de dados consome significativamente menos espaço em disco.

A figura a seguir mostra o HANA Studio de um cliente usando operações de backup de Snapshot. A imagem mostra que o banco de dados HANA (com aproximadamente 4 TB de tamanho) é copiado em 1 minuto e 20 segundos usando a tecnologia de backup Snapshot e em mais de 4 horas com uma operação de backup baseada em arquivos.

A maior parte do tempo total de execução do fluxo de trabalho de backup é o tempo necessário para executar a operação de Snapshot do banco de dados HANA. O backup do snapshot de armazenamento em si é concluído em poucos segundos, independentemente do tamanho do banco de dados HANA.

Esta seção apresenta uma comparação do objetivo de tempo de recuperação (RTO) de backups de Snapshot baseados em arquivos e backups de Snapshot baseados em armazenamento. O RTO é definido pela soma do tempo necessário para restaurar, recuperar e, em seguida, iniciar o banco de dados.

A execução de backups é uma parte essencial de qualquer estratégia de proteção de dados. Os backups são programados regularmente para garantir que você possa se recuperar de falhas do sistema. Esse é o caso de uso mais óbvio, mas também há outras tarefas de gerenciamento de ciclo de vida do SAP, onde acelerar as operações de backup e recuperação é crucial.

A atualização do sistema SAP HANA é um exemplo em que um backup sob demanda antes da atualização e uma possível operação de restauração, caso a atualização falhe, têm um impacto significativo no tempo de inatividade planejado. Com o exemplo de um banco de dados de 4 TB, você pode reduzir o tempo de inatividade planejado em 8 horas, ou seja, terá mais 8 horas para analisar e corrigir erros usando as operações de backup e restauração baseadas em snapshots.

Outro caso de uso seria um ciclo de teste típico, onde os testes devem ser realizados em múltiplas iterações com diferentes conjuntos de dados ou parâmetros. Ao aproveitar as operações rápidas de backup e restauração, você pode facilmente criar pontos de salvamento dentro do seu ciclo de teste e redefinir o sistema para qualquer um desses pontos de salvamento anteriores caso um teste falhe ou precise ser repetido. Isso permite que os testes terminem mais cedo ou que mais testes sejam realizados simultaneamente, melhorando os resultados.

Após a implementação dos backups de snapshot, eles podem ser usados para atender a diversos outros casos de uso que exigem cópias de um banco de dados HANA. Você pode criar um novo volume com base no conteúdo de qualquer backup de Snapshot disponível. O tempo de execução desta operação é de alguns segundos, independentemente do tamanho do volume.

O caso de uso mais comum é a atualização do sistema SAP, onde os dados do sistema de produção precisam ser copiados para o sistema de teste ou de controle de qualidade. Ao aproveitar o recurso de clonagem do ONTAP ou ANF, você pode provisionar o volume para o sistema de teste a partir de qualquer cópia Snapshot do sistema de produção em questão de segundos. O novo volume deve então ser anexado ao sistema de teste e o banco de dados HANA deve ser recuperado.

O segundo caso de uso é a criação de um sistema de reparo, utilizado para solucionar problemas de corrupção lógica no sistema de produção. Neste caso, um backup Snapshot mais antigo do sistema de produção é usado para iniciar um sistema de reparo, que é um clone idêntico do sistema de produção com os dados anteriores à ocorrência da corrupção. Em seguida, o sistema de reparo é usado para analisar o problema e exportar os dados necessários antes que sejam corrompidos.

O último caso de uso é a capacidade de executar um teste de failover de recuperação de desastres sem interromper a replicação e, portanto, sem influenciar o RTO (Objetivo de Tempo de Recuperação) e o RPO (Objetivo de Ponto de Recuperação) da configuração de recuperação de desastres. Quando a replicação ONTAP SnapMirror ou a replicação entre regiões ANF é usada para replicar os dados para o site de recuperação de desastres, os backups de Snapshot de produção também ficam disponíveis no site de recuperação de desastres e podem ser usados ​​para criar um novo volume para testes de recuperação de desastres.