Uma das "práticas" que já vi sendo executada por DBA's em minha organização é tratar uma exportação completa de banco de dados utilizando ferramentas como exp/ expdpcomo backup.
Seria esta uma boa prática? Quais seriam as vantagens de usar RMAN sobre esta abordagem?
A vantagem do RMAN é o PITR - recuperação pontual. Você pode fazer um backup RMAN dos DBFs e um backup RMAN dos redo logs arquivados e recuperar seu banco de dados em qualquer ponto no tempo até o backup do redo log arquivado mais recente. A desvantagem dessa abordagem é que ela é muito granulada - você só pode recuperar no nível do tablespace.
A vantagem de exp/expdp é que você tem uma cópia consistente do banco de dados que pode ser importada para um banco de dados em branco recém-criado. No entanto, você não pode avançá-lo - neste ponto, é um banco de dados completamente separado e independente, sem relação lógica com o original. Mas é fácil recuperar apenas uma única tabela ou até mesmo algumas linhas de uma exportação.
Uma boa abordagem seria backups regulares completos e incrementais de arquivos de dados RMAN, backups contínuos de redo logs arquivados (por exemplo, assim que um backup archivelog for concluído, inicie o próximo imediatamente para que você esteja "transmitindo" os logs para fita) e, em seguida, eduque seus usuários no uso de exp/imp para que possam realizar seus próprios "backups" (no caso de querer uma cópia real dos dados) e flashback (para que possam fazer suas próprias recuperações no caso de DML dar errado).
Lembre-se - um backup destina-se ao DBA para se recuperar de uma falha catastrófica do hardware. Não é para o benefício dos usuários finais (ou você gastará todo o seu tempo restaurando um sistema de teste e copiando algumas linhas de volta ao original!).
Exp/Expdp como solução de backup é como dizer que a loja de autopeças é seu automóvel de backup. Tecnicamente, isso fará com que você volte a funcionar, mas não causará nada além de dor e sofrimento.
Exp ou Expdp pode ser usado como um backup secundário para backups frios do sistema de arquivos ou backups quentes ou frios rman (outro software de cliente de backup Oracle geralmente executa apenas os comandos RMAN).
A metodologia típica seria a seguinte:
E se você realmente quiser ser prudente, transporte periodicamente os redo logs arquivados do servidor (a cada hora funciona) ou defina um local remoto para um segundo destino de log de arquivo.
-- RMAN *novo --
Minha sessão RMAN típica:
"Backup como backupset compactado...": Você também pode fazer uma imagem, que é uma cópia byte a byte dos arquivos de dados. Isso seria bom como aquele backup semanal.
"...banco de dados...": bastante óbvio
"...plus archivelogs...": nos dá recuperação pontual (e clonagem pontual [comando duplicado no rman])
"...delete input" : exclui os archivelogs dos quais foi feito backup. Você também pode definir isso para excluir aqueles que foram copiados pelo menos duas vezes, etc.
"excluir obsoleto": quando você tiver configurado sua política de retenção rman (a minha é de 5 dias), isso excluirá os backups que estão fora dessa janela. Isso não significa que só podemos nos recuperar 5 dias atrás. Você ainda deve ter seus backups em fita/fora do servidor diariamente da área de recuperação flash. Significa apenas que on-line você terá 5 dias de recuperação e, depois disso, precisará restaurar os itens da área de recuperação flash do backup em fita / fora do servidor e, em seguida, registrá-los no rman para usá-los.
Aqui está um log real de uma sessão, ligeiramente modificado para caminhos, etc:
As vantagens do RMAN são as seguintes: