Pular para o conteúdo principal

Restauro

Antes de qualquer restauro
  1. Salvaguardar o estado atual (mesmo danificado): pode ser preciso voltar a ele.
  2. Avisar os utilizadores: a aplicação fica indisponível durante a operação.
  3. Restaurar primeiro na pré-produção sempre que possível, para validar o ficheiro.

Base de dados a partir de um dump​

cd ~/pch-sig
F=docker-compose.prod.yml                  # ou docker-compose.preprod.yml
PG=$(docker ps --filter name=pch_postgres --format '{{.Names}}' | grep -v exporter | head -1)

# 1. Parar o backend (nenhuma escrita)
docker compose -f $F stop backend

# 2. Recriar uma base vazia
docker exec "$PG" sh -c 'dropdb -U "$POSTGRES_USER" --if-exists "$POSTGRES_DB" && createdb -U "$POSTGRES_USER" "$POSTGRES_DB"'
docker exec "$PG" sh -c 'psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -c "CREATE EXTENSION IF NOT EXISTS postgis; CREATE EXTENSION IF NOT EXISTS unaccent;"'

# 3. Carregar o dump
gunzip -c ~/backups/pch_sig_AAAAMMDD_HHMMSS.sql.gz | docker exec -i "$PG" sh -c 'psql -U "$POSTGRES_USER" -d "$POSTGRES_DB"'

# 4. Reiniciar o backend (executa as migrações em falta e repõe os direitos)
docker compose -f $F up -d --no-deps backend
docker exec pch_backend curl -s http://127.0.0.1:8000/api/health

Após o restauro:

  • Reindexar a base documental do assistente: docker exec -u www-data pch_backend php bin/console app:assistant:indexer --sans-vecteurs.
  • Em produção, avisar a equipa do servidor de recuperação: a replicação deve ser reinicializada a partir da nova base.

Base de produção a partir do servidor de recuperação​

Em caso de perda do servidor de produção, a base mais recente é a réplica de axone-dr (ou o seu último instantâneo restic). Esta operação é conduzida com a equipa que administra esse servidor: promoção da réplica ou exportação de um dump, depois restauro no novo servidor como acima.

Ficheiros carregados​

docker run --rm -v pch-sig_backend_uploads:/data -v ~/backups:/in alpine \
  sh -c 'rm -rf /data/* && tar -xzf /in/uploads_AAAAMMDD.tar.gz -C /data'
docker compose -f $F up -d --no-deps backend      # repõe os direitos de www-data

GitLab (pré-produção)​

O restauro exige os dois ficheiros do mesmo dia: o arquivo da aplicação e a configuração (gitlab-secrets.json). Sem este último, os tokens, a autenticação de dois fatores e as variáveis de CI perdem-se.

cd ~/gitlab
tar -xzf ~/backups/gitlab/gitlab-config_AAAAMMDD_HHMMSS.tar.gz -C /tmp       # depois recopiar para o volume /etc/gitlab
docker cp ~/backups/gitlab/<carimbo>_gitlab_backup.tar gitlab:/var/opt/gitlab/backups/
docker exec gitlab gitlab-ctl stop puma && docker exec gitlab gitlab-ctl stop sidekiq
docker exec -it gitlab gitlab-backup restore BACKUP=<carimbo>
docker compose -f docker-compose.yml restart

Procedimento completo e precauções em docs/GITLAB_SERVEUR.md do repositório.

Testar as salvaguardas​

Pelo menos uma vez por trimestre: restaurar o último dump de produção na pré-produção e verificar que é possível iniciar sessão e que os ecrãs principais aparecem. Uma salvaguarda nunca restaurada não é uma salvaguarda.