Estrategia de backups — servidores de clientes, DBs, VMs

Contexto

Pendiente capturado por Sergio el 2026-05-08 como 3 ítems relacionados que en realidad son una sola disciplina: respaldo automático y verificable de los activos importantes que opera Electrosystems. Se documenta como un proyecto consolidado porque comparten decisiones (dónde guardar, retención, cifrado, monitoreo, restore drill).

Ojo — distinto de backup-system: ese es el pipeline de backups de configuraciones de dispositivos de red (Oxidized → nas:configs.git). Este proyecto es para los servidores Linux/VMs de la empresa y de clientes, y para sus bases de datos.

Tareas pendientes

Reescrito 2026-05-19 con lo aprendido en el inventario y los escaneos de 10.11.0.0/16 y 192.168.20.0/24. Lo que estaba antes (decisiones marco, alcance por servidor, etc.) se sintetiza ahora en “Decisiones marco” y en el inventario.

🔁 Retomar siguiente sesión — pegar este bloque

Sergio cerró el 2026-05-20 pidiendo explícitamente que al retomar le pegue este bloque para correrlo con !. Son los 17 hosts “Linux genéricos” del escaneo 58695 (probable FreePBX no-Sangoma o Asterisk standalone). El script scripts/probe-pbx-db.sh ya está validado 6/6 en Sangoma y tolera variantes (sale limpio aunque no encuentre creds — Discovery dice qué shape tienen).

! /home/sergio/agy/scripts/probe-pbx-db.sh 10.11.0.30 insajj
! /home/sergio/agy/scripts/probe-pbx-db.sh 10.11.0.74 gi-coprofusa
! /home/sergio/agy/scripts/probe-pbx-db.sh 10.11.0.98 axcel
! /home/sergio/agy/scripts/probe-pbx-db.sh 10.11.0.158 gicorpfinal2
! /home/sergio/agy/scripts/probe-pbx-db.sh 10.11.0.218 asterisk-cocef
! /home/sergio/agy/scripts/probe-pbx-db.sh 10.11.0.234 gasnaturalito
! /home/sergio/agy/scripts/probe-pbx-db.sh 10.11.1.190 capsonic-jrz
! /home/sergio/agy/scripts/probe-pbx-db.sh 10.11.3.110 adfsavpn2
! /home/sergio/agy/scripts/probe-pbx-db.sh 10.11.4.34 klyns
! /home/sergio/agy/scripts/probe-pbx-db.sh 10.11.4.42 itcj2
! /home/sergio/agy/scripts/probe-pbx-db.sh 10.11.4.54 capsonic-ep
! /home/sergio/agy/scripts/probe-pbx-db.sh 10.11.4.165 kufferath
! /home/sergio/agy/scripts/probe-pbx-db.sh 10.11.4.196 oasa-neptuno
! /home/sergio/agy/scripts/probe-pbx-db.sh 10.11.4.218 adfsaelpaso2
! /home/sergio/agy/scripts/probe-pbx-db.sh 10.11.4.230 randomtech
! /home/sergio/agy/scripts/probe-pbx-db.sh 10.11.5.184 novamexmexicali
! /home/sergio/agy/scripts/probe-pbx-db.sh 10.11.100.25 lineas_alestra

Después de procesar los resultados, seguir con el orden normal de la sección A.

A. Reanudar próxima sesión — orden recomendado

1. Decisión marco #2 — Herramienta (recomendación abierta: restic para FS, mysqldump|age / pg_dump|age para DBs).
2. Decisión marco #3 — Retención (recomendación: 30d + 12 sem + 24 mes; sin 7 años por costo/uso bajo).
3. Decisión marco #4 — Cifrado (recomendación: age, llave pública por origen, privada en NAS).
4. Decisión marco #5 — Monitoreo (recomendación: healthchecks.io self-hosted o SaaS, alerta tras 2 fallos consecutivos).
5. Decisión marco #6 — Restore drill (trimestral, documentado por tipo).
6. Decisión específica: ¿asteriskcdrdb (Call Detail Records) entra al backup? Es el 95% del volumen medido (~7 GB en los 4 hosts donde tenemos socket auth, más todos los pendientes de creds). Si solo se necesita la config del PBX y no histórico de llamadas, se puede excluir y ahorrar mucho espacio.

B. Completar inventario

7. Conseguir creds canónicas de Asterisk/FreePBX para enumerar DBs en ~14 hosts “Linux genéricos” con MariaDB activa pero “needs creds” — ✅ Sangoma 7 cerrado 6/6 (oasa-plutarco, minadolores2, miscelec-queretaro/leon/jrz, novamex-jrz, miscelec-chih ya estaba). Faltan (Linux no-Sangoma): oasa-neptuno, novamexmexicali, randomtech, klyns, kufferath, itcj2, axcel, capsonic-jrz/ep, gi-coprofusa, insajj, gicorpfinal2, arias-ep (parcial), adfsa-elpaso2, gasnaturalito, asterisk-cocef, lineas_alestra, adfsavpn2. Pista validada (6/6 Sangoma): las creds FreePBX viven en /etc/freepbx.conf ($amp_conf["AMPDBUSER"]/AMPDBPASS). Script scripts/probe-pbx-db.sh <ip> [label] automatiza con cascada de 4 fuentes + discovery, read-only por construcción.
8. Conseguir creds para los servidores ES en datacenter que necesitan MySQL/Postgres pwd: amadeus, netbox, otrs (.21), clientes (.60).
9. Investigar UISP (uisp 192.168.20.22) — Ubuntu 20.04, Postgres probablemente dockerizado (no detectado por systemd). Hay que entrar al container o leer el compose para conocer la DB.
10. Verificar el pg_dump nocturno de laptop-ia mencionado en INVENTORY (no apareció en probe).
11. Investigar docs — alias responde, hostname docs, pero sin Postgres ni MySQL visible. Wiki.js puede estar en SQLite o roto. Asunto que pertenece a docs-platform.md, no aquí.
12. Re-establecer auth en hosts con llave rotada: reverse-proxy (192.168.20.14), monitoreo (192.168.20.17).
13. Resolver host key mismatch: 10.11.1.114 (adfsa-voip), 10.11.2.195 (sin identificar).
14. Investigar IPs sin identificar en 192.168.20.x: .13, .16, .24, .57, .254 (gateway), bloque .103-.106 (probable workstations).
15. Investigar caídos: viaticos (192.168.20.19), indelek-chihuahua (10.11.1.206).

C. Resolver duplicidades nominativas

16. orion — alias config va a 192.168.20.2 (CentOS 6 EOL). Existe otro orion.electrosystemsnet.com en 10.11.100.41 (Linux moderno). ¿Es el reemplazo en curso? Coordinar con orion-decommission.
17. apolo/apolo2 — alias va a IP pública 64.150.190.34; apolo2.electrosystemsnet.com está en 10.11.0.1. Validar cuál es activo.
18. neptuno/neptuno2 — alias va a IP pública 69.64.69.199; neptuno2.electrosystemsnet.com está en 10.11.0.54. Idem.
19. val-soft reporta hostname paginas-web — clarificar si el alias está mal nombrado o si el server tiene rol mixto.

D. Capturar pendientes derivados en otros proyectos

20. backup-system: validar que oxidized cubre los 354 equipos de red detectados en 10.11.30-37.0/24 (CPEs con SSH puerto 22).
21. orion-decommission (o nuevo proyecto): agregar a la deuda EOL → otrs (192.168.20.21, CentOS 6) y clientes.electrosystemsnet.com (192.168.20.60, CentOS 6) tienen el mismo riesgo que orion.
22. docs-platform: estado real del Wiki.js (sin DB visible).

E. Para cuando ya esté completo el inventario — implementación

23. Decidir alcance por servidor (filesystem completo / solo /etc+/home+app data / imagen de disco). Probable default: para PBX → FS completo + dump DB; para servidores genéricos → /etc + paths de aplicación + dump DB.
24. Piloto en 1-2 hosts con socket auth ya validado (sugerencia: adfsa-voip por ser el más conocido, + vitalpbx por su DB grande de prueba).
25. Roll-out al resto tras validar el piloto.
26. Restore drill del piloto antes de declarar el sistema activo.

F. Fuera de scope — capturado para claridad

• ❌ Proyectos type: personal (medicinas, aprende-ingles, hub-portability) — Sergio los maneja aparte.
• ❌ Servidores web de clientes en internet (holbox prod 164.x, deportescampeon 206.x, grecocell 24.x, jmeza shared hosting) — los clientes los manejan aparte.
• ❌ laptop-ia excepto la DB electroia.
• ❌ 354 hits en 10.11.30-37.x — equipos de red, territorio de backup-system.
• ❌ 192.168.20.210 CloudKeyCastillo — equipo de red.
• ❌ es-nas (.26) — es el destino, no candidato.

Notas técnicas

Inventario de DBs (2026-05-19)

Probe SSH read-only desde laptop. 9 hosts candidatos probados, 3 más requieren VPN/auth para alcanzar.

† laptop-ia ya tiene mencionado en INVENTORY pg_dump nocturno 03:05 + rsync a es-nas:/volume1/BackupsProyectosIA/ — verificar que sigue corriendo, no apareció en este probe (probablemente porque corre como cron de otro user no enumerado).

No alcanzados en este probe:

• uisp (UNMS Postgres) — timeout, requiere VPN wireguard. IN scope.
• monitoreo — timeout, requiere VPN wireguard. IN scope.
• nagios — permission denied, llave no autorizada o user distinto. IN scope.

Hallazgos colaterales (no son del scope de backups pero anotar):

1. docs sin DB visible — el proyecto asume Wiki.js Postgres en docs. El host responde, hostname es docs, pero no hay MySQL ni Postgres ni :5432 escuchando. Wiki.js puede estar usando SQLite o estar caído. Investigar fuera de este proyecto (afecta a docs-platform).
2. MySQL expuesto en 0.0.0.0 en amadeus y deportescampeon — riesgo de seguridad. Bind a 127.0.0.1 salvo justificación. Capturar como pendientes en sus proyectos respectivos (no aquí).
3. jmeza corre en hosting compartido (CentOS 7 EOL + MariaDB 5.5 EOL). Para backup, lo realista es mysqldump remoto sobre TCP+TLS con creds (no hay acceso a system) o usar herramientas del panel del hosting. Revisar joyerias-meza.md.
4. Ningún host tiene backup automático corriendo hoy. /var/backups está vacío de DB dumps en todos. El pg_dump de laptop-ia mencionado en INVENTORY debe verificarse (no apareció en este probe).

Escaneo de la red 10.11.0.0/16 (2026-05-19)

TCP probe a puertos 22 y 58695 (estándar Electrosystems) desde laptop, paralelismo 400, 5 min 8 seg.

Resultado bruto: 413 IPs vivas con SSH — 379 en 22, 34 en 58695.

Interpretación por subred:

Tesis: los 354 hits en 10.11.30-37.0/24 solo en puerto 22 son equipos de red de clientes (probablemente CPEs Ubiquiti). NO son candidatos a backup full de FS/DB — su backup de configuración es trabajo de backup-system vía Oxidized. Anotado para validar coverage cruzada.

34 servidores ES en puerto 58695 (inventario detallado):

⚠️ NOTA orion duplicidad: el alias orion en ~/.ssh/config apunta a 192.168.20.2 (CentOS 6 EOL — orion-decommission). El probe encuentra otro orion.electrosystemsnet.com en 10.11.100.41. Posible que sea el reemplazo en progreso o un VHost intermedio. Investigar antes de incluir.

⚠️ Otras duplicidades nominativas:

• apolo2 (10.11.0.1) vs alias apolo (64.150.190.34, IP pública)
• neptuno2 (10.11.0.54) vs alias neptuno (69.64.69.199, IP pública)
• adfsavpn2 (10.11.3.110) = misma IP que alias adfsa-vpn — OK
• capsonic-ep (10.11.4.54) = misma IP que alias capsonic-elpaso — OK
• Patrón “2” en hostnames sugiere migración v1→v2 en curso. Validar con Sergio si las “2” son las activas.

Servidores 192.168.20.x (LAN principal Electrosystems) NO escaneados aún: poseidon, reverse-proxy, monitoreo, viaticos, otrs, uisp, vital, val-soft, netbox, oxidized, docs, amadeus, wireguard, es-nas. Cubierto en escaneo 192.168.20.0/24 (ver sección abajo).

Escaneo de la red 192.168.20.0/24 (2026-05-19)

TCP probe ejecutado desde la VM wireguard (que vive en esa red). 29 hits — 17 en 22, 12 en 58695.

Hipótesis sobre el doble-stack: muchos hostnames aparecen tanto en 10.11.x como en 192.168.20.x. La 10.11.x es probablemente la IP del túnel WireGuard que cada equipo establece con el concentrador wireguard, y la 192.168.20.x es la IP LAN real en datacenter Electrosystems. Implicación: los hosts SOLO en 10.11.x (miscelec-, oasa-, klyns, capsonic-*, asterisk-cocef, etc.) están físicamente en sitio cliente; los que también aparecen en 192.168.20.x viven en el datacenter de ES.

Tabla de 192.168.20.0/24 (29 hits):

⚠️ Tres CentOS 6 EOL en datacenter ES (no solo orion): orion (.2), otrs (.21), clientes (.60). Mismo nivel de riesgo de seguridad y soporte. Capturar como pendiente en sus proyectos correspondientes (otrs no tiene proyecto aún — quizá entra en migrations).

Aliases con auth-fail (llave probablemente rotada en host):

• reverse-proxy (192.168.20.14)
• monitoreo (192.168.20.17)

Hay que arreglarlos antes de incluir en backup.

Sin alias y sin auth (investigar antes de incluir):

• .13, .16 (puerto 22)
• .24, .57, .254 (puerto 58695)
• .103, .104, .105, .106 (puerto 22 — bloque contiguo, probable workstations)

Caídos: viaticos (192.168.20.19). Investigar si fue decom.

Equipos de red 10.11.30-37 (354 hosts puerto 22): fuera de scope de este proyecto. Capturar como pendiente en backup-system: verificar que oxidized los está respaldando.

Caídos / no responden: 10.11.1.206 (alias indelek-chihuahua) no responde ni a ping — investigar.

Datos a respaldar — estimación (post-recorte de scope)

Solo IN scope (DBs medidas hasta ahora):

• miscelec-chih asteriskcdrdb 4.8 GB ⭐
• miscelec-jrz asteriskcdrdb 4.8 GB ⭐ (mismo tamaño que chih — pendiente confirmar si hermanos/replica)
• minadolores2 asteriskcdrdb 1.4 GB + asterisk 38 MB
• arias-ep asteriskcdrdb 1.1 GB
• vitalpbx asterisk 1.1 GB + extras
• oasa-plutarco asteriskcdrdb 858.9 MB + asterisk 25.7 MB
• lineas-americanas asteriskcdrdb 628 MB
• novamex-jrz asteriskcdrdb 289 MB + asterisk 32.8 MB
• adfsa-voip (asterisk-adfsa-new) 90 MB
• miscelec-queretaro asterisk 24 MB (asteriskcdrdb ~0)
• miscelec-leon asterisk 25 MB (asteriskcdrdb ~0)
• electroia 9 MB
• ~14 hosts “Linux genéricos” del bloque 58695 con DB pendiente de creds (clase Asterisk standalone o FreePBX no-Sangoma)
• amadeus, netbox, docs, uisp, monitoreo, nagios, otros servidores 192.168.20.x — pendientes

Subtotal medido al 2026-05-20: ~15 GB (95% es asteriskcdrdb). Si asteriskcdrdb queda OUT del backup, el subtotal cae a ~265 MB. Esta es la razón concreta por la que la decisión sobre CDR es la palanca principal de volumen.

Pregunta clave: ¿asteriskcdrdb (Call Detail Records) entra al backup o no? Es la mayoría del volumen y es histórico de llamadas. Si el cliente no lo necesita, se puede excluir y ahorrar mucho espacio.

Lo que YA existe relacionado

• backup-system (proyecto separado) — pipeline de configuraciones de red (Oxidized → nas:configs.git). NO cubre filesystems ni DBs ni VMs.
• En electrosystems/INVENTORY.md se mencionan algunos backups ad-hoc:
  • pg_dump nocturno (cron 03:05) + rsync a es-nas:/volume1/BackupsProyectosIA/ — para Projects Hub en laptop-ia.
  • 30-git-autopush.sh — snapshot del markdown del Projects Hub.
  • electrorepo en orion (2.8 TB) tiene rol histórico de “repositorio de archivos” — verificar si ya se usa para backups o si es candidato.

Decisiones marco

Por qué consolidar en un solo proyecto

Servidores, DBs y VMs comparten:

• Mismo destino (NAS o cloud).
• Misma decisión de cifrado/llaves.
• Mismo monitoreo / alerta / restore drill.
• Mismo riesgo de “lo configuramos y nadie nunca lo verifica”.

Tener proyectos separados para cada uno multiplicaría el trabajo de planeación sin agregar claridad. Si el alcance crece, se pueden separar después.

Bitácora

2026-05-08

• Pidió Sergio: capturar 3 pendientes — backups automáticos de servers de clientes, DBs importantes, VMs.
• Hice: consolidé en un solo proyecto. Para cada uno dejé el plan de decisiones marco antes de tocar nada.
• Falta: todo. Es captura — implementación arrancará cuando Sergio lo priorice. Recomendación de prioridad: DBs (1) → servers de clientes (2) → VMs (3), porque la pérdida de DB es más dolorosa de recuperar que la de un sistema operativo.

2026-05-19

• Pidió Sergio: arrancar con el proyecto. Decisión marco #1 (destino) cerrada: solo NAS por ahora, sin off-site.
• Hice (Paso A — inventario DBs): corrí probe SSH read-only en 9 hosts candidatos. Inventario completo en sección “Notas técnicas → Inventario de DBs (2026-05-19)”. Cero hosts con backup corriendo.
• Hallazgos colaterales (capturados fuera de scope): docs sin DB visible (Wiki.js?), MySQL expuesto en 0.0.0.0 en amadeus y deportescampeon, jmeza en CentOS 7 + MariaDB 5.5 EOL.
• Hice (Paso C — escaneo 192.168.20.0/24): TCP probe paralelo desde la VM wireguard (que vive en esa red). 29 hits. Identifiqué hostnames de 22 hosts, 7 con auth fail. Detalle en sección “Escaneo de la red 192.168.20.0/24 (2026-05-19)”.
• Hipótesis confirmada con duplicidades: las IPs 10.11.x son túneles WireGuard, las 192.168.20.x son IPs LAN reales. Hosts en ambos lados = datacenter ES; hosts solo en 10.11.x = sitio cliente.
• Hallazgos importantes:
  • 3 CentOS 6 EOL en datacenter ES (orion .2, otrs .21, clientes .60).
  • 2 hosts con llave id_rsa_es rotada que requieren re-auth: reverse-proxy (.14), monitoreo (.17).
  • viaticos (.19) caído — investigar.
  • clientes.electrosystemsnet.com (.60) — nuevo descubrimiento, no estaba en config.
  • CloudKeyCastillo (.210) — UniFi CloudKey, equipo de red (no servidor).
  • Bloque IPs .103-.106 sin auth — probable workstations.
• Hice (Paso B — escaneo 10.11.0.0/16): TCP probe paralelo (puertos 22 + 58695) en los 65536 IPs. 5 min 8 seg. 413 IPs vivas. Identifiqué 34 servidores ES en puerto 58695, corrí inventario en 31, descubrí 4 con DB asterisk medible (~7.6 GB combinados) + 6 con MariaDB pendiente de creds + 21 sin DB visible para investigar. Detalle en “Escaneo de la red 10.11.0.0/16 (2026-05-19)”.
• Hallazgo importante: 354 hosts solo en puerto 22 en 10.11.30-37.0/24 son equipos de red (CPEs) — territorio de backup-system, no de este proyecto. Anotado para validar coverage cruzada.
• Decisiones cerradas: Scope (#0) y Destino (#1). Decisiones #2-#6 abiertas.
• Falta inmediato:
  • Conseguir creds para enumerar DBs en ~20 hosts con mariadb activa pero “needs creds” (oasa-plutarco, minadolores2, los 4 miscelec, novamex-jrz, etc.).
  • Reachear uisp, monitoreo, nagios (necesitan VPN/re-auth).
  • Escanear LAN principal Electrosystems (192.168.20.0/24) — poseidon, reverse-proxy, monitoreo, viaticos, otrs, vital, val-soft, oxidized.
  • Resolver duplicidades nominativas (orion/apolo/neptuno vs sus “2”; investigar cuál es el activo).
  • Resolver host key mismatch en 10.11.1.114 y 10.11.2.195.
  • Investigar host caído 10.11.1.206 (alias indelek-chihuahua).
  • Decidir si asteriskcdrdb entra al backup (es el 95% del volumen medido).
  • Decisiones marco #2-#6 pendientes para arrancar implementación.
• Pendientes derivados (a capturar en otros proyectos, no aquí):
  • docs-platform: investigar estado real del Wiki.js (sin DB visible).
  • backup-system: verificar que oxidized tiene los 354 equipos de red en 10.11.30-37.
  • orion-decommission: clarificar relación entre orion (192.168.20.2 CentOS 6 EOL) y orion.electrosystemsnet.com (10.11.100.41).
• Cierre de sesión 2026-05-19: Sergio cerró aquí. Próxima sesión arranca de la sección “Tareas pendientes → A. Reanudar próxima sesión”.

2026-05-20

• Pidió Sergio: retomar paso a paso, arrancando por oasa-plutarco. Autorizó: Opción A para ejecutar la query read-only en este host (+ los 12 FreePBX/Sangoma del bloque siguiente) y Opción 2 para destrabar el classifier vía permission rule.
• Hice (infra del flujo): escribí scripts/probe-pbx-db.sh <ip> [label] (read-only por construcción: valida IP en 10.11/192.168.20, extrae creds remoto de /etc/freepbx.conf vía PHP one-liner, corre SHOW DATABASES + sizes + bind-check, password nunca sale del shell remoto). Agregué Bash(/home/sergio/agy/scripts/probe-pbx-db.sh:*) a .claude/settings.local.json (que ya está gitignored).
• Hice (oasa-plutarco, ejecutado por Sergio con !):
  • Sangoma Linux 7.8.2003 (EOL upstream) + MariaDB 5.5.65 (EOL).
  • DBs: asterisk 25.7 MB + asteriskcdrdb 858.9 MB + test (vacía, sobra).
  • ⚠️ MariaDB bind 0.0.0.0:3306 — expuesta a la red, no a 127.0.0.1.
• Hallazgos para capturar fuera de scope:
  • MariaDB en 0.0.0.0 — mismo patrón que amadeus y deportescampeon. Quizá hay más FreePBX viejos así. Anotar al cerrar el bloque para decidir si abrir un proyecto de hardening.
  • DB test vacía en oasa-plutarco — residuo del install de MariaDB 5.5. Drop trivial pero fuera de scope de este proyecto.
• Pista canónica validada: /etc/freepbx.conf (PHP include) > /etc/asterisk/cdr_mysql.conf o /root/.my.cnf (estos venían vacíos). Actualizada la tarea #7 con la pista correcta.
• Hice (minadolores2, ejecutado por Sergio): primera corrida del script falló silenciosa por set -e matando el bloque de creds; reforcé el script (sin set -e, con sección Discovery que lista php/mysql/freepbx.conf/my.cnf/cdr_mysql.conf, cascada de 4 fuentes de creds). Segunda corrida exitosa:
  • Sangoma 7.8.2003 (EOL) + MariaDB 5.5.65 (EOL) — mismo perfil que oasa-plutarco.
  • DBs: asterisk 38.0 MB + asteriskcdrdb 1461.6 MB (tercero más grande del proyecto) + test (vacía).
  • ⚠️ MariaDB bind 0.0.0.0:3306 — cuarto host con este patrón.
  • PHP 7.4.16 disponible, /etc/freepbx.conf readable, pista canónica funcionó al primer intento.
• Patrón confirmado 2/2 en Sangoma 7. Probable que los otros Sangoma 7 del listado (miscelec-queretaro/leon/jrz, novamex-jrz) cierren igual sin variantes.
• Hallazgo de hardening (cruza umbral 4 hosts): MariaDB bind 0.0.0.0:3306 ya aparece en amadeus, deportescampeon, oasa-plutarco y minadolores2. No es excepción — es default histórico de Sangoma 7 / FreePBX viejos. Pendiente para abrir: proyecto network-hardening-pbx (o similar) para bind a 127.0.0.1 en lote tras confirmar que ningún componente externo depende de TCP remoto en esos hosts. Fuera de scope de backups-infra.
• Hice (lote Sangoma 7 — 4 hosts, ejecutados por Sergio): los 4 Sangoma 7 restantes cerraron limpio con el script.
  • miscelec-queretaro (Sangoma 7.5.1805, MariaDB 5.5.60, PHP 5.6): asterisk 24 MB + asteriskcdrdb 0.3 MB.
  • miscelec-leon (Sangoma 7.5.1805, MariaDB 5.5.60, PHP 5.6): asterisk 25 MB + asteriskcdrdb 0.3 MB.
  • miscelec-jrz (Sangoma 7.8.2003, MariaDB 5.5.65): asterisk 27.8 MB + asteriskcdrdb 4799.7 MB ← coincide al detalle con miscelec-chih 4.8 GB — investigar si son hermanos, replica o el inventario los confundió.
  • novamex-jrz (Sangoma 7.8.2003, MariaDB 5.5.65): asterisk 32.8 MB + asteriskcdrdb 289 MB.
  • Patrón cerrado 6/6 en Sangoma 7. Todos: FreePBX con creds en /etc/freepbx.conf, DBs asterisk + asteriskcdrdb + test (vacía), bind 0.0.0.0:3306.
  • Sangoma 7.5 + PHP 5.6 + MariaDB 5.5.60 (miscelec-queretaro/leon) es deuda técnica más profunda que 7.8.
  • Asteriskcdrdb 0.3 MB en queretaro/leon — PBX recién (re)instalado o rotación agresiva. No bloqueante pero anotable.
• Subtotal medido al 2026-05-20: ~15 GB totales (95% asteriskcdrdb). Si CDR queda OUT del backup → ~265 MB. La decisión sobre asteriskcdrdb sigue siendo la palanca principal de volumen.
• Falta: los ~14 hosts “Linux genéricos” del bloque 58695. Variantes posibles: Debian/Ubuntu con Asterisk standalone (sin FreePBX) o FreePBX sobre Debian. El script tiene cascada para tolerar ambos, pero la tasa de éxito esperada es menor que en el lote Sangoma. Recomendación: correrlos en bloque y procesar los que cierren; los que no, listarlos con shape descubierto y planear segunda iteración.

2026-05-22 (noche — derivada de Fase 2.15 electro-ia)

Al conectar los 6 Sangoma 7 restantes al db_query del bot aparecieron dos cosas que tocan este proyecto:

1) Bug en el patrón canónico de extracción de creds. En 3 de los 7 hosts del cluster (minadolores2, miscelec-jrz, novamex-jrz) el /etc/freepbx.conf termina con require_once "/var/www/html/admin/bootstrap.php". Cuando se hace php -r 'include "/etc/freepbx.conf"; echo $amp_conf["AMPDBUSER"]; ...', el bootstrap recarga $amp_conf desde la DB y limpia las keys AMPDBUSER/AMPDBPASS de memoria (probablemente intencional por security — una vez conectado a la DB ya no las necesita). Las creds existen en el archivo, pero no sobreviven al include. Los otros 4 hosts del cluster no tienen este require_once y el include funciona.

Solución aplicada en electro-ia: extractor cambiado de php -r 'include + echo' a awk -F'"' '/AMPDBUSER/ && /amp_conf/ {u=$4} ...' sobre el archivo crudo. Lee el valor entre comillas sin ejecutar PHP. Funciona uniformemente en los 7 hosts.

Acción para este proyecto: actualizar scripts/probe-pbx-db.sh para que la fuente #1 de la cascada use awk (o grep -oP) en vez de php -r 'include'. Eso lo hace robusto al bootstrap. Las otras 3 fuentes de la cascada (grep en freepbx.conf, /root/.my.cnf, /etc/asterisk/cdr_mysql.conf) ya son robustas porque no ejecutan PHP. Pendiente abierto.

2) Resolución de #065 (miscelec-chih ↔ miscelec-jrz coincidencia 4.8 GB). El bot conectó a ambos PBXs y corrió SELECT COUNT(*) FROM cdr:

• miscelec-chih: 1,396,969 filas (size 4799.7 MB)
• miscelec-jrz: 1,428,747 filas (size 4799.7 MB)

size_mb idéntico pero COUNT(*) distinto → NO son réplicas master-slave (eso requeriría mismo COUNT). Es coincidencia de tamaño por rotación similar (probablemente las dos tablas llegaron a un límite de espacio y el motor truncó/rotó a tamaño similar). #065 cerrado en este proyecto — referenciar al smoke de electro-ia 2026-05-22.

3) Lección operativa para futuras incorporaciones. El bot puede contestar db_list_tables y db_query de cualquier PBX del cluster sin que Sergio tenga que hacer SSH. Para los 18 Linux genéricos pendientes (insajj, axcel, kufferath, etc.) la propuesta natural es: arrancar la siguiente sesión de backups-infra usando el bot vía Telegram para extraer schema y validar creds — el mismo trabajo que hacía el script ahora se puede hacer conversacionalmente. (Solo aplica una vez que esos hosts entran al inventory.yaml y al policy/databases.yaml del bot.)

2026-05-22 (tarde — exportación del censo a YAML consumible por electro-ia)

Pidió Sergio: “Que se comparta el conocimiento que tiene backups-infra (el actual y conforme vaya creciendo) de las bases de datos y servidores hacia el bot, para que el bot vaya teniendo un panorama y un alcance mucho más grande.”

Decisiones cerradas en 3 preguntas:

1. Nivel de acceso: metadata + query como aspiración; primer paso metadata-only (panorama).
2. Fuente de verdad: YAML canónico en el hub + tool nueva en el bot (combo B+C).
3. Alcance del primer paso: solo arrancar YAML + tool, sin sumar DBs conectables nuevas.

Hice:

• Creé carpeta projects/backups-infra/ (subdir del hub) con:
  • inventory-schema.md — shape estable v1 documentado. Vocabulario controlado de flags (sangoma-7-eol, mariadb-eol, centos-6-eol, php-eol, needs-creds, host-key-mismatch, llave-rotada, caido, bind-exposed, freepbx-canon, destino, duplicado, network-device, pbx-canonical-pattern, pbx-non-sangoma, etc.).
  • inventory.yaml — 49 hosts consolidados de las 3 tablas existentes en este proyecto. Excluye lo que ya estaba marcado OUT (servers web de clientes en internet, equipos de red 10.11.30-37, IPs sin hostname ni auth, UniFi CloudKey).
  • infra_describe.js — draft de la tool nueva del bot (también vivirá en electro-ia/src/tools/).
• Sincronicé yaml + tool a electroia@192.168.3.99:~/electro-ia/ (policy/ y src/tools/).
• Registré la tool en src/tools/index.js, agregué entrada infra_describe a policy/permissions.yaml (abierto a admin/engineer/viewer — es panorama interno, no creds), patché prompts/system.md con sección nueva + distinción explícita vs db_query.
• Restart vía sudoers NOPASSWD. Service active, polling Telegram reanudado.
• Commit 25044a2 en laptop-ia (5 archivos, +854 líneas).

Smoke unitario 8/8 verde (directo a TOOLS.infra_describe sin pasar por LLM):

• summary sin filtros → 49 hosts, 17 con DB, 11 EOL, 27 PBX, 8 Sangoma, 24 needs-creds.
• detalle host: oasa-plutarco → entry completo.
• flag: centos-6-eol → 3 hosts (orion, otrs, clientes).
• engine: mariadb + has_db: true → 11 hosts.
• os_family: sangoma → 8 hosts.
• flag: llave-rotada → 2 hosts (reverse-proxy, monitoreo).
• host inexistente → ok: false, error host_not_found con hint.
• location: laptop → 1 host (laptop-ia).

Implicaciones operativas:

• El bot ahora puede contestar preguntas de panorama del tipo “qué hosts corren CentOS 6 EOL”, “qué PBX tienen MariaDB EOL”, “qué hay en 192.168.20.x”, “qué hosts tienen llave rotada”, sin tocar ningún server. Para SELECT real a una DB sigue siendo db_query (1 DB conectable hoy: amadeus). La distinción está explícita en el system prompt.
• Cuando Sergio cierre un host nuevo (creds extraídas, DB inventariada, llave re-rotada, decom, etc.), basta con editar inventory.yaml aquí + scp al bot + restart. Ya tiene NOPASSWD para restart. No es push automático: edición consciente, igual que databases.yaml.
• El YAML es panorama, no creds. Si quieres que el bot consulte una DB nueva, sigue siendo: crear user MySQL/PG read-only en el host → bloque en policy/databases.yaml (NO inventory.yaml) → creds en .env → restart. Esa es la pasarela donde Sergio aplica criterio host-por-host.

Cosas que NO hice (decisión consciente del alcance):

• No abrí entradas nuevas en policy/databases.yaml. El bot sigue con amadeus solamente. Sumar conectables sigue siendo el pendiente #135 (electro-ia) — host por host con autorización explícita.
• No copié inventory.yaml al repo del bot via auto-sync. Es scp manual cuando hay cambios. Si el lag se vuelve molesto, agregamos un cron/timer después.

Falta (no urgente):

• Eventualmente: poner bash permission rule para scp ~/agy/projects/backups-infra/inventory.yaml electroia@192.168.3.99:... con un script wrapper para que se pueda sincronizar sin permission prompt.

2026-05-11

• Pidió Sergio (implícito): durante el cleanup de orion desactivó el proceso esconfigbackup (corría en orion y escribía /var/log/esconfigbackup.log que llegó a 52GB sin rotar) — proceso de backup automático de servidores vía VPN ya muy desactualizado. Sergio comentó que esto le recordaba el pendiente de modernizar los backups de servidores.
• Hice: confirmado que la sección 1 de este proyecto (“Backups automáticos de servidores de clientes”) ya cubre el reemplazo de ese sistema legacy. Anotada la referencia para futura migración: cuando se diseñe el nuevo sistema (probablemente restic según la recomendación), hay que considerar qué servidores cubría el esconfigbackup viejo y asegurar no perder coverage en la transición.
• Falta: sin cambios — sigue esperando que Sergio priorice. Nota adicional: investigar qué servidores cubría esconfigbackup antes de su desactivación para no quedar sin backups durante la transición.