Backup Oracle de verdade combina quatro camadas: dump lógico (expdp), archive logs em tempo real, histórico de archives compactado e datafiles completos. Com isso você recupera até o último segundo antes do problema — e ainda sobe o banco em outro servidor, inclusive em outro sistema operacional.
Mas Maurício, o DBA disse que o Oracle já tem backup configurado — pode confiar?
Depende muito do que esse backup cobre. Oracle é um mundo à parte. Cada empresa tem um DBA, e cada DBA faz do seu jeito. Já vi casos em que o backup existia, o script rodava todo dia, mas na hora de subir em outro servidor… ninguém sabia o que fazer. O arquivo estava lá — a estratégia, não.
Vou te mostrar como a maioria dos clientes da WSpeed que usam backup Oracle organiza isso na prática: quatro tipos de backup que, juntos, cobrem desde a recuperação de um objeto isolado até um disaster recovery completo em outro servidor.
Se você ainda está construindo o conceito de por que copiar o arquivo do banco em uso não funciona, recomendo dar uma lida no backup de banco de dados antes de continuar. E se o conceito de backup em si ainda está nebuloso, começa pelo o que é backup.
Por que backup Oracle é diferente dos outros SGBDs?
A maioria dos bancos de dados tem uma estratégia de backup razoavelmente padronizada. No Firebird você usa o gbak. No SQL Server, o BACKUP DATABASE. No PostgreSQL, o pg_dump. Em cada um desses, o caminho é mais ou menos conhecido.
No Oracle, a história é outra. A arquitetura é mais complexa — o banco trabalha com datafiles, control files, redo logs, archive logs, tablespaces, e ainda tem o modo ARCHIVELOG que precisa estar habilitado pra uma parte essencial da estratégia funcionar. A ferramenta oficial é o RMAN (Recovery Manager), mas a forma de usar varia muito de empresa pra empresa.
Sendo honesto: em Oracle, normalmente tem um DBA e cada um faz do seu jeito. Não é crítica — é a realidade do ecossistema. O que importa é que, qualquer que seja o jeito, a estratégia precisa cobrir os quatro tipos que vou explicar agora.
Quais são os 4 tipos de backup que clientes WSpeed usam no Oracle?
Na prática, a maioria das empresas que atendemos com Oracle trabalha com quatro camadas de backup. Cada uma serve pra uma coisa diferente, e nenhuma substitui a outra.
| Tipo | O que é | Pra que serve | Recupera até quando? |
|---|---|---|---|
| Dump lógico (expdp/exp) | Exportação lógica de objetos e dados do banco | Portabilidade, migração, recuperação de objetos isolados | Ponto fixo da exportação (não é contínuo) |
| Archive em tempo real | Archived redo logs gerados continuamente com o banco em uso | Garantir que nenhuma transação seja perdida entre backups completos | Até o último instante antes da falha |
| Archives compactados (histórico) | Logs de archive acumulados e compactados ao longo do tempo | Guardar o histórico de alterações para recuperação point-in-time | Qualquer ponto no passado coberto pelo histórico |
| Online / datafiles completos | Cópia física dos datafiles completos do banco (via RMAN) | Subir o banco inteiro do zero — inclusive em outro servidor ou SO | Ponto do último backup físico + archives aplicados |
O dump lógico (expdp): pra que serve de verdade?
O dump lógico é gerado pelo utilitário expdp (Data Pump Export) — ou pelo exp nas versões mais antigas do Oracle. Ele exporta objetos do banco: tabelas, views, procedures, sequences, usuários.
O ponto forte do dump é a portabilidade. Se você precisa mover dados de um banco pra outro, restaurar uma tabela específica que foi apagada por engano, ou migrar pra uma versão diferente do Oracle, o dump lógico é o caminho.
O ponto de atenção: o dump lógico não é contínuo. Ele captura o estado do banco no momento da exportação. Se você faz o dump às 22h e o banco falha às 15h do dia seguinte, você perdeu tudo que aconteceu nessas 17 horas. É por isso que o dump sozinho não é suficiente — ele precisa trabalhar junto com os archives.
O que é archive log e por que ele é o pulo do gato?
Você já se perguntou: e se o backup completo rodar à meia-noite, mas o banco falhar às 14h — o que acontece com as 14 horas de trabalho do dia?
Sem archive log, você perde. Com archive log, você não perde nada.
Quando o Oracle está em modo ARCHIVELOG, ele guarda continuamente o registro de cada transação ocorrida no banco — os chamados archived redo logs. Pense neles como um diário em tempo real: “às 09h14, o usuário alterou esse registro; às 09h15, esse outro registro foi inserido…”. Cada log fica armazenado em disco assim que é gerado.
Com os archive logs, você consegue recuperar o banco até o último instante antes da falha — isso se chama recuperação point-in-time, e é a diferença entre perder um dia inteiro de trabalho ou praticamente nada. Você pega o último backup completo, aplica os archives em sequência, e chega no ponto exato que você quer.
O RMAN sabe fazer isso automaticamente. Você informa até onde quer recuperar (por data, por SCN — System Change Number — ou por sequência de log) e ele aplica tudo.
Os archives compactados: o histórico que salva
Os archive logs em tempo real crescem sem parar. Com o banco em produção, podem ser gerados gigabytes de archives por dia. Manter tudo no servidor local come espaço rápido.
A solução prática que a gente vê nos clientes WSpeed: guardar os archives compactados como histórico, separados dos archives recentes. Eles ficam numa estrutura rotativa — por dia, por semana, por mês — e são transferidos pra nuvem imediatamente depois de compactados.
Esse histórico compactado é o que permite uma recuperação point-in-time mais distante no passado. Se você precisar reconstituir o banco como ele estava há três semanas, os archives compactados são o que torna isso possível — desde que estejam todos lá, em sequência, sem lacuna.
Uma lacuna na sequência de archives equivale a um buraco no tempo que não tem como preencher. Por isso a rotina de envio pra nuvem precisa ser contínua e monitorada.
Os datafiles completos: a base do disaster recovery
O backup físico completo — os datafiles do banco via RMAN — é o que permite subir o banco do zero em outro servidor. E aqui está um detalhe que pouca gente destaca:
Com os datafiles + archives, dá pra montar um DR em outro local — inclusive em outro sistema operacional. Temos clientes que fazem exatamente isso: o banco principal roda em Windows, e o ambiente de DR foi configurado em Linux. No dia que precisar, o banco sobe no segundo site a partir dos arquivos que estão na nuvem.
Isso é disaster recovery de verdade — não um documento no gaveta dizendo “se tudo falhar, ligue pra fulano”, mas um ambiente que pode ser ativado porque os arquivos estão lá, testados, prontos.
O RMAN é a ferramenta padrão de fato pra gerenciar esses backups físicos. Ele verifica a integridade dos blocos durante o backup, cataloga os arquivos gerados, e sabe exatamente o que precisa ser aplicado pra uma recuperação completa. Em ambientes Oracle enterprise, é comum ter também um catálogo de recuperação separado — um banco Oracle auxiliar que armazena o histórico do RMAN.
Como ficam as quatro camadas na prática?
Não existe uma receita única — o DBA define a frequência e a estrutura de acordo com o ambiente. Mas um modelo que funciona bem, e que vemos nos clientes WSpeed com Oracle:
- Dump lógico (expdp): diário ou semanal, dependendo do ritmo de mudanças no schema.
- Archive logs em tempo real: contínuos enquanto o banco está em modo ARCHIVELOG — sem parar.
- Archives compactados: compactação e envio pra nuvem em janelas programadas (por exemplo, a cada hora ou a cada turno).
- Datafiles completos: backup físico via RMAN em janela de manutenção — semanal ou quinzenal, dependendo do tamanho do banco.
O resultado: você tem um backup lógico pra portabilidade, um histórico contínuo de transações, e uma base física pra subir o banco do zero quando precisar.
E se o backup Oracle ficar só no servidor?
Você já imaginou o servidor Oracle com HD queimado — e o dump, os archives e os datafiles estavam todos na mesma máquina?
Acontece. E quando acontece, não tem RMAN que salve, porque os arquivos de backup sumiram junto com o banco.
Todo esse trabalho de montar as quatro camadas só faz sentido se os arquivos saírem do servidor e forem pra um lugar separado — de preferência pra nuvem, com criptografia, com versionamento e com garantia em contrato de que você vai recuperar.
É exatamente aí que o backup em nuvem para empresas da WSpeed entra. O RMAN gera os arquivos de backup na pasta local — o WSpeed monitora essa pasta e envia tudo automaticamente pro Backblaze B2 (nosso armazenamento primário, especializado em backup e mais econômico) com criptografia AES-256 e retenção configurável. Se precisar, o arquivo também vai pro AWS S3. Sem ação manual, sem depender de alguém lembrar de copiar o HD externo.
Aqui a gente não infla o discurso pra parecer maior. Diz Backblaze B2 + AWS S3 porque é o que a gente usa de verdade — e cada um serve a um propósito claro.
Se você cuida da TI de clientes com Oracle e quer estruturar isso como serviço gerenciado, vale conhecer as soluções para empresas de TI que a WSpeed oferece. A gente trabalha direto com MSPs e suportes locais.
Agora me conta nos comentários: qual é o seu modelo atual de backup Oracle? Você já precisou fazer um DR de verdade — subir o banco em outro servidor — e funcionou? Fico curioso pra saber.
Abraço e até o próximo artigo ou vídeo.
Perguntas frequentes
Qual o melhor backup de Oracle?
Não existe um único melhor — depende do que você quer recuperar e em quanto tempo. A combinação mais robusta é: dump lógico (expdp) + archive logs em tempo real + datafiles completos gerenciados pelo RMAN. Juntos, esses quatro tipos cobrem desde a portabilidade de objetos até o disaster recovery completo em outro servidor.
O que é archive log no Oracle?
Archive log (ou archived redo log) é o registro de cada transação feita no banco depois do último backup completo. Com o banco em modo ARCHIVELOG, o Oracle guarda esse histórico continuamente. Resultado: se o banco parar agora, você consegue recuperar até o último instante antes da falha, sem perder uma transação sequer.
Dá pra migrar Oracle de Windows pra Linux pelo backup?
Sim, e é exatamente pra isso que servem os datafiles completos (backup físico via RMAN). Você restaura os arquivos do banco em um servidor Linux, aplica os archives e sobe o banco no novo ambiente. É uma das grandes vantagens desse tipo de backup: portabilidade entre sistemas operacionais.
Oracle perde dados entre backups?
Não — se estiver configurado em modo ARCHIVELOG e capturando os archives em tempo real. Os archive logs registram cada transação ocorrida entre um backup completo e o próximo. Sem eles, você perderia tudo que foi feito desde o último backup completo. Com eles, o ponto de recuperação é o último archive gerado antes da falha.
O que é RMAN no Oracle?
RMAN (Recovery Manager) é a ferramenta oficial da Oracle para backup e recuperação. Ele gerencia backups físicos dos datafiles, control files e archive logs, verifica integridade dos blocos, e integra com o catálogo de recuperação. Na prática, é o padrão de fato para quem leva backup Oracle a sério.
Precisa de DBA para fazer backup Oracle?
Na prática, sim — especialmente para configurar a estratégia inicial e garantir que o restore funcione. Oracle tem muitas variáveis: modo ARCHIVELOG, estrutura de tablespaces, configuração do RMAN. O que a WSpeed faz é pegar os arquivos que o RMAN gera e levá-los para a nuvem com criptografia e versionamento, automaticamente.
