RMAN - Abordando a política de retenção (RECOVERY WINDOW) em backups incrementais

Olá,

Nos artigos de Outubro/2010 e Julho/2012 eu abordo um pouco sobre estratégias de backup utilizando o RMAN (Recovery Manager). Vale a pena recapitular que no Oracle, quando fazemos backups utilizando o RMAN, além da opção do backup FULL, temos também a opção de utilizarmos os backups incrementais. No RMAN, o termo "backup incremental" é utilizado para fazer referência a dois tipos: incremental diferencial e incremental cumulativo. O backup incremental inicial é conhecido como backup Nivel-0 (nível zero) e cada backup incremental realizado após o inicial é chamado de backup Nivel-1 (nível um). Os backups incrementais Nivel-1 podem ser cumulativos ou diferenciais.

Usar backups incrementais cumulativos significa que cada backup incremental se tornará progressivamente maior e mais demorado até que outro Nivel-0 seja executado, mas durante uma operação de recuperação, somente dois conjuntos de backups (Backup sets) serão necessários (O Nivel-0 e o último Nivel-1).

Os backups incrementais diferenciais somente registram as alterações referentes ao o último backup. Portanto, cada conjunto deles poderá ser menor ou maior do que o anterior, sem nenhuma sobreposição em seus blocos de dados. Entretanto, uma operação de recuperação poderá ser mais demorada pelo fato de terem mais conjuntos de backups para serem lidos em vez de apenas dois como no cumulativo (por exemplo: O Nivel-0, e vários Nivel-1). No mais, em relação aos backups incrementais, já li sobre DBAs levantando dúvidas no que se refere à política de retenção baseada no tempo (RECOVERY WINDOW) quando são utilizados backups incrementais como parte da política de backup. Muitas dessas dúvidas se referem sobre quando um conjunto de backups (backup sets) ficará obsoleto dentro de uma política de backup incremental.

Bom, para começar vale a pena salientar o que seria uma política de retenção no RMAN. Basicamente temos 3 opções:

Redundancy Backup Retention Policy

Com essa política o RMAN mantém X números de backups do banco de dados (número de cópias a serem retidas) para ficarem disponíveis para recuperação. Segue abaixo uma ilustração supondo que é realizada uma operação de backup 1 vez por dia. 

RMAN> configure retention policy to redundancy 2
 

Como demonstrado na figura acima, é possível perceber que o backup realizado na segunda-feira ficou obsoleto após o backup de quarta-feira ter sido realizado, e assim por diante. O que importa neste caso é o número de cópias que precisam ficar retidas. Como demonstrado na imagem, ao realizar o terceiro backup na quarta-feira, o primeiro backup que foi realizado na segunda-feira ficou obsoleto.

Recovery Window Backup Retention Policy

Essa política especifica que o RMAN deve reter todos os backups (baseado no tempo) durante um determinado X número de dias antes de torná-los obsoletos. A questão que devemos fazer ao optar por essa política é perguntar por quanto tempo queremos manter os backups para que seja possível uma recuperação em qualquer período em um tempo no passado (em dias) dentro da janela de retenção. Segue uma ilustração supondo que é realizada uma operação de backup 1 vez por dia.

RMAN> configure retention policy to recovery window of 1 day

Como demonstrado na figura acima, é possível perceber que o backup realizado na segunda-feira ficou obsoleto após o backup de quarta-feira ter sido realizado, e assim por diante. Isso significa que é possível recuperar o banco de dados em qualquer ponto no tempo dentro da janela de retenção de 1 dia.

NONE (os backups nunca ficam obsoletos)

Essa política especifica que o RMAN deve reter todos os backups sem nunca torná-los obsoletos.

RMAN> configure retention policy to none

Como demonstrado na figura acima, todos os backups realizados estarão disponíveis e não ficarão obsoletos.

Em relação ao backups incrementais, um backup de NIVEL-1 é inútil sem a existência de um backup de NIVEL-0. Portanto, se aos domingos são realizados backups de NIVEL-0 e nos demais dias (segunda-feira até sábado) são realizados backups de NIVEL-1, então mesmo que a minha política de retenção baseada em tempo (RECOVERY WINDOW) estiver configurado para 2 dias, na prática na primeira semana a retenção será de 9 dias, pois o backup de NIVEL-0 não poderá ficar obsoleto, já que o mesmo é necessário para realização de recover dos backups de NIVEL-1. Neste caso, um backup de NIVEL-0 só ficará obsoleto após a geração de um novo backup NIVEL-0 realizado na semana seguinte, conforme demonstrado na ilustração abaixo.

Na figura acima, o backup de NIVEL-0 realizado no dia 1 e todos os backups NIVEL-1 realizados até o dia 7 ficarão obsoletos somente a após a geração do backup NIVEL-1 no dia 10.

Segue abaixo uma evidência na qual são realizados backups NIVEL-0 (aos domingos) e NIVEL-1 (resto da semana) em um banco de dados que possui a política de retenção de 2 dias (RECOVERY WINDOW OF 2 DAYS). Conforme exemplificado na imagem acima, podemos verificar abaixo que nenhum backup se tornou obsoleto dentro dos 9 dias de realização dos backups.

RMAN> show all;

RMAN configuration parameters for database with db_unique_name BD01 are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 2 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 1;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default

RMAN> list backup summary;

List of Backups
===============
Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---------------
9337652 B  0  A DISK        01/10/2015      1       1       YES        LEVEL-0_SEMANAL
9337696 B  A  A DISK        01/10/2015      1       1       YES        ARCHIVES_DIARIO
9340964 B  1  A DISK        02/10/2015      1       1       YES        LEVEL-1_DIARIO
9341007 B  A  A DISK        02/10/2015      1       1       YES        ARCHIVES_DIARIO
9343776 B  1  A DISK        03/10/2015      1       1       YES        LEVEL-1_DIARIO
9346935 B  A  A DISK        03/10/2015      1       1       YES        ARCHIVES_DIARIO
9346949 B  1  A DISK        04/10/2015      1       1       YES        LEVEL-1_DIARIO
9350199 B  A  A DISK        04/10/2015      1       1       YES        ARCHIVES_DIARIO
9350213 B  1  A DISK        05/10/2015      1       1       YES        LEVEL-1_DIARIO
9353555 B  A  A DISK        05/10/2015      1       1       YES        ARCHIVES_DIARIO
9353569 B  1  A DISK        06/10/2015      1       1       YES        LEVEL-1_DIARIO
9353612 B  A  A DISK        06/10/2015      1       1       YES        ARCHIVES_DIARIO
9356729 B  1  A DISK        07/10/2015      1       1       YES        LEVEL-1_DIARIO
9356772 B  A  A DISK        07/10/2015      1       1       YES        ARCHIVES_DIARIO
9360532 B  0  A DISK        08/10/2015      1       1       YES        LEVEL-0_SEMANAL
9360576 B  A  A DISK        08/10/2015      1       1       YES        ARCHIVES_DIARIO
9363815 B  1  A DISK        09/10/2015      1       1       YES        LEVEL-1_DIARIO
9363858 B  A  A DISK        09/10/2015      1       1       YES        ARCHIVES_DIARIO


RMAN> report obsolete;

RMAN retention policy will be applied to the command
RMAN retention policy is set to recovery window of 2 days
no obsolete backups found