VitePress

Appearance

Rollback ​

Procedimentos para reverter o sistema para uma versão anterior em caso de problema.

Rollback de código (sem migration destrutiva) ​

Se o deploy causou um problema e as imagens antigas ainda existem:

bash
# 1. Ver imagens disponíveis
docker images | grep crm

# 2. Identificar a tag anterior (formato: local-YYYYMMDD-HHMMSS)
# Exemplo: crm-backend:local-20250520-093045

# 3. Atualizar o .env com as tags antigas
sed -i "s|^BACKEND_IMAGE=.*|BACKEND_IMAGE=crm-backend:local-20250520-093045|" /home/crm/app/.env
sed -i "s|^FRONTEND_IMAGE=.*|FRONTEND_IMAGE=crm-frontend:local-20250520-093045|" /home/crm/app/.env

# 4. Restart sem rebuild (usa as imagens antigas)
bash deploy.sh --restart

Rollback de migration de banco ​

Prisma não tem rollback automático. Opções:

Opção A — Migration de rollback manual ​

bash
# 1. Escrever migration inversa
# Ex: se a migration adicionou uma coluna, a migration de rollback remove
# backend/prisma/migrations/YYYYMMDDHHMMSS_rollback_campo/migration.sql
ALTER TABLE "Customer" DROP COLUMN IF EXISTS "novoCampo";

# 2. Aplicar o rollback
bash deploy.sh backend  # prisma migrate deploy aplica a nova migration

Opção B — Restaurar backup (dados perdidos!) ​

bash
# 1. Parar o backend (não o postgres)
docker stop crm-galdix-backend-1

# 2. Fazer dump do estado atual (para auditoria)
docker exec crm-galdix-postgres-1 \
  pg_dump -U $POSTGRES_USER $POSTGRES_DB \
  > /home/crm/backup_before_rollback_$(date +%Y%m%d_%H%M%S).sql

# 3. Restaurar backup anterior
docker exec -i crm-galdix-postgres-1 \
  psql -U $POSTGRES_USER $POSTGRES_DB \
  < /home/crm/backup_YYYYMMDD.sql

# 4. Fazer deploy da versão anterior do código
# (imagem mais antiga, antes da migration)

ATENÇÃO: Restaurar backup desfaz TODOS os dados desde o backup. Usar apenas em emergências.

Backup do banco ​

Não há backup automático configurado. Para fazer backup manual:

bash
# Dump completo
docker exec crm-galdix-postgres-1 \
  pg_dump -U $POSTGRES_USER -d $POSTGRES_DB \
  --format=custom \
  > /home/crm/backups/crm_$(date +%Y%m%d_%H%M%S).pgdump

# Restaurar
docker exec -i crm-galdix-postgres-1 \
  pg_restore -U $POSTGRES_USER -d $POSTGRES_DB \
  < /home/crm/backups/crm_20250523_120000.pgdump

Recomendação: Configurar backup diário automatizado (cron + dump + envio para storage externo).

Rollback de configuração ​

Se o problema foi numa variável de ambiente:

bash
# Ver variáveis atuais do container
docker inspect crm-galdix-backend-1 | grep -A 50 '"Env"'

# Editar .env.secrets e fazer restart
nano /home/crm/app/.env.secrets
bash deploy.sh --restart

Rollback do Traefik labels ​

Se as labels do Traefik foram alteradas erroneamente no docker-compose.labels.yml:

bash
git diff docker-compose.labels.yml  # ver o que mudou
git checkout docker-compose.labels.yml  # reverter
bash deploy.sh --restart

Histórico de imagens ​

O Docker mantém imagens antigas até docker image prune. Para ver o histórico:

bash
docker images --format "table {{.Repository}}\t{{.Tag}}\t{{.CreatedAt}}\t{{.Size}}" | grep crm

O deploy.sh executa docker image prune -f ao final — remove imagens dangling (sem tag). Imagens com tag (como crm-backend:local-20250520-093045) são mantidas até serem removidas manualmente ou até sobrescritas.