Apagados no limpios

Un cierre no limpio ocurre cuando Unraid detecta que el array no se detuvo correctamente antes de que el sistema se apagara. Esta situación puede desencadenar una parity check automática durante el próximo arranque para garantizar la integridad de los datos.

Recommendations para prevenir apagados no limpios

Tomar algunas medidas proactivas puede ayudarte a evitar o identificar apagados no limpios:

• Usa un SAI: Mantén tu servidor conectado a un Sistema de Alimentación Ininterrumpida (SAI) y configúralo para iniciar un apagado controlado cuando la energía de la batería sea baja.
• Intentar un apagado ordenado: Si su servidor no responde, presione brevemente el botón de encendido para activar un apagado seguro. No mantenga el botón presionado, ya que esto forzará un apagado duro y provocará un apagado no limpio.
• Habilitar registro persistente: Ve a Configuración → Servidor de Syslog para activar el registro que persiste después de un reinicio. Consulta Registros persistentes (servidor Syslog) para más detalles.
• Adjuntar diagnósticos para soporte: Si ocurre un apagado no limpio, Unraid intentará guardar los diagnósticos en /log/diagnostics.zip en su dispositivo de flash. Adjunte este archivo a las publicaciones en el foro cuando busque ayuda.

UPS mejores prácticas de configuración

Un SAI bien configurado es tu mejor defensa contra apagados no limpios causados por pérdida de energía.

• Conecta el SAI vía USB a tu servidor Unraid.
• Habilitar el soporte de SAI en Configuración → Configuración de SAI.
• Configura los tiempos de espera de apagado: Establezca el UPS para que active un apagado controlado antes de que la batería se agote. Ajuste los umbrales de "Tiempo de ejecución restante de la batería" o "Nivel de carga de la batería" para proporcionar suficiente tiempo para que Unraid detenga el array y se apague de forma segura.
• Prueba tu configuración: Simula una pérdida de energía para asegurarte de que el SAI y Unraid respondan correctamente.

Consulte el plugin NUT para obtener una mayor compatibilidad con modelos UPS más avanzados o hardware no compatible.

Eventos que provocan apagados no limpios

Comprender los principales desencadenantes de apagados no limpios lo ayuda a prevenirlos. Las siguientes secciones cubren los escenarios más comunes y sus soluciones.

Pérdida de energía inesperada

Las interrupciones de energía son una de las principales razones de apagados no limpios. Protege tu sistema con un SAI (Sistema de Alimentación Ininterrumpida) configurado correctamente que pueda apagar automáticamente Unraid antes de que se agote la batería.

nota

Unraid admite la mayoría de las unidades UPS utilizando el protocolo apcupsd (APC y CyberPower suelen ser compatibles). Si tu UPS no es compatible, considera usar el complemento Network UPS Tools (NUT) de Community Applications.

Fallo de unidad flash

El estado de array se guarda en tu dispositivo USB. Si la unidad flash se vuelve inaccesible o entra en un estado de solo lectura, Unraid no puede actualizar el estado de apagado, incluso si el array se detiene correctamente. Esto resulta en un apagado incorrecto que se detecta en el próximo arranque.

Abrir sesiones de terminal

Unraid espera que todas las sesiones abiertas de terminal o SSH se cierren durante el apagado. Si estas sesiones permanecen activas y el temporizador de apagado expira, se produce un apagado forzado.

consejo

El plugin Dynamix Stop Shell puede cerrar automáticamente sesiones de bash o SSH que estén sin actividad, ayudando a asegurar un apagado ordenado. Sin embargo, tenga cuidado si hay operaciones de escritura en curso en el array.

---

Tiempo de espera para máquinas virtuales

Configurar correctamente los tiempos de espera de apagado es esencial para asegurar que su servidor Unraid pueda detener todos los servicios de manera efectiva. Esto evita apagados no limpios, especialmente durante cortes de energía o mantenimiento. El paso más importante es configurar sus VMs para hibernar en lugar de apagarse. Este enfoque ayuda a eliminar muchos problemas relacionados con el tiempo de espera.

Configuración de hibernación de VM

:::tip[Use Hibernación de VM

Para los apagados más confiables y rápidos, configure sus VMs para hibernar en lugar de apagarse. Esto es especialmente importante para las VMs de Windows, pero beneficia a todos los tipos de VM.

Recomendamos usar la hibernación porque:

• Guarda el estado de la VM al instante - No hay que esperar a que el sistema operativo invitado se apague.
• Previene la pérdida de datos - Sin riesgo de interrumpir actualizaciones o trabajos no guardados.
• Evita problemas de tiempo de espera - La hibernación es casi instantánea.
• Recuperación más rápida - Las VMs se reanudan exactamente donde se quedaron.

El apagado puede ser problemático porque:

• Windows puede mostrar cuadros de diálogo ("¿Guardar este documento?") que detienen el apagado indefinidamente.
• Las actualizaciones de Windows pueden tardar más de 10 minutos durante el apagado.
• Si el tiempo de espera expira, Unraid forzará el cierre de la VM, lo que podría corromper actualizaciones de Windows en curso, documentos no guardados, datos de aplicaciones y sistemas de archivos en el sistema operativo invitado.

Requisito crítico: Asegúrese de que el QEMU Guest Agent esté instalado en la VM para que la hibernación funcione correctamente.

:::

Para habilitar la hibernación de VM:

VMs de Windows

1. Descargar QEMU Guest Agent:

   • Vaya a la página de descarga de controladores VirtIO.
   • Descargue el archivo virtio-win.iso más reciente.

2. Instalar en Windows VM:

   • Monte la virtio-win.iso en su VM.
   • Ejecute el instalador desde la ISO montada.
   • Instale tanto los controladores VirtIO como el QEMU Guest Agent.
   • Reinicie la VM.

3. Configure en Unraid:

   • Vaya a la configuración de su VM en la pestaña VMs.
   • Establezca Acción de apagado en Hibernar.
   • Haga clic en Aplicar.

VMs de Linux

1. Instale QEMU Guest Agent:

# Ubuntu/Debian
sudo apt install qemu-guest-agent

# CentOS/RHEL/Fedora
sudo yum install qemu-guest-agent
# or
sudo dnf install qemu-guest-agent

2. Habilitar el servicio:

   sudo systemctl enable qemu-guest-agent
   sudo systemctl start qemu-guest-agent

3. Configure en Unraid:

   • Configure Acción de apagado en Hibernar en la configuración de su VM.

VMs de electrodomésticos

Algunas VMs, como Home Assistant, no permiten la instalación de software adicional. Para estas:

• Mantenga Acción de apagado establecida en Apagar.
• Use valores de tiempo de espera más largos (consulte las recomendaciones de tiempo de espera a continuación).
• Considere los riesgos de forzar el cierre de estas VMs durante las actualizaciones.

Why appliance VMs are different

Appliance VMs are designed to run specific software and often don't allow the installation of additional packages, such as QEMU Guest Agent. This means hibernation isn't available, so you'll need to rely on proper timeout configuration.

Ahora, para verificar que tu hibernación funcione, inicia tu VM y abre algunas aplicaciones. Luego, deténla desde Unraid. Cuando la reinicies, debería reanudarse con todas las aplicaciones aún abiertas.

:::warning[Guest Agente es crítico

Sin el QEMU Guest Agent instalado, la hibernación puede no funcionar correctamente. En ese caso, la VM volverá al modo de apagado, consumiendo todo el periodo de tiempo de espera.

:::

---

Configuración de tiempo de espera

En esta sección, cubriremos cómo configurar los tiempos de espera para varios sistemas y procesos. Esta información es importante para asegurar que sus VMs y contenedores Docker se apaguen correctamente sin pérdida de datos.

Configuración	Defecto	Cuándo aumentar	Dónde configurar
Tiempo de espera para apagado de VM	60s	300s si no se usa hibernación y las VMs se bloquean	Configuración → Gestor de VM → Apagado de VM (Avanzado)
Tiempo de espera para detener contenedor Docker	10s	30s si alguno de los contenedores se bloquea al detenerse	Configuración → Docker (Avanzado)
Tiempo de espera general de apagado	90s	180s si obtienes apagados no limpios, 300s+ con VMs	Configuración → Configuración de Disco → Tiempo de espera para apagado

:::tip[When para aumentar tiempo de espera

Si experimentas apagados anómalos o contenedores que se bloquean durante el apagado, considera aumentar el tiempo de espera general de apagado a 180 segundos (o 300+ segundos si tienes múltiples VMs). Esto da más tiempo a los servicios para apagarse correctamente.

:::

Secuencia de apagado

Al apagar, el proceso ocurre en el siguiente orden:

1. Apagado de VM: Esto implica tres etapas, y cada una puede tomar hasta el tiempo de espera de la VM:

   • Etapa 1: Reanudar cualquier VMs pausada
   • Etapa 2: Hibernar VMs que están configuradas para hibernación
   • Etapa 3: Apagar cualquier VMs restantes

   Todas las VMs en cada etapa se procesan al mismo tiempo, lo que significa que el tiempo total de apagado puede calcularse como: tiempo de espera de la VM × 3.

2. Los contenedores de Docker se detienen simultaneamente (tiempo total = tiempo de espera de Docker).

3. Otros servicios incluyen tareas como contenedores LXC y complementos de terceros, que generalmente toman unos pocos segundos.

4. Apagado del array: las unidades deben desmontarse y sincronizarse los datos; esto típicamente toma de 15-30 segundos.

:::tip[Calculate su tiempo de espera general de apagado

Fórmula: Su tiempo de espera general de apagado debe ser mayor que:

(VM timeout × 3) + (Docker timeout) + (Other services) + 15-30 seconds

Ejemplo: Si seguimos la fórmula, se vería así: (300 × 3) + 30 + 10 + 30 = 970 segundos (más de 16 minutos).

Recomendado: Al menos 180 segundos (3 minutos) como mínimo y 300+ segundos (5+ minutos) si tiene múltiples VMs o contenedores complejos.

:::

Si todos sus VMs están configurados para hibernar en lugar de apagarse, entonces el tiempo de espera de la VM es menos crítico ya que la hibernación es casi inmediata. Podría usar un tiempo de espera menor para las VM (por ejemplo, 60-120 segundos) como respaldo para cualquier VMs que no admitan hibernación.

---

Guía detallada de configuración

Esta sección proporciona información detallada sobre cómo configurar los tiempos de espera para diferentes componentes del sistema. Cada configuración de tiempo de espera funciona junta para garantizar que su servidor se apague correctamente sin pérdida de datos.

Tiempos de espera de VM

Configura los tiempos de espera al apagar la VM en Configuración → Administrador de VM → Apagado de VM (activa la vista avanzada).

Cómo funciona:

• Las VMs pasan por tres etapas de apagado, cada una consume el tiempo de espera completo de la VM.
• Todas las VMs en cada etapa se procesan simultáneamente
• Tiempo total de apagado de VM = tiempo de espera de VM × 3

Problemas comunes:

• Interrupciones de actualización de Windows: Las actualizaciones durante el apagado pueden corromperse si expira el tiempo de espera.
• Trabajo no guardado: Los cuadros de diálogo que preguntan si desea guardar documentos pueden detener el apagado indefinidamente.
• Fallos de hibernación: VMs sin el QEMU Guest Agent pueden fallar en hibernar y usar todo el tiempo de espera.

VM recomendaciones de tiempo de espera

• Recomendación principal: Configure las VMs para hibernar en lugar de apagar (requiere QEMU Guest Agent).
• Si las VMs se bloquean durante el apagado: Aumente el tiempo de espera a 300 segundos (5 minutos) para VMs de Windows.
• Actualizaciones de Windows: Configure Windows para instalar actualizaciones al inicio en lugar de durante el apagado.
• Prueba tu configuración: Detén manualmente tus VMs para confirmar que se apaguen o hibernen dentro del período de espera.

No tiempo de espera seguro sin hibernación

Sin hibernación y QEMU Guest Agent, no existe un tiempo de espera verdaderamente seguro para las VMs de Windows. Los cuadros de diálogo o las instalaciones de actualizaciones en curso podrían hacer que cualquier tiempo de espera sea inadecuado, lo que podría llevar a apagados forzados y riesgo de corrupción de datos.

Tiempos de espera de Docker

Configura los tiempos de espera de detención de contenedores Docker en Configuración → Docker (activa la vista avanzada).

Cómo funciona:

• Los contenedores se detienen en paralelo, por lo que el tiempo total es igual al tiempo de espera de detención de Docker.
• La mayoría de los contenedores se detienen en 10 segundos, pero algunos pueden necesitar más tiempo.
• Contenedores complejos con grandes bases de datos u operaciones en curso podrían requerir tiempo adicional.
• Si el temporizador expira, los contenedores se detienen forzosamente.

Docker recomendaciones de tiempo de espera

• Los 10 segundos por defecto funcionan bien para la mayoría de los contenedores.
• Si los contenedores fallan al detenerse: Incrementa el tiempo de espera a 30 segundos.
• Supervisa tus contenedores durante el apagado para identificar aquellos que consistentemente necesitan más tiempo.

Tiempos de espera generales

Configura el tiempo de espera general de apagado en Configuración → Configuración de disco → Tiempo de espera de apagado.

Consideraciones sobre la UPS (factor más crítico):

• Tu UPS debe proporcionar suficiente tiempo de ejecución para completar la secuencia de apagado completa antes de que se agote la batería.
• Para apagado manual, puedes establecer tiempos de espera más largos ya que controlas cuándo comienza el apagado.
• Con apagado por corte de energía, tu tiempo de espera está limitado por la vida útil de la batería de la UPS.
• Prueba tu UPS simulando una interrupción eléctrica para asegurarte de que tu servidor se apague limpiamente con tiempo de sobra.

General recomendaciones de tiempo de espera

• Si obtienes apagados no limpios: Incrementa a 180 segundos (3 minutos) para sistemas sin VMs.
• Para sistemas con VMs: Utiliza 300+ segundos (5+ minutos) si no usas hibernación.
• Si usas hibernación: 180-300 segundos suelen ser suficientes.
• Asegúrate de que los tiempos de espera no sean más largos de lo que tu UPS puede soportar durante un corte de energía.

Servicios de terceros

Contenedores LXC: El plugin LXC tiene su propia configuración de tiempo de espera para detener contenedores. Al igual que los contenedores Docker, los contenedores LXC normalmente se detienen en unos pocos segundos, pero algunos pueden requerir más tiempo. Revisa la configuración del plugin LXC para el tiempo de espera de detención y añade este tiempo de espera a tu cálculo general de apagado.

Otros servicios: Algunos plugins o servicios personalizados pueden tener sus propios procedimientos de apagado. Consulta la documentación del plugin para configuraciones de tiempo de espera específicas e incorpóralas en tus cálculos.

Fórmula actualizada con servicios de terceros:

(VM timeout × 3) + (Docker timeout) + (LXC/other timeouts) + 15-30 seconds

Plugin Dynamix Stop Shell: Si frecuentemente utilizas sesiones SSH o de terminal, las sesiones abiertas pueden evitar apagados limpios porque Unraid espera a que se cierren antes de proceder.

El plugin Dynamix Stop Shell ayuda cerrando automáticamente las sesiones persistentes de bash o SSH cuando se detiene el array, asegurando un apagado oportuno.

Puedes instalarlo desde Community Applications (busca "Dynamix Stop Shell").

When para usar el plugin

• Si regularmente tienes sesiones de terminal abiertas.
• Para prevenir que las sesiones SSH olvidadas retrasen el apagado.
• Para limpieza automatizada durante el apagado.

precaución

• Sé cauteloso si tienes scripts o procesos ejecutándose en sesiones de terminal.
• Asegúrate de que no haya operaciones de escritura críticas en progreso antes de apagar.
• El plugin cerrará las sesiones de manera forzada, lo que podría interrumpir el trabajo.