É importante que na definição de estratégias de recuperação de desastres, não consideremos apenas a parte técnica. O mundo ideal seria coletarmos com o negócio/cliente qual é o RTO e RPO toleráveis, e partindo desta informação, analisar sua aderência técnica e se é necessário investimentos (a nível de infraestrutura, licencimento, recursos humanos, etc).
Uma falha em nosso ambiente pode ocorrer de diversas maneiras, como falha de processo, de rede, instância, mídia, corrupção física ou lógica, erros de usuário, etc. O RTO, que é o acrônimo de Recovery Time Objective, define por quanto tempo um sistema estará disponível e operacional novamente. Sabemos que esta etapa contém algumas atividades, como identificação do problema, plano de recuperação, e o tempo da recuperação em si. Portanto, isso deve estar definido no tempo acordado com o negócio.
Já o RPO, acrônimo para Recovery Point Objective, define a tolerância máxima de dados que pode ser perdido (e a unidade de medida geralmente usada é o tempo, como por exemplo, 2 horas de perda).
A partir destas definições, poderemos analisar tecnicamente qual ferramenta/feature poderia ser usada, como o RMAN, Data Guard, Flash Back, etc. Então o mais importante a se destacar é que a estratégia de recuperação de um ambiente é feita de forma compartilhada, e todos devem estar cientes dos SLAs acordados (e seus respectivos investimentos para torná-los factíveis).
Fontes: https://docs.oracle.com/database/121/VLDBG/GUID-76435B39-EF7E-418B-9C33-0C43B088178A.htm#VLDBG1567 e https://docs.oracle.com/database/121/VLDBG/GUID-AD7289B0-0D01-4382-AA5D-CBE458ADDF91.htm#VLDBG1568
Portuguese
English
Spanish