{"id":14,"date":"2026-06-03T09:00:00","date_gmt":"2026-06-03T12:00:00","guid":{"rendered":"https:\/\/www.wspeed.com.br\/blog\/backup-oracle\/"},"modified":"2026-06-20T16:02:33","modified_gmt":"2026-06-20T19:02:33","slug":"backup-oracle","status":"publish","type":"post","link":"https:\/\/www.wspeed.com.br\/blog\/backup-oracle\/","title":{"rendered":"Backup Oracle: Dump, Archive Log e DR Que N\u00e3o Perde Dado"},"content":{"rendered":"
Resposta r\u00e1pida<\/span><\/p>\n

Backup Oracle de verdade combina quatro camadas: dump l\u00f3gico (expdp), archive logs em tempo real, hist\u00f3rico de archives compactado e datafiles completos. Com isso voc\u00ea recupera at\u00e9 o \u00faltimo segundo antes do problema \u2014 e ainda sobe o banco em outro servidor, inclusive em outro sistema operacional.<\/p>\n<\/div>\n

Mas Maur\u00edcio, o DBA disse que o Oracle j\u00e1 tem backup configurado \u2014 pode confiar?<\/strong><\/p>\n

Depende muito do que esse backup cobre. Oracle \u00e9 um mundo \u00e0 parte. Cada empresa tem um DBA, e cada DBA faz do seu jeito. J\u00e1 vi casos em que o backup existia, o script rodava todo dia, mas na hora de subir em outro servidor\u2026 ningu\u00e9m sabia o que fazer. O arquivo estava l\u00e1 \u2014 a estrat\u00e9gia, n\u00e3o.<\/p>\n

Vou te mostrar como a maioria dos clientes da WSpeed que usam backup Oracle<\/strong> organiza isso na pr\u00e1tica: quatro tipos de backup que, juntos, cobrem desde a recupera\u00e7\u00e3o de um objeto isolado at\u00e9 um disaster recovery completo em outro servidor.<\/p>\n

Se voc\u00ea ainda est\u00e1 construindo o conceito de por que copiar o arquivo do banco em uso n\u00e3o funciona, recomendo dar uma lida no backup de banco de dados<\/a> antes de continuar. E se o conceito de backup em si ainda est\u00e1 nebuloso, come\u00e7a pelo o que \u00e9 backup<\/a>.<\/p>\n

Por que backup Oracle \u00e9 diferente dos outros SGBDs?<\/h2>\n

A maioria dos bancos de dados tem uma estrat\u00e9gia de backup razoavelmente padronizada. No Firebird voc\u00ea usa o gbak. No SQL Server, o BACKUP DATABASE<\/code>. No PostgreSQL, o pg_dump. Em cada um desses, o caminho \u00e9 mais ou menos conhecido.<\/p>\n

No Oracle, a hist\u00f3ria \u00e9 outra. A arquitetura \u00e9 mais complexa \u2014 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\u00e9gia funcionar. A ferramenta oficial \u00e9 o RMAN (Recovery Manager)<\/strong>, mas a forma de usar varia muito de empresa pra empresa.<\/p>\n

Sendo honesto: em Oracle, normalmente tem um DBA e cada um faz do seu jeito.<\/strong> N\u00e3o \u00e9 cr\u00edtica \u2014 \u00e9 a realidade do ecossistema. O que importa \u00e9 que, qualquer que seja o jeito, a estrat\u00e9gia precisa cobrir os quatro tipos que vou explicar agora.<\/p>\n

Quais s\u00e3o os 4 tipos de backup que clientes WSpeed usam no Oracle?<\/h2>\n

Na pr\u00e1tica, 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.<\/p>\n\n\n\n\n\n\n\n\n
Tipo<\/th>\nO que \u00e9<\/th>\nPra que serve<\/th>\nRecupera at\u00e9 quando?<\/th>\n<\/tr>\n<\/thead>\n
Dump l\u00f3gico (expdp\/exp)<\/strong><\/td>\nExporta\u00e7\u00e3o l\u00f3gica de objetos e dados do banco<\/td>\nPortabilidade, migra\u00e7\u00e3o, recupera\u00e7\u00e3o de objetos isolados<\/td>\nPonto fixo da exporta\u00e7\u00e3o (n\u00e3o \u00e9 cont\u00ednuo)<\/td>\n<\/tr>\n
Archive em tempo real<\/strong><\/td>\nArchived redo logs gerados continuamente com o banco em uso<\/td>\nGarantir que nenhuma transa\u00e7\u00e3o seja perdida entre backups completos<\/td>\nAt\u00e9 o \u00faltimo instante antes da falha<\/td>\n<\/tr>\n
Archives compactados (hist\u00f3rico)<\/strong><\/td>\nLogs de archive acumulados e compactados ao longo do tempo<\/td>\nGuardar o hist\u00f3rico de altera\u00e7\u00f5es para recupera\u00e7\u00e3o point-in-time<\/td>\nQualquer ponto no passado coberto pelo hist\u00f3rico<\/td>\n<\/tr>\n
Online \/ datafiles completos<\/strong><\/td>\nC\u00f3pia f\u00edsica dos datafiles completos do banco (via RMAN)<\/td>\nSubir o banco inteiro do zero \u2014 inclusive em outro servidor ou SO<\/td>\nPonto do \u00faltimo backup f\u00edsico + archives aplicados<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

O dump l\u00f3gico (expdp): pra que serve de verdade?<\/h2>\n

O dump l\u00f3gico \u00e9 gerado pelo utilit\u00e1rio expdp<\/strong> (Data Pump Export) \u2014 ou pelo exp<\/strong> nas vers\u00f5es mais antigas do Oracle. Ele exporta objetos do banco: tabelas, views, procedures, sequences, usu\u00e1rios.<\/p>\n

O ponto forte do dump \u00e9 a portabilidade<\/strong>. Se voc\u00ea precisa mover dados de um banco pra outro, restaurar uma tabela espec\u00edfica que foi apagada por engano, ou migrar pra uma vers\u00e3o diferente do Oracle, o dump l\u00f3gico \u00e9 o caminho.<\/p>\n

O ponto de aten\u00e7\u00e3o: o dump l\u00f3gico n\u00e3o \u00e9 cont\u00ednuo. Ele captura o estado do banco no momento da exporta\u00e7\u00e3o. Se voc\u00ea faz o dump \u00e0s 22h e o banco falha \u00e0s 15h do dia seguinte, voc\u00ea perdeu tudo que aconteceu nessas 17 horas. \u00c9 por isso que o dump sozinho n\u00e3o \u00e9 suficiente \u2014 ele precisa trabalhar junto com os archives.<\/p>\n

O que \u00e9 archive log e por que ele \u00e9 o pulo do gato?<\/h2>\n

Voc\u00ea j\u00e1 se perguntou: e se o backup completo rodar \u00e0 meia-noite, mas o banco falhar \u00e0s 14h \u2014 o que acontece com as 14 horas de trabalho do dia?<\/strong><\/p>\n

Sem archive log, voc\u00ea perde. Com archive log, voc\u00ea n\u00e3o perde nada.<\/p>\n

Quando o Oracle est\u00e1 em modo ARCHIVELOG<\/strong>, ele guarda continuamente o registro de cada transa\u00e7\u00e3o ocorrida no banco \u2014 os chamados archived redo logs<\/em>. Pense neles como um di\u00e1rio em tempo real: “\u00e0s 09h14, o usu\u00e1rio alterou esse registro; \u00e0s 09h15, esse outro registro foi inserido\u2026”. Cada log fica armazenado em disco assim que \u00e9 gerado.<\/p>\n

Com os archive logs, voc\u00ea consegue recuperar o banco at\u00e9 o \u00faltimo instante antes da falha<\/strong> \u2014 isso se chama recupera\u00e7\u00e3o point-in-time, e \u00e9 a diferen\u00e7a entre perder um dia inteiro de trabalho ou praticamente nada. Voc\u00ea pega o \u00faltimo backup completo, aplica os archives em sequ\u00eancia, e chega no ponto exato que voc\u00ea quer.<\/p>\n

O RMAN sabe fazer isso automaticamente. Voc\u00ea informa at\u00e9 onde quer recuperar (por data, por SCN \u2014 System Change Number \u2014 ou por sequ\u00eancia de log) e ele aplica tudo.<\/p>\n

Os archives compactados: o hist\u00f3rico que salva<\/h2>\n

Os archive logs em tempo real crescem sem parar. Com o banco em produ\u00e7\u00e3o, podem ser gerados gigabytes de archives por dia. Manter tudo no servidor local come espa\u00e7o r\u00e1pido.<\/p>\n

A solu\u00e7\u00e3o pr\u00e1tica que a gente v\u00ea nos clientes WSpeed: guardar os archives compactados como hist\u00f3rico, separados dos archives recentes. Eles ficam numa estrutura rotativa \u2014 por dia, por semana, por m\u00eas \u2014 e s\u00e3o transferidos pra nuvem imediatamente depois de compactados.<\/p>\n

Esse hist\u00f3rico compactado \u00e9 o que permite uma recupera\u00e7\u00e3o point-in-time mais distante no passado. Se voc\u00ea precisar reconstituir o banco como ele estava h\u00e1 tr\u00eas semanas, os archives compactados s\u00e3o o que torna isso poss\u00edvel \u2014 desde que estejam todos l\u00e1, em sequ\u00eancia, sem lacuna.<\/p>\n

Uma lacuna na sequ\u00eancia de archives equivale a um buraco no tempo que n\u00e3o tem como preencher.<\/strong> Por isso a rotina de envio pra nuvem precisa ser cont\u00ednua e monitorada.<\/p>\n

Os datafiles completos: a base do disaster recovery<\/h2>\n

O backup f\u00edsico completo \u2014 os datafiles do banco via RMAN \u2014 \u00e9 o que permite subir o banco do zero em outro servidor. E aqui est\u00e1 um detalhe que pouca gente destaca:<\/p>\n

Com os datafiles + archives, d\u00e1 pra montar um DR em outro local \u2014 inclusive em outro sistema operacional.<\/strong> 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\u00e3o na nuvem.<\/p>\n

Isso \u00e9 disaster recovery de verdade \u2014 n\u00e3o um documento no gaveta dizendo “se tudo falhar, ligue pra fulano”, mas um ambiente que pode ser ativado porque os arquivos est\u00e3o l\u00e1, testados, prontos.<\/p>\n

O RMAN \u00e9 a ferramenta padr\u00e3o de fato pra gerenciar esses backups f\u00edsicos. Ele verifica a integridade dos blocos durante o backup, cataloga os arquivos gerados, e sabe exatamente o que precisa ser aplicado pra uma recupera\u00e7\u00e3o completa. Em ambientes Oracle enterprise, \u00e9 comum ter tamb\u00e9m um cat\u00e1logo de recupera\u00e7\u00e3o separado \u2014 um banco Oracle auxiliar que armazena o hist\u00f3rico do RMAN.<\/p>\n

Como ficam as quatro camadas na pr\u00e1tica?<\/h2>\n

N\u00e3o existe uma receita \u00fanica \u2014 o DBA define a frequ\u00eancia e a estrutura de acordo com o ambiente. Mas um modelo que funciona bem, e que vemos nos clientes WSpeed com Oracle:<\/p>\n