Por que eu devo ler este artigo:Este artigo objetiva mostrar como implementar uma boa estratégia de backup e de restore para seu banco de dados. Para isso, será abordado o funcionamento do Continous Archiving, também conhecido como backup incremental. Vamos saber em que situações este tipo de backup é útil, quais os passos para habilitá-lo, como realizar o restore e o recover da base de dados. Se você tem um banco de dados PostgreSQL e considera que os dados contidos nele são importantes, então é recomendável que você entenda como criar uma boa estratégia de backup e que também tenha em um bom procedimento para realizar a recuperação desses dados. Caso contrário, poderá ter problemas no dia em que precisar realizar um restore no ambiente de produção.

Uma das atividades mais importantes de um administrador de banco de dados é, sem dúvidas, planejar e implementar uma boa estratégia de backup para se prevenir de possíveis desastres. Nem sempre é possível prever tudo, mas para se prevenir de possíveis falhas é importante considerar desastres que podem ocorrer com seu banco de dados: terremoto, furacão, incêndios, falha de hardware, falha de software e até falha humana. Para se proteger de todas elas existe um custo e a implementação vai depender do nível de investimento que será feito e dos riscos que a empresa está disposta a correr. Nem sempre o administrador de banco de dados consegue se proteger da maioria dos desastres, pois não depende só dele. Nesses casos é interessante deixar os responsáveis pelos sistemas cientes da situação.

Para criação da melhor estratégia de backup para o ambiente, temos que considerar quais as necessidades dos clientes que usam o serviço de banco de dados. A seguir abordaremos quais pontos devem ser levados em consideração.

Uma sigla bastante importante para definição da nossa estratégia é o ANS (Acordo de Nível de Serviço) ou em inglês SLA (Service Level Agreement). Proveniente do ITIL, biblioteca com melhores práticas de infraestrutura de TI, o ANS é o acordo entre o provedor de serviços de TI e o cliente para um determinado tipo de serviço. No nosso caso, o serviço em questão é o de banco de dados. E o acordo será o tempo de indisponibilidade desse serviço durante uma parada não programada. Quanto tempo é aceitável para o cliente ficar sem esse serviço no caso de um desastre?

No caso de um desastre, dependendo da estrutura da empresa, é muito provável que será necessário um restore usando o backup realizado. E claro, de nada vale um backup se o restore não funciona. Por isso, um outro conceito que precisamos entender aqui é o RTO (Recovery Time Objective), que é o tempo gasto do desastre até a completa recuperação dos dados. De uma maneira direta, nossa estratégia de backup precisa ter um RTO que atenda o ANS relacionado a desastres.

Outro acordo que deve ser definido é o período aceitável de perda de informações em caso de falha. Existe um período aceitável em que, no caso de um restore, os dados podem ser perdidos ou não é aceitável de maneira alguma perder dados?

A criação dos backups históricos também terá um peso grande na definição da estra ...

Quer ler esse conteúdo completo? Tenha acesso completo