Com muita frequência, vejo pessoas fazendo perguntas sobre estratégias de backup que devem empregar para seus bancos de dados. Parece que nunca falha, todas as perguntas desse tipo que encontrei em vários fóruns nunca incluem seus requisitos de recuperação. Muitas vezes, fiquei perplexo ao considerar seus requisitos de recuperação antes de projetar sua estratégia de backup. Quando pressionado por requisitos, geralmente recebo requisitos de backup, por exemplo:

• Os backups não devem causar tempo de inatividade
• Precisa ser capaz de fazer backup de redo logs arquivados
• Os backups devem ser gravados em fita

Esses requisitos são muito bons, mas, na minha opinião, você nunca deve projetar sua estratégia de backup sem primeiro documentar seus requisitos de recuperação e obter a ocorrência de gerenciamento.

Então, aqui estão algumas perguntas que me faço ao projetar uma estratégia de backup. Observe que essas perguntas estão todas focadas no lado da recuperação.

1. Quanta perda de dados posso suportar ao restaurar o banco de dados? Zero perda de dados? Uma hora de perda de dados é aceitável após a recuperação do banco de dados?
2. Preciso avançar alguma transação, ou seja, realizar uma restauração pontual?
3. Precisarei restaurar o conteúdo de um esquema deixando os outros esquemas intactos?
4. Quanto tempo tenho para colocar o banco de dados em funcionamento após uma falha?
5. De que tipo de falhas devo me recuperar? Obviamente, preciso ser capaz de restaurar a partir de uma falha completa do servidor ou perda de um disco. Mas preciso ser capaz de me recuperar de falhas humanas, como alguém que excluiu acidentalmente uma tabela?
6. Serei obrigado a restaurar o backup para outros servidores como parte da atualização de banco de dados de desenvolvimento ou teste de uma cópia de produção?

Se você perguntar à maioria das pessoas na comunidade Oracle hoje em dia, elas dirão para você usar o RMAN para fazer backup do seu banco de dados. O RMAN é um ótimo produto e, para muitas coisas, é melhor do que os backups quentes ou frios gerenciados pelo usuário à moda antiga. Alguns DBAs Oracle dirão para você usar o RMAN para realizar backups dinâmicos e executar seu banco de dados de produção no modo de log de arquivo. Ao fazer isso, você cobrirá muitos dos cenários de recuperação que provavelmente enfrentará. Mas e se sua resposta à pergunta 4 for que você tem 1 hora para voltar a funcionar e seu banco de dados tiver 10 TB de tamanho. Boa sorte ao tentar fazer uma restauração completa de um banco de dados de 10 TB em 1 hora com o RMAN. E o RMAN não poderá ajudar na questão 3, pois o RMAN não faz backup no nível do esquema.

Existem muitas ferramentas à disposição do DBA para fazer backup e recuperar dados no banco de dados. Essas ferramentas incluem, mas não estão limitadas também:

• Gerenciador de recuperação da Oracle (RMAN)
• Backups gerenciados pelo usuário Oracle
• Exportação/importação Oracle ou Data Pump
• Snapshots baseados em disco
• Replicação baseada em disco
• Protetor de dados da Oracle

Então qual você usa? Bem, cada um tem seus prós e contras. Depois de conhecer seus requisitos de recuperação, as ferramentas para fazer backup de seu banco de dados começam a ficar mais claras. E pode ser necessário empregar mais de uma ferramenta de backup para atender a todos os seus requisitos de recuperação. Se você usar, como sugestão, o RMAN com o modo Archive Log e nada mais, e seu gerente vier até você e disser “você precisa colocar esse banco de dados de 10 TB em funcionamento em 1 hora!” seu trabalho pode estar em jogo.

O que leva ao próximo ponto, documente seus requisitos de recuperação e coloque-os em seu Acordo de Nível de Serviço (SLA). Ao redigir e verificar o SLA, sua gerência pode dizer que deseja zero perda de dados. É neste momento que você pode trazer os prós e contras da implementação de uma solução de perda zero de dados... e também mencionar os custos! Muitas empresas recusam o alto custo de uma solução de perda zero de dados, mas para outras empresas, o custo é pequeno quando comparado ao ônus financeiro de perder qualquer transação. É aqui que a pechincha e a troca entram em jogo. Se a administração insistir em uma solução de perda zero de dados, então eles terão que arranjar os fundos para apoiá-la porque o RMAN (gratuito) não vai fornecê-la. Depois de documentar seus requisitos de recuperação no SLA, será difícil para o gerenciamento solicitar que você recupere algo que sua estratégia de backup não foi projetada para suportar. Se o SLA estiver em vigor e eles solicitarem que você recupere todas as transações e sua estratégia de backup não permitir, você terá um documento que diz que a perda zero de dados nunca foi necessária e isso pode ajudar a salvar seu trabalho.

Dito isso, depois de ter seus requisitos de recuperação documentados no SLA, certifique-se de que sua estratégia de backup permitirá que você execute todos os cenários de recuperação documentados no SLA. Seu trabalho pode depender disso. Se o SLA indicar perda zero de dados e você não implementar o Data Guard, mesmo que a gerência esteja disposta a financiá-lo, eles poderão demiti-lo porque você não estava cumprindo seu trabalho.

Finalmente, nenhuma estratégia de backup/recuperação está completa a menos que seja completamente testada. Você deve testar todas as estratégias de recuperação necessárias para garantir que possa atender a todos os requisitos declarados no SLA. O teste deve ser realizado pelo menos uma vez por ano por dois motivos... um, garante que as alterações no sistema não afetem negativamente sua capacidade de realizar uma recuperação necessária e dois, mantém você atualizado sobre como realizar a recuperação para que se você tem que fazer isso de verdade, você não está se atrapalhando com o procedimento. Nos testes, você pode descobrir que sua metodologia de backup oferecerá suporte a cenários de recuperação necessários, mas é bom ter se você precisar deles.

E não posso dizer o suficiente….Teste, teste e teste!