Backup Oracle com RMAN: Guia Prático 2026

Se existe uma frase que resume 25 anos administrando bancos Oracle é esta: backup sem teste é ilusão de segurança. Já vi empresas com rotinas de backup "funcionando" há anos descobrirem, na hora do desastre, que o backup estava incompleto, corrompido ou simplesmente irrecuperável.

O RMAN (Recovery Manager) é a ferramenta nativa da Oracle para backup e recuperação. É poderosa, flexível e, quando bem configurada, confiável. Mas "quando bem configurada" é a parte que faz toda a diferença.

Neste guia, vou te mostrar como configurar uma estratégia de backup Oracle profissional com RMAN — do básico ao avançado, incluindo backup em cloud.

1. Antes de tudo: ARCHIVELOG mode

Se o seu banco está em NOARCHIVELOG mode, pare tudo e resolva isso primeiro. Sem ARCHIVELOG, você não consegue fazer point-in-time recovery — ou seja, se perder dados, só consegue restaurar até o último backup full. Tudo que aconteceu depois, perdeu.

Se o resultado for NOARCHIVELOG, a conversão exige um restart do banco:

2. Configuração básica do RMAN

Antes de criar backups, configure o RMAN com padrões sensatos:

O que cada configuração faz:

• RECOVERY WINDOW OF 7 DAYS — Mantém backups suficientes para restaurar o banco em qualquer ponto dos últimos 7 dias. Ajuste conforme seu RPO.
• BACKUP OPTIMIZATION ON — Evita backups duplicados de datafiles que não mudaram.
• CONTROLFILE AUTOBACKUP ON — Fundamental. Sem o controlfile, você não consegue restaurar nada. O autobackup garante que ele seja salvo a cada operação.
• PARALLELISM 4 — Usa 4 canais simultâneos para backup. Ajuste conforme a capacidade de I/O do storage.
• COMPRESSION ALGORITHM 'MEDIUM' — Bom equilíbrio entre taxa de compressão e CPU. Use 'HIGH' se tiver CPU sobrando e quiser economizar espaço.

3. Tipos de backup: full vs incremental

Backup Full

Copia todos os blocos de dados utilizados. É a base de qualquer estratégia. Mais lento e ocupa mais espaço, mas é auto-suficiente para restauração.

O PLUS ARCHIVELOG DELETE INPUT faz backup dos archived logs e depois apaga os já salvos, liberando espaço na FRA.

Backup Incremental

Copia apenas os blocos que mudaram desde o último backup. Muito mais rápido e menor. A estratégia mais comum é:

• Level 0 — Base incremental (similar ao full, mas serve como ponto de partida para os incrementais)
• Level 1 Differential — Copia blocos alterados desde o último level 0 ou level 1 (padrão)
• Level 1 Cumulative — Copia tudo que mudou desde o último level 0 (restauração mais rápida, backup maior)

4. Backup com compressão e criptografia

Compressão

A compressão RMAN reduz significativamente o tamanho dos backups — tipicamente 60-80% de redução. Fundamental para quem envia backups pra cloud.

Criptografia

Para proteger backups em trânsito e em repouso (especialmente em cloud), habilite a criptografia:

5. Backup em Cloud: S3 e OCI Object Storage

Enviar backups pra cloud é a melhor forma de garantir proteção contra desastres físicos sem investir em storage offsite. As duas opções mais comuns para Oracle:

Amazon S3

Utiliza o Oracle Secure Backup Cloud Module (biblioteca SBT). Após instalar e configurar o módulo com suas credenciais AWS:

Oracle Cloud (OCI Object Storage)

A integração com OCI é nativa e usa a biblioteca libopc.so. Após configurar o módulo com tenancy, user e compartment da OCI:

A sintaxe RMAN é a mesma — o que muda é a configuração do canal SBT que aponta pra cada provedor. Para uma análise sobre qual provedor cloud é melhor pro seu cenário, veja nossa página de consultoria cloud Oracle.

6. Gerenciamento da FRA (Fast Recovery Area)

A FRA é o repositório padrão onde o RMAN guarda backups, archived logs e flashback logs. O erro mais comum que vejo é não monitorar o espaço da FRA. Quando ela enche, o banco trava — literalmente para de operar.

Regras básicas de gestão:

• Monitore diariamente — Configure alertas para 80% e 90% de uso
• DELETE OBSOLETE regularmente — RMAN> DELETE OBSOLETE; remove backups fora da retention policy
• Não deixe archived logs acumularem — Use PLUS ARCHIVELOG DELETE INPUT nos backups
• Dimensione adequadamente — Regra prática: FRA deve ter espaço para pelo menos 2x o tamanho do banco se usar flashback

7. Validação e teste de recuperação

Esta é a parte mais importante de toda estratégia de backup — e a mais negligenciada. Um backup que nunca foi testado não é um backup, é uma esperança.

Validar integridade sem restaurar

Isso verifica se todos os backup pieces estão legíveis e consistentes sem efetivamente restaurar nada.

Teste completo de recuperação (recovery drill)

Pelo menos trimestralmente, restaure o banco em um ambiente separado e valide:

1. O backup está completo (database + archived logs + controlfile)?
2. O tempo de restauração atende o RTO declarado?
3. Os dados estão íntegros após o restore?
4. O point-in-time recovery funciona?
5. A equipe sabe executar o procedimento?

Documente cada teste. Quando o desastre real acontecer (e uma hora acontece), a documentação vale ouro.

8. Checklist de backup profissional

1. Banco em ARCHIVELOG mode
2. RMAN com retention policy definida (alinhada ao RPO)
3. Controlfile autobackup habilitado
4. Block Change Tracking habilitado (para incrementais)
5. Compressão ativa (especialmente para cloud)
6. Criptografia para backups offsite
7. Cópia offsite ou em cloud (não só local)
8. FRA monitorada com alertas
9. DELETE OBSOLETE automatizado
10. Testes de recuperação trimestrais documentados

Se você marcar todos os 10 itens, seu backup Oracle está no nível profissional. Se faltam itens, cada um deles é uma vulnerabilidade que pode custar caro.