Selecione um Método DR

Fazer Backup e Restaurar Volumes em Blocos

O principal objetivo dos backups é dar suporte à continuidade aos negócios, fazer a recuperação de desastres e o arquivamento de longo prazo.

Estes são casos de uso comuns para backups de volume em blocos:

Criando várias cópias do mesmo volume. Os backups são úteis quando você precisa de instâncias com muitos volumes que devem conter os mesmos dados.
Tirar um snapshot que você possa restaurar para um novo volume posteriormente.
Garantir que você tenha uma cópia confiável dos dados caso algo dê errado com o volume principal.

Ao definir seu plano de backup e metas, considere os seguintes fatores:

Frequência: Com que frequência você deseja fazer backup dos seus dados.
Tempo de recuperação: Quanto tempo você pode aguardar para que um backup seja restaurado e fique acessível aos aplicativos que o utilizam. O tempo para que um backup seja criado depende de vários fatores, como o tamanho dos dados que estão sendo submetidos a backup e o volume de dados que foram alterados desde o último backup.
Número de backups armazenados: Quantos backups você deve disponibilizar e a programação de exclusão para backups que não são mais necessários.

Ao criar backups e restaurá-los, considere as seguintes práticas recomendadas:

Antes de criar um backup, certifique-se de que os dados sejam consistentes: sincronize o sistema de arquivos, desmonte-o, se possível, e salve os dados do aplicativo. Somente os dados do disco são submetidos a backup. Ao criar um backup, depois que o estado do backup mudar de REQUEST_RECEIVED para CREATING, você poderá continuar a gravar dados no volume. Enquanto um backup está em andamento, o volume que está sendo feito não pode ser excluído.
Se você quiser anexar um volume restaurado à instância de computação que tenha o volume original anexado, observe que alguns sistemas operacionais não suportam a restauração de volumes idênticos. Para superar essa restrição, altere os IDs de partição antes de restaurar o volume. As etapas para alterar o ID da partição do sistema operacional dependem do sistema operacional. Consulte a documentação do sistema operacional da sua instância de computação.
Não exclua o volume original até verificar se o backup foi criado com sucesso.

Se seu aplicativo usar vários volumes que abrangem mais de uma instância de computação, então use backups de grupo de volumes. Os grupos de volumes simplificam o processo de criação de backups e clones para aplicativos que usam vários volumes em várias instâncias. Você pode restaurar um grupo inteiro de volumes usando um backup do grupo de volumes, conforme mostrado no diagrama a seguir.

Descrição da ilustração volume-backup-restore.png

Criar uma Luz do Piloto

O termo luz piloto refere-se a uma pequena chama em um aquecedor a gás tradicional que está sempre aceso e pode ser usado para reiniciar rapidamente o aquecedor quando acionado por sensores de temperatura na casa. No contexto da DR, uma luz piloto consiste nos principais componentes críticos do seu aplicativo, implantados no site de DR e que contêm a configuração mais recente do aplicativo e dados críticos. Esses principais componentes piloto-luz podem então ser usados para restaurar um ambiente de produção em caso de desastre.

Estes são os componentes críticos da luz piloto no site de DR:

Camada de Banco de Dados
O serviço Oracle Cloud Infrastructure Database permite que você provisione todo o seu banco de dados no site de DR (domínio de disponibilidade, região ou ambos) sem ativar recursos do tamanho da produção. Quando a DR estiver ativada, você poderá ativar mais recursos, com uma única chamada de API REST para o serviço sem reiniciar o servidor de banco de dados.
Camada de Aplicativos
Você implanta somente um servidor de aplicativos em seu site de DR (domínio de disponibilidade, região ou ambos) que contenha toda a configuração mais recente. Você pode usar o recurso de imagens personalizadas no Oracle Cloud Infrastructure para fazer backup de seu sistema operacional e aplicativos periodicamente e, em seguida, usar essas imagens para provisionar novos servidores quando o site de DR for ativado.

Por exemplo, se um site de produção contiver oito servidores de aplicativos, você implantará apenas um servidor de aplicativos no site de DR e o manterá sincronizado com o site principal usando rsync ou outra ferramenta. Você cria uma imagem personalizada deste servidor no site de DR diariamente que pode ser usada para provisionar os sete servidores restantes quando o DR é ativado.
Camada de Rede
Use os seguintes recursos e serviços do Oracle Cloud Infrastructure em sua luz piloto no site de DR
- Endereço IP (privado e público)
- Serviço DNS
- Serviço de balanceamento de carga

Usar um Standby Ativo

Um Standby Ativo (stand-by montado em verso) é um standby que é somente leitura aberto durante a recuperação do banco de dados. O standby ativo requer a funcionalidade e a licença do Active Data Guard.

Com o Active Data Guard, o standby físico pode ser utilizado para leituras e geração de relatórios reduzindo a carga de trabalho potencial no principal. O Active Data Guard fornece proteção de dados abrangente com reparo automático de bloqueio de corrompimentos de dados físicos e verifica outros tipos de corrompimentos de dados, como gravações perdidas e corrupções de blocos lógicos. Com o stand-by montado, você também aproveitará muitos dos benefícios de proteção de dados, exceto para reparo de bloqueio automático de corrupções de bloco físico. O tempo de recuperação (RTO) e a perda de dados (RPO) geralmente são muito baixos quando você faz failover para qualquer banco de dados stand-by, independentemente de ele ser somente para leitura aberto ou não.

Ao selecionar um método DR, considere se deseja recursos simétricos ou assimétricos:

Recursos simétricos: Essa é a arquitetura recomendada para que o standby seja simétrico com o sistema principal para garantir que o desempenho do aplicativo e do banco de dados seja semelhante ou idêntico no momento da transição de funções. Isso também garante que o banco de dados stand-by tenha recursos suficientes para acompanhar a carga de trabalho de produção, de modo que a perda de dados seja mínima no momento de um desastre. Se implantado como um Banco de Dados Standby Ativo ou com a opção Active Data Guard, o standby será aberto somente para leitura enquanto fornecer proteção de DR. Isso permite descarregar relatórios e consultas.
Recursos assimétricos: Esta arquitetura é uma configuração de redução do ambiente stand-by. Com o Active Data Guard, o standby ainda pode ser lido fornecendo os mesmos benefícios do trabalho de off-load para o standby. No entanto, após o failover, o desempenho pode não ser o mesmo, a menos que você amplie o sistema para corresponder ao principal.

Os sistemas standby assimétricos ou menores custam menos, mas podem ter menos computação, CPU e memória para reduzir os custos. A troca é após a transição de função ou um evento de failover, você deve ampliar (expandir) para corresponder ao seu sistema principal anterior ou aceitar desempenho inferior ou funcionalidade reduzida.

Usar um Standby Frio

O termo stand-by frio é usado para descrever um cenário de DR no qual uma réplica redundante do ambiente principal é implantada em um site de DR. O ambiente standby frio só será ativado se o sistema principal falhar. Essa abordagem fornece continuidade da produção com um tempo de ativação bem definido para o switchover.

O Oracle Cloud Infrastructure suporta a implantação automatizada (programática) de um ambiente stand-by frio que mantém o custo de manter esse ambiente no mínimo. Você só pagará pelos recursos ativos e por qualquer armazenamento persistente consumido no site de DR.