Ir para o conteúdo

Plano — Módulo de Monitoramento de Backups, Pastas e Bancos

Contexto salvo em 2026-07-15 (atualizado no mesmo dia). Decisões confirmadas pelo Moisés: coleta via agente instalado em cada servidor; verificação Iperius por logs + validação na nuvem via Graph API; bancos: SQL Server (msdb); prioridade imediata: diagnosticar backups falhando. Directory Monitor é Pro → log em banco habilitado; cópia para o share feita por tarefa agendada no .3.

Topologia (atualizada)

Servidor Papel Componentes
192.168.0.2 (IMPERAD) AD + diretórios + backup Iperius Backup (destino nuvem OneDrive direto pelo Iperius — cliente OneDrive foi DESATIVADO por problemas), Directory Monitor Pro, share \\192.168.0.2\backup2026\OneDrive
192.168.0.3 Banco de dados + arquivos SQL Server 2017 (PegasusImpercia + outros), pastas de trabalho e XMLs em E:\, backups .bak do SQL também em E:\

Fluxo de backup desejado

  1. Tarefa agendada no .3 (scripts/Copia-Backups-Para-Share.ps1): copia XMLs e .bak do E:\ para \\192.168.0.2\backup2026\OneDrive (robocopy /E /XO, nunca apaga).
  2. Iperius no .2: job envia backup2026\OneDrive para a nuvem (destino OneDrive nativo do Iperius — sem cliente de sync).
  3. Monitoramento: agente verifica logs do Iperius, JSON de resultado da cópia (C:\Scripts\logs\ultimo_resultado.json no .3) e msdb.

Directory Monitor → gráficos no Flet

  • Habilitar plugin Database do DirMonitor Pro apontando para banco DirMonitorLogs no SQL do .3 (scripts/dirmonitor_db_setup.sql cria banco + logins).
  • API Django lê com usuário read-only impercia_ro; novos endpoints em api/monitoring/.
  • Gráficos no Flet: arquivos mais acessados, top usuários, distribuição por hora, eventos por tipo. Substitui a exportação manual de XLS a cada 2 dias.

Situação atual do sistema (Impercia)

  • Flet (app/, :8080) — frontend com views: dashboard, dba, ad, maint, structure, ai_chat.
  • Django REST (api/analyzer/, :8001) — tools/views para SQL Server, AD, manutenção.
  • Impercia Agent (agent/impercia_agent.py, FastAPI :8767) — APScheduler com jobs health_check (15min), ad_security_check (60min), daily_report (08:00); alertas por e-mail (Brevo) e insights via Maritaca Sabiá.
  • Ambiente: domínio ciaimper.com.br, DC IMPERAD (192.168.0.2), SQL Server 2017 (PegasusImpercia, 192.168.0.3). Backups feitos por Iperius com destino OneDrive — suspeita de falhas silenciosas.

Fase 0 — Diagnóstico (AGORA)

Antes de codar, mapear o estado real:

  1. diagnostico/Diagnostico-Backups.ps1 — rodar no servidor do Iperius (leitura apenas): logs do Iperius (7 dias), idade/tamanho dos arquivos nos destinos, estado do OneDrive.
  2. diagnostico/diagnostico_backups_msdb.sql — rodar na instância SQL: último FULL/DIFF/LOG por banco, atrasos, destinos e tamanhos.
  3. Com o resultado, definir thresholds reais e quais jobs do Iperius corrigir.

Fase 1 — Agente coletor por servidor

Evoluir agent/ para um pacote instalável nos servidores (já existe instalar_agente.bat):

  • agent/collectors/iperius.py — parser dos logs do Iperius (mesma lógica do PS1, em Python); reporta por job: nome, última execução, status, mensagem de erro.
  • agent/collectors/folders.py — vigilância de pastas (substitui/complementa o Directory Monitor): existência, idade do arquivo mais recente, tamanho total, contagem; via watchdog para eventos em tempo real + varredura agendada.
  • agent/collectors/mssql_backup.py — consulta msdb (a query da Fase 0 parametrizada).
  • Envio: POST autenticado (Bearer, já existe padrão AGENT_KEY) para a API Django central.
  • Config por servidor em .env/YAML: quais coletores ativar, pastas, thresholds.

Fase 2 — Backend Django (central)

  • Novo app api/monitoring/ com models: Server, BackupJob, BackupExecution, WatchedFolder, FolderSnapshot, Alert (migrar de SQLite para PostgreSQL ao crescer).
  • Endpoints DRF: ingestão dos agentes (POST /api/monitoring/ingest/), consulta para o Flet (GET /api/monitoring/status/, /alerts/).
  • Regras de alerta no servidor central (não no agente): backup atrasado, job com erro, pasta sem arquivos novos, agente sem contato ("heartbeat perdido" > X min).
  • Reuso do pipeline de e-mail + Maritaca já existente no agente para os novos alertas.

Fase 3 — Validação OneDrive via Microsoft Graph

  • App registration no Entra ID (permissão Files.Read.All, client credentials).
  • Job no agente central: confirmar que os arquivos que o Iperius enviou existem no OneDrive na nuvem (nome, tamanho, lastModifiedDateTime).
  • Comparar tamanho local (share backup2026) × nuvem.
  • Obs.: cliente de sync OneDrive foi desativado nos servidores — validação é só via API.

Fase 4 — Frontend Flet

  • Nova view app/views/backups.py: grid de servidores × jobs com semáforo (OK / atrasado / erro / sem contato), timeline de execuções, detalhe do log de erro.
  • Card no dashboard existente com resumo (X jobs OK, Y falhando, Z atrasados).

⏸️ ONDE PARAMOS — retomar em 16/07/2026

Executado em 15/07 à noite (autorizado, com contas admin do .env):

  1. Jobs SQL criados no .3: SYNCRONNET - Sistema - Backup FULL (diario) (21:00) e SYNCRONNET - Ciaimperinventario - Backup FULL (diario) (21:30), padrão Ola Hallengren. 1ª execução falhou (pasta inexistente) → pastas criadas (E:\SQLBackups\Sistema\FULL e E:\SQLBackups\Ciaimperinventario\FULL) → jobs ficaram em RETRY automático. VERIFICAR amanhã: rodar diagnostico/check_result.py — deve mostrar SUCESSO e backups gravados. Se ainda em retry/falha, rodar diagnostico/check_error.py.
  2. Tarefa de cópia instalada no .3: Impercia\CopiaBackupsParaShare, diária 23:00, roda como administrator local (o .3 está em WORKGROUP, não no domínio! — por isso o script autentica no share via -ShareUser CIAIMPER\administrator). Script em C:\Scripts\Copia-Backups-Para-Share.ps1 no .3, logs em C:\Scripts\logs\. 1ª execução disparada 19:47 e estava EM ANDAMENTO ao parar (NFE_XML ok, SQLBackups copiando ~3 GB). VERIFICAR amanhã: \\192.168.0.3\c$\Scripts\logs\ultimo_resultado.json (ok=true esperado) e conteúdo de \\192.168.0.2\BACKUP2026\OneDrive\.
  3. Espaço livre confirmado: 426 GB no BACKUP2026 (.2), 141 GB no C:\ (.3).

Pendências (ordem sugerida para amanhã):

  1. Verificar itens 1 e 2 acima.
  2. Moisés (manual): atualizar Iperius 5.8.5 → versão atual e reconectar conta OneDrive (uploads falhando em loop — Job009 DP.VENDAS / Job015 DP.VENDASGERENCIAL).
  3. Incluir a pasta BACKUP2026\OneDrive novas subpastas (SQLBackups, BACKUPSQL, NFE_XMLs) nos jobs do Iperius para subirem à nuvem.
  4. Definir senhas e executar scripts/dirmonitor_db_setup.sql + configurar plugin Database do Directory Monitor Pro (.2 → SQL .3, banco DirMonitorLogs).
  5. Fase 1 do plano: coletores no agente (Iperius Exceptions.log, ultimo_resultado.json, msdb).
  6. Git: commitar scripts/, diagnostico/, docs/ (sugestão: feat: monitoramento de backups — jobs SQL, tarefa de cópia e diagnósticos).
  7. Segurança (importante): trocar senhas expostas no .env.example versionado.

Status (15/07/2026, noite)

  • Diagnóstico executado — ver docs/DIAGNOSTICO_BACKUPS_2026-07-15.md. Iperius 5.8.5 falhando uploads OneDrive em loop (Job009/Job015). Ciaimperinventario sem backup.
  • scripts/Copia-Backups-Para-Share.ps1 ajustado com caminhos reais (E:\SQLBackups, D:\SQLBackups LOG, E:\BACKUPSQL, 3 pastas NFE_XML ativas) → \\192.168.0.2\BACKUP2026\OneDrive.
  • scripts/sql_backup_jobs_novos.sql pronto (padrão Ola Hallengren em [PegasusImpercia].dbo, jobs SYNCRONNET - Sistema 21:00 e Ciaimperinventario 21:30). Aguardando aprovação para executar.
  • Pendentes do Moisés: atualizar Iperius + reconectar OneDrive; senhas para dirmonitor/impercia_ro.

Riscos / decisões pendentes

  • Credenciais no .env.example estão expostas no git — trocar senhas e limpar histórico.
  • db.sqlite3 central: ok para começar, planejar PostgreSQL na Fase 2.
  • Directory Monitor Pro: manter como fonte de eventos (log em banco); coletor próprio fica opcional.
  • Conta da tarefa agendada no .3 precisa de gravação em \\192.168.0.2\backup2026 (usar conta de serviço do domínio, não SYSTEM, se o share exigir autenticação).
  • Versionamento: uma branch por fase (feat/monitoring-fase1, etc.), commits pequenos.