Informe de Apagon del Servidor

Servidor: srv1.syscorp.cl (200.63.97.145/146)

Fecha del incidente: 6 de Agosto de 2026

Fecha del analisis: 7 de Agosto de 2026

Sistema operativo: CentOS/CloudLinux 8 (Kernel 4.18.0-553.134.1.el8_10.x86_64)

Entorno: Xen HVM domU (maquina virtual sobre Xen 4.7)

Panel: cPanel & WHM

1. Resumen Ejecutivo

El servidor sufrio un apagon subito (hard crash) durante la madrugada del 6 de agosto de 2026. Estuvo completamente fuera de servicio por aproximadamente 6 horas y 19 minutos. La evidencia apunta a una causa externa a la maquina virtual, probablemente una accion a nivel del hipervisor Xen o del host fisico.

2. Cronologia del Incidente

Hora (GMT-4)	Evento
Ago 6, 00:27:02	Ultima actividad registrada en todos los logs del sistema (messages, maillog, cron, secure)
Ago 6, 00:27 - 06:46	Silencio total (~6 horas, 19 minutos). Los archivos de log contienen bytes NUL (corrupcion por apagon subito sin sync de filesystem)
Ago 6, 06:46:04	El servidor arranca desde cero (kernel boot). Todos los servicios se reinician normalmente.
Ago 6, 06:46:14	Dovecot, PowerDNS, y servicios de cPanel inician correctamente.
Ago 6, 06:51:44	MySQL Server inicia exitosamente.

3. Analisis de Causas Descartadas

Se investigaron las siguientes posibles causas dentro de la VM, y todas fueron descartadas:

3.1 Sin Panico del Kernel

No se encontro ningun mensaje de kernel panic, oops, ni BUG en los logs. El servidor simplemente dejo de escribir en disco.

3.2 Sin OOM Killer (Out of Memory)

No se encontro ninguna actividad del OOM killer. El servidor tiene 19 GB de RAM, y segun los reportes de SAR (System Activity Report), el sistema tenia recursos abundantes:

Recurso	Estado antes del apagon (Ago 5, 23:50)
CPU idle	~83%
RAM disponible	~13 GB (de 19 GB)
Swap usado	~461 MB (de 15 GB)
Disco /	38% usado (251 GB libres de 425 GB)

3.3 Sin Apagado Ordenado

No se registro ningun evento de shutdown, reboot, poweroff ni halt. Un apagado ordenado habria dejado logs del proceso de parada de servicios.

3.4 Sin Crash Dump

A pesar de que el kernel esta configurado con crashkernel=auto (256 MB reservados), el directorio /var/crash/ esta vacio. No se genero ningun volcado de memoria.

3.5 Sin Fallos en Backups de cPanel

Los backups de cPanel se ejecutan cada 5 minutos via backup_jobs_helper. No habia ningun trabajo de backup pesado en ejecucion al momento del apagon.

4. Evidencia del Apagon Subito

4.1 Corrupcion en Archivos de Log

El hallazgo mas revelador es que los archivos de log (/var/log/messages y /var/log/maillog) contienen grandes bloques de bytes NUL (^@) entre la ultima entrada registrada (00:27:02) y el nuevo arranque del kernel (06:46:04):

Aug  6 00:27:02 srv1 imunify360-watchdog[373375]: INFO: Webshield is accessible
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@... (miles de bytes NUL)
Aug  6 06:46:04 srv1 kernel: Command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-...

Este patron es caracteristico de un corte de energia subito donde el filesystem no tuvo oportunidad de sincronizar (fsync) los datos pendientes a disco.

4.2 El Journal no es Persistente

El journal de systemd no esta configurado como persistente (/var/log/journal/ no existe). Esto impidio recuperar los logs del arranque anterior.

5. Causa Mas Probable

  Con una alta probabilidad, la causa fue externa a la maquina virtual:
  Accion en el hipervisor Xen: Alguien con acceso al host fisico (Xen 4.7) pudo haber detenido, pausado o reiniciado la VM. El hecho de que tardara 6 horas en volver sugiere intervencion manual para re-encenderla.
Fallo del host fisico: Un problema de hardware, energia o mantenimiento en el servidor fisico que aloja esta VM pudo haber causado la caida. Si el host no tenia configurado auto-arranque de VMs, estas quedarian apagadas hasta intervencion manual.
Migracion de VM: Una migracion en vivo (live migration) fallida podria haber dejado la VM en estado inconsistente, requiriendo un arranque limpio posterior.

6. Recomendaciones

6.1 Inmediatas

Contactar al proveedor de hosting o administrador del hipervisor Xen para preguntar si hubo alguna accion sobre esta VM o el host fisico durante la madrugada del 6 de agosto.
Solicitar informacion sobre la politica de auto-arranque de VMs en el host Xen.

6.2 Preventivas

Habilitar journal persistente de systemd para preservar logs entre reinicios:
```
mkdir -p /var/log/journal
systemctl restart systemd-journald
```
Configurar monitoreo externo (ej. UptimeRobot, Pingdom, Nagios) que alerte cuando el servidor no responda.
Verificar que el crash kernel este funcionando para capturar volcados de memoria en caso de panico futuro:
```
kdumpctl status
```
Revisar con el proveedor si el host fisico tiene configurado auto-arranque de VMs en caso de reinicio del host.

7. Estado Actual del Servidor

Desde el reinicio del 6 de agosto a las 06:46, el servidor se encuentra operando con normalidad:

Indicador	Valor Actual
Uptime	1 dia, 4 horas
RAM usada	5.6 GB / 19 GB (29%)
Disco /	153 GB / 425 GB (38%)
Carga del sistema	6.00 (normal para este servidor)
Servicios	Todos operativos (MySQL, Dovecot, PowerDNS, cPanel, Imunify360)