Backup não é Data Pump: Como Estruturar uma Rotina RMAN de Verdade
Recentemente, precisei implementar uma rotina de backup em um ambiente onde o cliente utilizava apenas uma exportação via Data Pump, executada diariamente às 23h. Nem preciso dizer que essa abordagem é totalmente inadequada como estratégia de backup.
O mais impressionante é que, mesmo com a enorme quantidade de conteúdo técnico disponível hoje, ainda encontramos cenários com alto nível de desinformação e baixa maturidade em práticas essenciais dentro de ambientes corporativos.
2 pontos que eu gostaria de salientar :
1- Backup
2-Observabilidade
Esses dois pontos precisam caminhar juntos: não adianta ter uma rotina de backup se você não sabe, de fato, se ela está funcionando corretamente. Faz sentido, não é?
Com isso em mente, agora podemos avançar para a parte prática.
A Tal Rotina de data pump
#!/bin/bash
export ORACLE_PDB_SID=PDB_APP01
export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=/u01/app/oracle/product/19.0.0.0/dbhome_1 export ORACLE_HOSTNAME=DBSERVER01
export PATH=\(PATH:\)ORACLE_HOME/bin
#
cd /backup/datapump
/bin/mv /backup/datapump/*APP01*.gz /backup/datapump_old 2>/dev/null
DATA=$(date +%Y-%m-%d)
expdp system/SenhaFicticia123@PDB_APP01
schemas=APP,APP_AUDIT
directory=DP_DIR_APP01
flashback_time=systimestamp
dumpfile=EXPDP_APP01_${DATA}.dmp
logfile=EXPDP_APP01_${DATA}.log
/bin/gzip *APP01*
/bin/chmod 644 *.gz *.log
Até aqui, nada além do básico — uma rotina simples e funcional.
Optei por mantê-la como estava, pois, apesar de existirem diversas oportunidades de melhoria, ela cumpria seu papel. E, naquele momento, o foco da atividade não era evoluir essa rotina, mas atuar em pontos mais críticos do ambiente.
Rotina Backup Contrab
#rotina arc - a cada 30m
*/30 * * * * /backup/scripts_bkp/bkp_arc.sh > /backup/scripts_bkp/log_err_arc 2>&1
#inc - segunda a sabado as 21:15h
15 21 * * 1-6 /backup/scripts_bkp/bkp_inc.sh > /backup/scripts_bkp/log_err_inc 2>&1
#full - Domingo as 21h
0 21 * * 0 /backup/scripts_bkp/bkp_full.sh > /backup/scripts_bkp/log_err_full 2>&1
Com essa estratégia, conseguimos cobrir a base de dados com backups ao longo de uma semana.
Os parâmetros adotados foram definidos com base nas limitações de espaço do ambiente. Considerando a rotina de backup de archivelogs a cada 30 minutos, temos um RPO aproximado de 30 minutos — desde que todos os backups estejam íntegros e disponíveis para recuperação.
Os scripts utilizados estão disponibilizados abaixo, devidamente documentados, incluindo regras de notificação por e-mail tanto para sucesso quanto para falhas. É uma abordagem simples, mas que atende bem ao objetivo proposto.
O ambiente em questão utilizava Oracle Standard Edition e apresentava diversas limitações. Ainda assim, isso não justifica a ausência de uma estratégia de backup confiável e funcional — pelo contrário, torna essa necessidade ainda mais crítica.
Configurações Essenciais RMAN
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DISK;
Todas as rotinas documentas e com envio de e-mail diretamente nos scripts para facilitar a Observability quando uma rotina falhar ou finalizar com sucesso.
Script Backup Full
Script Backup Archive
https://github.com/francois-fiorino/Advanced-Scripts/blob/344dc099fa1c545ca3af29c45aafe5cb7db6b3f6/oracle/bkp-archive
Script Backup Incremental
Conclusão
É isso galera, nem sempre temos disponíveis as melhores condições no cliente, as melhores features ou recursos, mas o básico deve ser atendido, pelo menos é desta forma que eu penso.
Até a próxima ...
