Comprobar el estado del SSD de Sophos Firewall mediante SMART

Un valor SMART puede resultar útil para diagnosticar el hardware. En XGS Appliances físicos cuyo SSD interno está montado como /dev/sda, una consulta de solo lectura con smartctl devuelve el atributo de resistencia. Sin embargo, para SFOS 22.0 Sophos no documenta un comando general para administradores, una ruta de disco fija ni un umbral de desgaste válido para todos los modelos. Por tanto, compruebe primero la appliance, el nodo y la ruta del dispositivo, y considere el valor como un indicio de diagnóstico, no como el único criterio para decidir una sustitución.

El procedimiento seguro comienza en WebAdmin: compruebe la ocupación y el comportamiento del sistema, genere un Consolidated troubleshooting report (CTR) e involucre a Sophos Support si sospecha que existe un problema de hardware. La consulta descrita a continuación lee los datos SMART existentes y no inicia ninguna prueba automática. Otras rutas de dispositivo, pruebas SMART o comandos de reparación solo deben utilizarse en el contexto de un caso de soporte concreto.

⚠️ Importante: La Advanced Shell ofrece acceso directo al sistema. No pruebe rutas de disco, inicie pruebas automáticas SMART, modifique particiones, borre archivos manualmente ni sustituya los SSD por su cuenta. Incluso system fsck-on-nextboot en Device Console solo debe utilizarse por recomendación de Sophos Support: el comando ayuda cuando se producen errores de montaje de /sig, /conf o /var, fuerza la comprobación del sistema de archivos de todas las particiones durante el siguiente reinicio y puede dañar el sistema de archivos si el hardware o el SSD no están en buen estado. on, off y show activan, desactivan o muestran el estado; el valor predeterminado es off. En modo Failsafe, SFOS puede activar automáticamente la comprobación, por ejemplo, si no se inician las bases de datos de configuración, informes o firmas, no se puede aplicar una migración o falta el modo de despliegue. El procedimiento seguro se describe en Diagnosticar el modo Failsafe de Sophos Firewall.

Procedimiento de diagnóstico seguro

1. En WebAdmin, vaya a Diagnostics > System graphs, seleccione Disk usage como gráfico y elija un periodo que incluya el inicio de la incidencia.
2. Compruebe si, al mismo tiempo, se observan anomalías en los informes, logs, la cuarentena, WebAdmin o los servicios. El gráfico Disk usage muestra el espacio ocupado, no el desgaste del SSD ni su estado SMART.
3. Antes de actualizar el firmware, revise también los avisos y las notificaciones del firewall. SFOS 22.0 puede indicar que determinados modelos de XGS Appliance requieren una actualización del firmware del SSD; en HA, los requisitos de actualización se comprueban por separado para cada nodo.
4. En Diagnostics > Tools, dentro de Consolidated troubleshooting report, seleccione System snapshot y All log files, introduzca el motivo del diagnóstico, haga clic en Generate y después en Download. El modo debug no es necesario para System snapshot.
5. Si se producen errores de I/O, del sistema de archivos, de arranque o recurrentes de la base de datos, abra un caso con Sophos Support y proporcione el CTR, la hora, los síntomas y los datos del dispositivo. El soporte decidirá si se necesitan diagnósticos adicionales mediante shell o SMART y si procede una RMA.

Si el problema solo afecta al espacio disponible, consulte Comprobar el espacio de almacenamiento de Sophos Firewall y gestionar los informes. Central Firewall Reporting puede reducir la dependencia de los datos de informes locales. En cambio, un Sophos Firewall Health Check evalúa los riesgos de configuración y no sustituye un diagnóstico de hardware.

Qué significan las señales visibles

Disk usage indica capacidad, no desgaste

En Diagnostics > System graphs > Disk usage, el eje X muestra minutos, horas, días o meses según el periodo seleccionado, y el eje Y, el porcentaje de ocupación. La leyenda diferencia las firmas (naranja), los archivos de configuración (violeta), los informes (verde) y el almacenamiento temporal (azul). Un valor alto puede afectar a los informes y servicios, pero no demuestra que exista un fallo del SSD. A la inversa, disponer de espacio libre no aporta información sobre errores de hardware ni sobre la vida útil de escritura restante. El gráfico no contiene atributos SMART ni umbrales de desgaste.

Un aviso de firmware del SSD no es un resultado SMART

Para algunos modelos de XGS Appliance, antes de instalar SFOS 22.0 o una versión posterior puede ser obligatoria una actualización del firmware del SSD destinada a mejorar la fiabilidad. Si se requiere alguna acción, aparece una notificación. Se trata de un requisito de actualización específico del modelo, no de un valor de resistencia medido ni de un defecto automático.

Por ello, antes de actualizar, compruebe que dispone de un backup actual, espacio libre suficiente, una ruta de actualización compatible, las Release Notes y una ventana de mantenimiento. En HA, ambos nodos deben estar accesibles, en buen estado y sincronizados, y cada uno debe cumplir por separado los requisitos de actualización; si uno de ellos no los cumple, puede bloquear la actualización. Inicie la actualización únicamente desde Primary Device.

Las salidas SMART son datos de diagnóstico específicos del modelo

Los atributos SMART, los nombres de los dispositivos y su significado pueden variar según el SSD, el controlador, la appliance y el firmware.

Consultar la resistencia en un XGS Appliance con /dev/sda

Acceda al firewall mediante SSH, abra la Advanced Shell y confirme que trabaja en la appliance o el nodo HA correctos. Avanet ejecutó la consulta en un XGS 3100 con SFOS 21.5.1 MR-1 Build 261. Si el SSD interno está montado en ese equipo como /dev/sda, este comando lee todos los datos SMART y muestra únicamente las líneas que contienen Endurance:

smartctl -x /dev/sda | grep Endurance

En el ejemplo de Avanet, el SSD comunica el valor bruto 1 para Percentage Used Endurance Indicator. En esta unidad, un valor bajo indica que se ha consumido poca vida útil de escritura. No aplique esta escala a otros SSD sin comprobarla: el nombre del atributo, su normalización y el valor bruto pueden tener un significado distinto según el fabricante y el modelo. Por tanto, un valor de 80 no constituye un umbral universal de RMA de Sophos. Documente su evolución y tenga en cuenta los síntomas, los errores de I/O y la evaluación específica del modelo.

El comando y su interpretación según el modelo ya se han debatido públicamente en la práctica porque no aparecen documentados en la ayuda de Sophos Firewall: Comprobar la vida útil del SSD de Sophos XGS en Administrator.de. El artículo recomienda sustituirlo pronto cuando el valor supera 80; Avanet ha decidido expresamente no adoptar este valor procedente de la comunidad como umbral universal de RMA de Sophos. La captura de pantalla anterior procede de una appliance de Avanet, no de dicho artículo.

Un SSD puede fallar sin que SFOS emita antes una advertencia. HA protege el tráfico, pero no necesariamente todos los datos almacenados de forma local: los logs, la cola de correo y la cuarentena pueden verse afectados en el nodo averiado; la cola de correo y la cuarentena no se sincronizan entre los nodos HA. Los informes centralizados, los backups recientes y un procedimiento de recuperación documentado reducen el riesgo, pero no sustituyen la supervisión del SSD.

Si no aparece ninguna línea, puede que no exista un atributo Endurance adecuado, que la ruta de dispositivo confirmada no sea correcta para esa appliance o que smartctl no pueda leer el SSD de ese modo a través del controlador instalado. Una salida vacía no demuestra ni que el SSD esté en buen estado ni que esté averiado. No pruebe otros nombres de dispositivo ni inicie una prueba automática SMART.

Para interpretar los resultados, tenga en cuenta lo siguiente:

• Utilice /dev/sda únicamente si se ha confirmado esta ruta para la appliance concreta; no adivine rutas NVMe o RAID.
• No deduzca un umbral general a partir de nombres de atributo como Endurance, Percentage Used o Wear.
• No interprete un solo valor ni la diferencia entre dos nodos HA como una decisión de sustitución.
• No considere la ausencia de salida SMART como prueba de que el SSD está en buen estado o averiado.

En HA, el comando confirmado se ejecuta por separado en ambos nodos, ya que cada nodo tiene su propio SSD. Guarde juntos la salida, la fecha, la zona horaria, la versión de SFOS y el rol del nodo. Si aparecen síntomas, valores altos o que aumentan rápidamente, o atributos poco claros, añada también el número de caso y la evaluación de Sophos Support.

Documentar y validar los resultados

Un historial breve y coherente resulta más útil que un valor aislado:

• Fecha y hora con zona horaria: por ejemplo, 2026-09-05 10:30 CEST
• Appliance y ubicación: por ejemplo, XGS 2100 – HQ
• Número de serie y, en HA, el rol: Primary o Auxiliary
• Versión y build de SFOS
• Síntoma: advertencia de almacenamiento, error de I/O, error de arranque o problema de informes o de la base de datos
• Periodo de Disk usage y cambios anómalos
• Archivo CTR y número del caso de soporte
• Consulta SMART práctica: ruta de dispositivo confirmada, comando exacto y salida sin modificar

El diagnóstico no termina únicamente porque el gráfico sea normal o por disponer de un solo valor SMART. Como validación, compruebe si la ocupación del almacenamiento y las funciones afectadas permanecen estables después de aplicar la medida segura, y si los errores vuelven a producirse durante el periodo de observación acordado. En firewalls virtuales, el estado del disco, el datastore, la latencia de I/O y los errores deben supervisarse principalmente desde el hipervisor y la plataforma de almacenamiento.

Si sospecha de la temperatura o los ventiladores, consulte Comprobar la temperatura y los ventiladores mediante SSH; puede complementar el estado y el historial de los sensores de hardware compatibles con Monitorización de hardware mediante SNMP. Ninguna de estas comprobaciones sustituye el diagnóstico del SSD por parte de Sophos.

Si la appliance es inestable o no está accesible

No ejecute por precaución comandos de reinicio, del sistema de archivos o de reparación. Documente la última hora en que funcionaba, los cambios anteriores a la incidencia, el estado de los LED y la accesibilidad mediante HTTPS, SSH y la consola serie. Si se ha producido una pérdida total de alimentación, pruebe primero otra toma de corriente y otro cable de alimentación; en appliances con dos fuentes de alimentación, compruebe la segunda entrada y, en los modelos previstos para ello, otra fuente hot-swap. Una foto o un vídeo del comportamiento de los LED y del arranque agiliza la comprobación para la RMA.

Si la appliance no arranca, compruebe HTTPS y SSH tanto por LAN como por WAN, así como la consola serie directamente mediante DB-9, un adaptador Serial-to-USB o el puerto de consola Micro-USB disponible en los modelos de XGS Appliance más recientes. En Device Manager del equipo del administrador, compruebe si hay errores de controlador o conexión. Configure 38400 baudios, revise el estado en varios intervalos de tiempo y documente mediante capturas de pantalla los errores visibles. Si la consola no muestra nada, repita la comprobación con otro cable u ordenador. Sophos decide si un dispositivo se considera DOA únicamente después de realizar su propia evaluación. El procedimiento interno completo se describe en Sophos hardware defectuoso: preparar la RMA y la sustitución.

Si todavía se puede acceder a la appliance, reproduzca el error inmediatamente antes de recopilar los datos y anote la hora exacta con la zona horaria. En Diagnostics > Tools > Consolidated troubleshooting report, seleccione System snapshot y All log files, indique el motivo, haga clic en Generate y después en Download. Cargue el informe cifrado en el caso de soporte. Algunos logs del CTR solo contienen el número de líneas configurado mediante CLI; por tanto, si el evento ocurrió hace tiempo, guarde también por separado los Troubleshooting logs afectados. El modo debug está desactivado de forma predeterminada y no es necesario para System snapshot; los logs de debug aumentan el espacio utilizado y deben desactivarse después de una recopilación específica. En HA, los logs y los informes no se sincronizan, por lo que deben recopilarse por separado en cada nodo e identificarse de forma inequívoca. El procedimiento completo se describe en Guardar logs de Sophos Firewall para soporte y análisis.

Si Sophos solicita acceso remoto para el diagnóstico, puede generar un Access ID temporal en Diagnostics > Support access. Para ello, el firewall establece una conexión de control segura saliente mediante TCP 22 hacia *.apu.sophos.com; cualquier router situado delante debe permitirla. Active Support access, confirme con OK, seleccione la duración, haga clic en Apply, vuelva a confirmar con OK y copie el ID único que aparece en Access status. Comparta el Access ID únicamente dentro del caso de soporte. Con él, Sophos puede acceder a WebAdmin y a la shell sin la contraseña de administrador; las sesiones inactivas finalizan después de 15 minutos. El acceso puede desactivarse en cualquier momento y se deshabilita tras cerrar el caso. El procedimiento interno detallado se describe en Habilitar Sophos Firewall Support Access para Avanet.

Preparar el soporte y la RMA

Antes de escalar el caso, tenga preparados los siguientes datos:

• descripción exacta del error, inicio, frecuencia e impacto;
• modelo, revisión, número de serie, versión y build de SFOS;
• estado de HA y nodo afectado;
• evolución de Disk usage, mensajes de error relevantes y CTR;
• backup de configuración actual descargado;
• contraseña de cifrado del backup y Secure Storage Master Key correspondiente guardados de forma segura, aunque solo deben compartirse mediante el método seguro indicado por Sophos;
• estado de la licencia y del soporte.

Un valor SMART no genera automáticamente una RMA. Según Sophos, el proceso de RMA comienza con la identificación del error y los datos del dispositivo, seguido de un caso de soporte y su validación; Sophos puede solicitar diagnósticos adicionales. El formulario de RMA debe incluir el modelo, la revisión, la versión de firmware, el número de serie y la pertenencia a HA.

En HA también debe aclararse qué nodo se sustituirá. La reconstrucción descrita a continuación solo es válida para Active-Passive, no para Active-Active, y provoca una interrupción del servicio. Registre previamente el modelo, la revisión, cuál era el Primary inicial, así como la versión de firmware y el build de ambos dispositivos mediante system diagnostics show version-info.

• Preparar el dispositivo de sustitución: Si no está disponible el mismo build de firmware, solicítelo a Sophos Support. Conecte un cliente DHCP al puerto 1 y abra https://172.16.16.16:4444. Utilice Setup Assistant para configurar el puerto 2 únicamente como WAN y para el acceso a Internet; no configure todavía otras interfaces. Después del reimage o la actualización, vuelva a comprobar el build con system diagnostics show version-info.
• Sustituir el Auxiliary: El Primary en buen estado funcionará temporalmente por sí solo. Instale en el dispositivo de sustitución la misma versión y build de firmware, reclámelo en Central y transfiera la licencia del Auxiliary averiado. Desactive HA en el Primary en buen estado, compruebe con service -S | grep msync que el estado sea UNTOUCHED o STOPPED, cambie el cableado y vuelva a crear el HA Active-Passive con el dispositivo en buen estado como Primary.
• Sustituir el Primary: Anule el registro del Auxiliary en buen estado en Central y confirme en My Products > Firewall Management > Firewalls que ya no aparece. Guarde su backup actual. Instale en el dispositivo de sustitución la misma versión y build de firmware, reclámelo, transfiera la licencia, restaure el backup y, después de cambiar el cableado, deje que gestione el tráfico de forma independiente. A continuación, restablezca a la configuración de fábrica el antiguo Auxiliary en buen estado, vuelva a reclamarlo y configure de nuevo el HA Active-Passive con el dispositivo de sustitución como Primary.

La sustitución proporciona el hardware, pero no garantiza que el servicio esté operativo. Documente antes de la ventana de mantenimiento la transferencia de la licencia, la compatibilidad del backup, la asignación en Central, el cableado y la prueba funcional. Los principios básicos de los roles se explican en Clúster HA de Sophos Firewall: Active-Passive, Active-Active y Auxiliary Appliance.

¿Durante cuánto tiempo tiene garantía el hardware de Sophos? resume los principios básicos de garantía y soporte. Si Sophos exige un reimage, siga el procedimiento independiente Reinstalar Sophos Firewall OS: reimage con una memoria USB.

Comprobación final

• Se han comprobado Disk usage y el periodo sin interpretar la capacidad como estado del SSD.
• Se han documentado los síntomas, la evolución temporal, el modelo, el número de serie, la versión de SFOS y el nodo HA.
• Se ha guardado un backup actual fuera de la appliance y están disponibles los secretos de restauración.
• Se ha generado y guardado de forma segura un CTR con System snapshot y All log files.
• No se han utilizado rutas de dispositivo supuestas ni se han ejecutado pruebas automáticas SMART o comandos fsck, de borrado o de reparación sin autorización.
• Si se sospecha de un problema de hardware, se ha abierto un caso de soporte; cualquier diagnóstico adicional solo se realiza siguiendo instrucciones concretas del soporte.
• La RMA o la sustitución del hardware solo se planifican después de que Sophos las valide.

FAQ