Backup e recuperação#

Este artigo descreve o conteúdo do backup e a preparação da recuperação do Docker com MariaDB ou PostgreSQL integrados. Antes das operações, o administrador precisa do procedimento para a versão e o banco utilizados. Para banco externo, o procedimento é acordado com seu administrador.

Conteúdo do backup#

Um backup completo da instalação inclui:

Os bancos principal e de arquivo do MariaDB, ou todo o banco PostgreSQL, incluindo os esquemas principal e de arquivo.
.env, docker-compose.yml e o docker-compose.override.yml utilizado.
backend/config, configuração do nginx e certificados.
Dados do Armazenamento no volume orchestrator-storage.
Dados do Vault, .vault_keys.json e vault/config/vault.hcl, quando o Vault é utilizado.

O dump do banco não contém os demais arquivos e volumes listados. É necessário preservar o ORCHESTRATOR_ENCRYPTION_KEY original e as chaves de desbloqueio do Vault; sem eles, os segredos restaurados podem ficar inacessíveis.

Criação e verificação#

Antes de parar os serviços, é necessário obter com o suporte técnico da Sherpa o procedimento de backup e restauração do banco para a versão e o mecanismo utilizados. Ele contém comandos para o banco. Separadamente, é necessário preparar e testar a cópia e restauração de configurações, certificados, Armazenamento e Vault conforme os volumes montados. O backup da instalação não está completo até verificar a recuperação de todos os componentes.

É necessário acordar uma janela de manutenção, verificar o espaço livre e selecionar um diretório protegido.
Devem ser interrompidos o backend, WebSocket, nginx e as integrações externas que gravam dados. O contêiner do banco selecionado permanece em execução.
É necessário criar um dump do banco selecionado conforme o procedimento recebido e uma cópia dos arquivos e volumes consistente no tempo. Os comandos devem ser adaptados antes da execução se os nomes dos bancos não forem padrão.
É necessário verificar o código de saída de cada comando, se o dump não está vazio e as somas de verificação. Uma cópia deve ser transferida para fora do servidor mantendo as restrições de acesso.
A recuperação é testada em uma instância de banco e volumes separados. A existência do arquivo de dump não comprova, por si só, que o backup seja utilizável.

Se não houver atualização ou restauração planejada, após a cópia é necessário reiniciar os serviços conforme o procedimento recebido para o banco selecionado.

Os processos de escrita não devem ser reiniciados entre o dump e a atualização. Caso contrário, o backup deixará de corresponder ao estado anterior à atualização.

Recuperação e reversão#

A recuperação substitui os dados atuais do banco de destino. Antes dela, são necessários um dump verificado e um backup novo e separado do estado atual. O aplicativo e os processos externos de escrita devem permanecer parados.

Para reverter, primeiro são restauradas as imagens e configurações compatíveis com o dump. Em seguida, inicia-se apenas o banco e segue-se a seção do mecanismo correspondente no procedimento recebido para a versão e o banco utilizados. A recuperação do PostgreSQL utiliza um banco recriado para não manter objetos de migrações mais recentes. A recuperação de teste do MariaDB é realizada somente em uma instância e um volume isolados.

Os volumes de produção não devem ser excluídos com docker compose down -v. O backend é iniciado somente após restaurar o banco, os arquivos e os segredos, pois pode aplicar migrações na inicialização.

Após a inicialização, é necessário verificar login, acesso a Processos e Armazenamento, Licenças, leitura de segredos e um cenário de teste seguro. O backup original é mantido até a confirmação do resultado.