Por que eu devo ler este artigo:Esse artigo descreve como o DBA responsável pelo backup de uma empresa, de médio ou grande porte, deve definir e criar as operações de backup.

Será descrito um tutorial de criação e recuperação do backup, destinado à administradores de banco de dados com o mínimo conhecimento sobre a estrutura do Oracle database.

A discussão desse tema é extremamente útil para o dia a dia do DBA responsável pelo backup da empresa, pois este artigo contém informações que ajudarão os administradores de banco de dados a definir e defender suas teses de como o backup deve ser configurado e executado.

Hoje em dia as empresas estão, mais do que nunca, procurando manter seus dados seguros e de maneira que sua recuperação seja a mais rápida possível. Pensando nisso, o administrador de banco de dados deve sempre ter em mente quais são suas opções e melhores práticas utilizadas e disponíveis no mercado.

Baseado em um conjunto de experiências, serão descritos nesse artigo alguns caminhos e atalhos para facilitar a vida dos administradores que estão começando e até mesmo alguns que estarão reconfigurando seus backups.

Esse artigo não abrangerá ferramentas proprietárias, serão apenas consideradas técnicas que podem ser utilizadas usando as ferramentas disponíveis em qualquer banco de dados Oracle 11g.

Primeiramente vamos construir um cenário: imaginem uma empresa que trabalhe 24/7 (vinte e quatro horas por dia e sete dias por semana) com um database de 500 gigabytes com um grande índice de atualização e que necessita de backup constante (diário) e com um planejamento de tempo de recovery mais baixo possível.

Uma boa estratégia de backup é baseada em três siglas que descreverei mais a fundo nos próximos tópicos. Elas definem o tempo que o recovery deverá demorar, tal como o tempo entre os backups, tanto completo quanto incremental e qual o nível de granularidade que os tipos de backups devem chegar, até qual ponto é possível restaurar e qual objeto eu posso retornar do backup.

Em todos esses pontos, é importantíssimo que sejam definidos com a ajuda da área de negócio, ou seja, toda a estratégia de backup deve ser feita cumprindo as expectativas da área de negócio em conjunto com tempos reais de backup e recovery.

Uma estratégia de backup sólida é baseada em um completo alinhamento entre as áreas, tanto a responsável pelo backup quanto a de negócio, assim teremos um denominador comum entre a expectativa do cliente e o tempo real possível para o retorno das informações.

Devemos levar em conta a taxa de crescimento do database, pois esse fator influencia diretamente no tempo em que um backup completo levaria para restaurar após uma falha completa do sistema ou um crash de disco.

Tenha em mente que essa parte é apenas para descrever como funciona a expectativa da área de negócio em conjunto com o mundo da TI. Não se preocupe agora com a parte técnica, essa será discutida mais à frente nesse artigo.

RTO - Recover Time Objective

Devemos sempre levar em conta que o recovery é a parte mais importante do backup. Encorajo a prática de fazer diversos testes de recovery para assim ter o processo mais maduro e eficiente possível, pois com diversos testes poderemos automatizar os scripts de backup e recovery, tal como termos a noção exata do tempo que levará para efetuar um recovery completo, a confiabilidade do backup realizado e também das mídias utilizadas no mesmo.

O RTO ou Recover Time Objective é todo o tempo que leva desde um “crash” ou perda total dos dados, até o ponto em que o sistema está totalmente operacional e disponível para os usuários reiniciarem os serv ...

Quer ler esse conteúdo completo? Tenha acesso completo