Files

B2BCall Bootstrap 80e72881b2 feat: Fase 9/10 — métricas, scripts operacionais, callback/wrap-up e aceite final

Fase 9 (segurança e produção):
- GET /api/metrics: endpoint Prometheus com métricas reais (chamadas,
  agentes, filas, CPS por campanha), protegido por permissão
- scripts/backup.sh, restore.sh, healthcheck.sh, install.sh, update.sh —
  testados contra o ambiente real (backup.sh e healthcheck.sh rodados de
  verdade; install.sh/update.sh validados por inspeção, ambiente atual já
  provisionado)
- POST /api/agent-console/dispose: aplica disposição de chamada de verdade
  (lacuna deixada aberta desde a Fase 6), com ações CALLBACK (agenda
  retorno) e DO_NOT_CALL (suprime automaticamente)
- apps/dialer-worker/src/callback-sweep.ts: reativa leads com callback
  vencido; GET /api/callbacks para consulta
- apps/dialer-worker/src/wrap-up-sweep.ts: transição automática
  WRAP_UP -> AVAILABLE + despausa real na fila do Asterisk. Exigiu corrigir
  main.ts para conectar ao AMI mesmo em DIALER_SIMULATION=true
  (DIALER_SIMULATION deve impedir só originação de chamada, não ações
  administrativas de fila)
- nftables revisado (sem alterações necessárias)
- Documentação completa: INSTALL, OPERATIONS, BACKUP_RESTORE, SECURITY,
  DATABASE, API, ASTERISK, OPENSIPS (não implementado, motivo
  documentado), TROUBLESHOOTING
- README.md e CHANGELOG.md reescritos

Fase 10 (testes e aceite):
- Quality gate completo executado: build/typecheck (7 workspaces), lint,
  46 testes unitários, docker compose config/ps, healthcheck — tudo verde
- Aceite de segurança (seção 92): 13 itens verificados ao vivo contra o
  sistema real, não só por inspeção de código
- Aceite Asterisk (seção 93): os 5 comandos executados e documentados,
  comunicação API->AMI->Asterisk validada
- docs/RELATORIO_FINAL.md: relatório final no formato da seção 96

Todos os fixtures de teste desta fase foram removidos/desativados ao
final. Credenciais de acesso entregues separadamente em CREDENCIAIS.txt
(fora do git, nunca versionado).

2026-08-27 19:16:14 -03:00

2.8 KiB

Raw Blame History

B2BCall — Backup e Restore

O que é backupado

Um único pg_dump -Fc do banco b2bcall cobre tudo que precisa persistir:

Schema public — usuários, campanhas, leads, chamadas, configurações.
Schema asterisk — troncos/ramais provisionados (ps_endpoints, ps_auths, ps_aors, ...), CDR, CEL.

Os arquivos gerados em Telefonia → Dialplan e Call Center → Filas (/etc/asterisk-generated/*.conf dentro do container do Asterisk) não precisam de backup separado: são derivados de DialplanVersion/Queue (Postgres) e recriados automaticamente na próxima publicação, caso o volume Docker seja perdido (agente.md seção 97: "Asterisk não é banco de negócio").

O .env é backupado à parte (contém segredos que não estão no banco: JWT_*_SECRET, SECRETS_MASTER_KEY, credenciais AMI/ARI/SMTP).

Backup

sudo ./scripts/backup.sh

Gera em backups/ (fora do git, chmod 600):

postgres-<timestamp>.dump — dump pg_dump -Fc (formato custom, comprime e permite restore seletivo).
env-<timestamp>.bak — cópia do .env.
FIRST_LOGIN-<timestamp>.txt — se o arquivo ainda existir no servidor.

Retenção: remove automaticamente backups com mais de 30 dias (BACKUP_RETENTION_DAYS no ambiente para ajustar).

Agendamento recomendado (cron, fora do escopo deste repositório):

0 3 * * * cd /opt/b2bcall && ./scripts/backup.sh >> /var/log/b2bcall-backup.log 2>&1

Copie os backups para fora do servidor (outro host, storage externo) — um backup que só existe no mesmo disco do banco não protege contra falha de disco.

Restore

sudo ./scripts/restore.sh backups/postgres-20260101-030000.dump

Isso é destrutivo: substitui completamente o conteúdo atual do banco (pg_restore --clean --if-exists). O script pede confirmação explícita (digitar "restaurar") antes de agir, para acidentes de digitação.

O que o script faz:

Para os serviços de aplicação (api, asterisk-events, dialer-worker, frontend, nginx) — mantém postgres/redis/asterisk no ar.
Executa pg_restore contra o Postgres em funcionamento.
Reinicia os serviços de aplicação.

Após restaurar, rode scripts/healthcheck.sh e confira:

pjsip show endpoints no Asterisk reflete os troncos/ramais do backup.
Login funciona com um usuário que existia no momento do backup.

Restaurando o `.env`

Se o .env também precisar ser restaurado (ex.: perda total do servidor):

cp backups/env-<timestamp>.bak .env
chmod 600 .env

Isso restaura os segredos (JWT, master key de criptografia) — sem eles, as senhas de tronco/ramal cifradas no banco restaurado não podem ser decifradas. Por isso o .env deve ser guardado com a mesma prioridade que o dump do banco, não apenas como acessório.

2.8 KiB Raw Blame History