Estratégias de backup e restore no PostgreSQL
Este artigo apresenta como implementar uma boa estratégia de backup e restore. Será discutido o funcionamento do Continous Archiving, também conhecido como backup incremental.
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?"
[...] continue lendo...Artigos relacionados
-
Artigo
-
Artigo
-
Artigo
-
Artigo
-
Artigo