Backup e recuperação de dados

Esta documentação busca descrever comportamentos do sistema, em especial do Engine, que devem ser considerados nas estratégias de backup e de recuperação de dados que envolvam o sistema. A definição dessas políticas em si é um assunto mais complexo que foge do escopo deste documento, pois envolve diversos outros componentes além do sistema, como equipamentos, infraestrutura de rede e segurança de dados quem devem ser analisados sobre o contexto geral da organização, sendo o sistema apenas um componente importante na infraestrutura de TI da empresa.

Na arquitetura do sistema, os dados que necessitam de persistência e proteção são majoritariamente gravados no banco de dados relacional, sendo atualmente suportados os bancos de dados PostgreSQL, Oracle e Microsoft SQL Server. Opcionalmente, arquivos podem ser gravados em serviços de armazenamento de objetos em nuvem, como o Google Cloud Storage, o Amazon S3 e o Azure Blob Storage. Os dados gravados pelo servidores Engines são por natureza temporários ou de cache, como logs, arquivos com dados transacionais não efetivados, dados de sessões transientes de usuários e réplica dos dados cadastrais da base de dados.

Enquanto a perda dos dados de um Engine pode ser absorvida sem maiores impactos, a perda da base de dados relacional é catastrófica e pode ser definitiva. Por esse motivo, o banco de dados relacional é o componente mais importante a ser observado nas políticas de backup e de recuperação de dados. Os serviços de armazenamento de objetos, caso utilizados, também contêm dados que não podem ser perdidos, no entanto, os serviços providos pelas principais nuvens públicas já oferecem um nível elevado de segurança e proteção contra perda de dados se devidamente configurados.

A seguir serão descritos os principais aspectos que devem ser observados nas estratégias de backup e recuperação de dados para cada um desses componentes.

Banco de dados

Os dados armazenados no sistema de banco de dados relacional representam o ativo mais crítico da aplicação. As melhores práticas de backup e recuperação de dados dependem do banco de dados utilizado e devem ser definidas por um DBA especializado. Também podem ser utilizados serviços gerenciados de banco de dados nas nuvens públicas, como o Google Cloud SQL, Amazon RDS ou Azure Database, que possuem soluções de alta disponibilidade com as melhores práticas de segurança incorporadas.

Pontos importantes a serem observados no processo de recuperação de dados:

1. Caso ocorra perda de dados na restauração de um backup, é obrigatório que seja executado o comando de descarte de dados do cache local e de chaves dos Engines. Caso contrário, o sistema poderá criar chaves duplicadas ou realizar operações sem consistência de integridade, pois o cache local dos Engines terá mais informações que a base de dados relacional.
2. Em soluções de alta disponibilidade, o failover automático deve ser configurado apenas se houver garantia que todos os commits na base de dados principal estão efetivados no ambiente de standby. É recomendado que o failover seja manual caso a replicação de commits seja assíncrona ou haja o risco de perda de dados da última transação, pois, caso haja perda de dados, é necessária a execução do comando de descarte de dados do cache local e de chaves logo após o failover para o ambiente de standby.

O descarte dos caches locais e de chaves do Engine pode ser solicitado pelo processo “Administração do sistema > Cache local > Descarte dos caches de dados e chaves”. Ele deve ser executado com todos os Engines desativados, exceto o servidor onde o comando for executado, que deve estar indisponível para os demais usuários. Após a execução do comando, todos os Engines devem ser reiniciados para que o comando seja efetivado. Opcionalmente, o comando pode também ser executado pelo DBA diretamente no banco de dados com todos os Engines desativados por meio do comando SQL abaixo:

-- PostgreSQL
UPDATE ULTCHAVE SET VERSAOBD = ROUND(EXTRACT(EPOCH FROM NOW()) * 1000)
-- Oracle
UPDATE ULTCHAVE SET VERSAOBD = (CAST(SYSTIMESTAMP AT TIME ZONE 'UTC' AS DATE) - DATE '1970-01-01') * 86400000
-- Microsoft SQL Server
UPDATE ULTCHAVE SET VERSAOBD = DATEDIFF_BIG(MILLISECOND,'1970-01-01 00:00:00.000', SYSUTCDATETIME())

Os caches locais são recriados sem os índices das tabelas, pois eles são criados sob demanda de acordo com a utilização dos usuários. Em bases de dados com alto volume de registros cadastrais, esse processo de indexação pode ser demorado e prejudicar a experiência dos usuários logo após a reconstrução do cache local. Para evitar esse impacto, a indexação pode ser antecipada utilizando o botão “Restaurar índices” do processo “Administração do sistema > Cache local > Tabelas e índices” nos Engines servidores que necessitem dessa antecipação.

Observação: o descarte do cache local pode ser acelerado nos Engines servidores removendo manualmente o subdiretório “dbCache” no diretório de instalação do Engine.

Engines

A maioria dos dados armazenados pelo Engine localmente podem ser reconstruídos a partir da base de dados relacional, como a réplica dos dados cadastrais armazenadas no cache local e o cache de chaves. Também há dados transientes e de diagnóstico, como logs e dados temporários de sessões de usuários, que para a maioria dos cenários não são relevantes a ponto de justificar sua proteção por uma política de backup. No entanto, as configurações dos Engines, em especial as dos servidores de aplicação, devem ter uma atenção, pois elas serão necessárias caso os Engines precisem ser reinstalados.

As configurações do Engine são gravadas nos arquivos “conf/iengine.conf” e “config/manage.icf”. Caso haja portas HTTPS configuradas, também são requeridos os arquivos com o certificado digital e a chave privada associada ao certificado. Essas informações podem ser protegidas por uma solução de backup. No entanto, por serem raramente modificadas, apenas a sua documentação e cópia dos arquivos relacionados aos certificados digitais podem ser suficientes para uma eventual necessidade de reinstalação.

Para evitar interrupção do sistema devido a uma falha de um servidor, é recomendado que os servidores de aplicação sejam configurados com balanceamento de carga. Mais detalhes sobre essa configuração podem ser obtidos no manual Alta disponibilidade.

Pontos importantes a serem observados no processo de recuperação de dados:

1. O diretório de instalação do Engine possui arquivos que são únicos para cada instalação do Engine e jamais podem ser copiados. Caso seja necessário acelerar a inicialização de um Engine servidor aproveitando o cache local de outro, deve ser copiado apenas o diretório dbCache e nunca o diretório completo de instalação do Engine.
2. Caso seja utilizada um solução de snapshot de disco para agilizar a restauração de um servidor, devem ser removidos o cache local e de chaves dos Engines logo após a restauração, antes da reinicialização dos serviços. Restaurar um snapshot antigo do disco sem o correto descarte dos caches irá retroceder o cache de chaves e provocar a geração de chaves duplicadas no sistema, uma falha extremamente grave de integridade.
3. Uso de snapshots de disco como estratégia de agilizar a duplicação de servidores requer que todos os diretórios exceto o subdiretório “dbCache” e os arquivos “conf/iengine.conf” e “config/manage.icf” sejam excluídos na instância criada a partir do snapshot.

Importante: outros módulos e sistemas construídos sobre a plataforma base do sistema podem ter outras necessidades específicas que não estão relacionadas nesta documentação.

Serviços de armazenamento de objetos

Caso o sistema esteja configurado para utilizar serviços de armazenamento de objetos em nuvem como o Google Cloud SQL, Amazon RDS ou Azure Database, deve-se observar que esses serviços contêm dados críticos para o funcionamento do sistema e eles devem ter uma atenção equivalente ao banco de dados relacional. Esses serviços podem ser configurados com diferentes níveis de proteção e redundância que devem ser ao menos equivalentes aos empregados na base de dados relacional.

Pontos importantes a serem observados no processo de recuperação de dados:

1. A perda de dados no serviço de armazenamento de objetos pode gerar uma inconsistência na tabela “iLob” do banco de dados relacional, pois os registros dessa tabela irão referenciar arquivos que não existem no serviço de armazenamento de objetos. Deve ser avaliado o impacto dessa perda considerando o uso dos arquivos perdidos e se há possibilidade de recuperá-los de outras fontes.