> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/knowledge-base/es/system-administration/cluster-recovery-after-power-outage.md).

# Recuperación del clúster después de un corte total de energía

## Resumen

{% hint style="info" %}
**Puntos clave**

* Los apagados no controlados deben evitarse siempre que sea posible, especialmente en sistemas de producción.
* Esta guía proporciona buenas prácticas -- para mitigar problemas potenciales -- para encender el clúster después de que ocurra un apagado inesperado.
* Encender **Node1** primero. Espere de 30 segundos a un minuto, luego encienda los nodos restantes del clúster.
* Un **Reparaciones** conteo tras la recuperación es normal; debería disminuir a medida que se completen los Journal Walks.
* Póngase en contacto con el soporte de VergeIO si el conteo de Reparaciones no vuelve a cero al completarse el Journal Walk o si persisten otras anomalías.
  {% endhint %}

## Alcance

Esta guía cubre cómo volver a encender un clúster VergeOS después de un **apagado no controlado** -- en el que el clúster perdió la energía bruscamente debido a un corte eléctrico, agotamiento del SAI/UPS, fallo de la instalación o un evento similar. Para los procedimientos planificados y controlados de apagado y encendido, consulte [Procedimiento correcto de apagado del sistema VergeOS](/knowledge-base/es/system-administration/proper-vergeos-system-shutdown-procedure.md) y [Secuencia correcta de encendido y apagado](/knowledge-base/es/system-administration/proper-power-sequence-for-vergeos.md).

{% hint style="warning" %}
**Evitar apagados no controlados siempre que sea posible**

* Aunque VergeOS incluye múltiples protecciones integradas para preservar la integridad de los datos, ningún sistema de almacenamiento distribuido puede garantizar por completo contra la corrupción de datos cuando los nodos pierden la energía de forma abrupta y simultánea.
* Las escrituras en curso en el momento de la pérdida de energía pueden quedar incompletas o inconsistentes entre pares, y en algunos casos la única forma de recuperar la integridad es revertir un volumen a una instantánea reciente.
* Además, los problemas de hardware, del sistema operativo invitado y de las aplicaciones son comunes después de apagados no controlados.
* Una infraestructura de alimentación adecuada -- cobertura de UPS/SAI dimensionada para un apagado controlado, fuentes de alimentación redundantes y apagado automatizado con batería baja -- es la protección más eficaz; consulte la [Prevención](#preventionmitigation) sección para obtener orientación.
* Cuando se produce un apagado no controlado a pesar de estas precauciones, el procedimiento que sigue está diseñado para volver a poner el clúster en línea de forma segura y detectar cualquier problema de integridad que requiera atención.
  {% endhint %}

## Requisitos previos

* Acceso físico o IPMI/BMC a cada nodo
* Conocimiento de qué nodo es **Node1** (Node1 deberá arrancarse primero.)
* Confirmación de que la energía aguas arriba, la red (switches principales de la infraestructura) y el IPMI se han restablecido y son estables
* Una instantánea reciente local o replicada remotamente en caso de que se detecten problemas de integridad
* Familiaridad con el [Panel de vSAN Tier / Journal Walks](/knowledge-base/es/storage-vsan/understanding-journal-walks-and-vsan-tier-status.md)

## Pasos

### Qué esperar

* VergeFS incluye múltiples protecciones integradas para ayudar a preservar la integridad de los datos durante eventos de energía -- incluyendo journaling de escrituras, replicación entre pares, servidores de reparación (ioGuardian) y verificación al iniciar. Al arrancar el controlador, VergeFS desencadena un **Journal Walk completo** para verificar cada bloque y reconciliarlo con los pares. Estas protecciones son eficaces en la mayoría de los casos, pero ningún sistema de almacenamiento distribuido puede garantizar por completo contra la corrupción causada por una pérdida brusca de energía; la verificación después del inicio es importante, especialmente después de un apagado no controlado.
* vSAN requiere **Cantidad mínima de nodos** en línea antes de montarse (p. ej., en un clúster de 4 nodos con protección N+1, vSAN se monta siempre que 3 nodos estén en línea) Hasta que se alcance ese umbral, el almacenamiento permanece fuera de línea y las VM no se iniciarán.
* Node1 arrancará pero se detendrá antes de montar vSAN hasta que se unan suficientes pares.
* Un **Reparaciones** conteo tras la recuperación es normal y debería disminuir a medida que avanza el Walk.

### Comprobaciones previas al encendido

{% hint style="warning" %}
**Verifique primero que la infraestructura esté lista**

Antes de encender cualquier nodo del clúster, confirme que se cumplen dos condiciones críticas. Estas se cubren en los requisitos previos, pero vale la pena repetirlas aquí -- omitirlas puede causar mucho más daño que el apagado original:

1. **La energía de la instalación se ha restablecido por completo y es estable.** Levantar el clúster durante una inestabilidad eléctrica en curso -- parpadeos, caídas de tensión o un segundo corte -- corre el riesgo de agravar el problema original y puede provocar más problemas de integridad de los datos.

2. **Los switches principales de la red están encendidos y completamente arrancados.** Los switches empresariales pueden tardar varios minutos en completar su proceso de arranque, de forma similar a un servidor. Si los nodos del clúster entran en línea antes de que la red esté lista, no podrán descubrir a sus pares, lo que puede causar problemas de reconciliación.
   {% endhint %}

3. Confirme **la energía aguas arriba** es estable. Levantar los nodos con una alimentación inestable supone el riesgo de un segundo corte en medio de la recuperación.

4. Confirme **los switches principales de la red** están en línea, **completamente arrancados**, y la infraestructura entre nodos está activa. vSAN no puede reformarse sin ella, y los switches avanzados pueden tardar varios minutos en terminar de arrancar.

5. Verifique **IPMI/BMC** acceso en cada nodo para que pueda supervisar el arranque de forma remota si es necesario.

6. Anote cualquier nodo con fallos de hardware visibles (PSU defectuosas, LED de discos, alarmas de ventiladores) -- estos pueden requerir atención antes de volver a incorporarlos.

### Secuencia de encendido

Una vez que se confirma que la energía y la infraestructura de red están listas:

1. **Encienda Node1.**
   * Observe la consola/IPMI. Node1 arrancará el sistema operativo pero **se detendrá antes de montar vSAN** hasta que se unan suficientes pares.
2. **Espere de 30 segundos a un minuto.**
   * Esta breve pausa permite que Node1 comience a inicializarse antes de que llegue el resto del clúster. No es necesario esperar a que Node1 alcance por completo su estado de detención antes de continuar.
3. **Encienda los nodos restantes.**
   * Los nodos restantes pueden encenderse juntos (o en rápida sucesión); no es necesario escalonarlos uno por uno.
   * vSAN se monta automáticamente en cuanto hay un número mínimo de nodos en línea (p. ej., todos menos un nodo en una configuración N+1 predeterminada).
4. **Entornos con varios clústeres:** ponga completamente en línea el clúster controlador antes de encender clústeres adicionales.

{% hint style="success" %}
**Consejo**

Node1 arranca primero y espera mientras enciende el resto del clúster -- eso es lo esperado, no un estado atascado. vSAN se monta por sí solo en cuanto hay suficientes pares en línea, y VergeOS gestiona la reconciliación automáticamente; no se necesitan comandos manuales de reparación.
{% endhint %}

### Verificación posterior a la recuperación

Una vez que todos los nodos estén en línea y el clúster haya tenido tiempo de estabilizarse, verifique que todo haya vuelto a un estado saludable. Debido a que el clúster se apagó de forma no controlada, realice estas comprobaciones con mayor escrutinio -- una pérdida brusca de energía puede dejar problemas que el clúster no puede resolver por completo por sí mismo. Busque cuidadosamente errores persistentes de vSAN, cargas de trabajo fallidas o en bucle de fallos, y cualquier error del sistema de archivos a nivel de invitado. Si se detecta corrupción irrecuperable, puede ser necesario revertir un volumen a una instantánea reciente.

1. **Confirme el estado general del sistema**

   La pérdida brusca de energía aumenta el riesgo de problemas de hardware. Es importante comprobar cualquier incidencia:

   * Revise los [Alarmas](/run-the-platform/operations/alarms.md) panel. Confirme que no se hayan activado nuevas alarmas.
   * Revise **registros del sistema (Panel principal)** para detectar errores durante el arranque o el montaje inicial.
2. **Verifique el estado de vSAN**
   * Abra el **Panel principal** -- todas las luces de estado deberían estar **Verdes**.
   * Vaya a **Sistema → vSAN → Niveles** y haga doble clic en cada nivel.
   * Revise los **Estado** mosaico en el panel de cada nivel. El artículo de KB [Entender los recorridos de estado/registro de nivel de vSAN](/run-the-platform/storage/vsan-diagnostics.md) proporciona una guía para leer los campos de estado de los niveles de vSAN.
3. **Verifique el estado de los discos**
   * Ve a **Sistema → vSAN → Discos**.
   * Busque cualquier disco que muestre errores, advertencias o alertas SMART -- esto puede ocurrir cuando los discos no vuelven de forma limpia después de una pérdida brusca de energía.
   * **Reemplace los discos defectuosos** con rapidez para mantener la protección de datos de vSAN.
4. **Verifique las cargas de trabajo**

   <div data-gb-custom-block data-tag="hint" data-style="success" class="hint hint-success"><p><strong>Comportamiento de inicio automático de las VM</strong></p><p>De forma predeterminada, las VM están configuradas para iniciarse automáticamente cuando se restablece la energía del clúster. Las VM con un <strong>En caso de pérdida de energía</strong> ajuste alternativo deberán encenderse manualmente.</p></div>

   * Verifique las VM críticas: consola respondiendo, SO invitado saludable, servicios de aplicación en funcionamiento. Los apagados no controlados pueden causar problemas dentro del SO invitado y de las aplicaciones instaladas -- esté atento a errores del sistema de archivos, servicios que no logran iniciarse y aplicaciones que se bloquean al arrancar.
   * Identifique posibles candidatas a reversión lo antes posible -- idealmente antes de que las aplicaciones vuelvan a un uso intensivo.

{% hint style="warning" %}
**Las decisiones de reversión a instantánea son sensibles al tiempo**

Si el sistema general o las VM individuales muestran signos de daño por el apagado no controlado que no pueden repararse en su lugar, restaurar desde una instantánea anterior al corte puede ser la única forma de volver a un estado saludable. **Esta determinación debe hacerse lo antes posible**, por dos razones:

* **La retención de instantáneas es finita.** Una instantánea viable anterior al corte puede caducar y dejar de estar disponible si pasa demasiado tiempo antes de tomar la decisión.
* **Se pierden datos más recientes al revertir.** Cuanto más tiempo permanezca la VM afectada en uso de producción después del corte, más trabajo legítimo posterior a la recuperación se descarta cuando se realiza la reversión.
  {% endhint %}

## Resolución de problemas

{% hint style="warning" %}
**Problemas comunes**

* **Problema:** Un nodo no logra reincorporarse al clúster.
  * **Solución:** Compruebe la salida de IPMI/consola en busca de errores de arranque. Verifique que la interfaz principal de red del nodo esté activa y sea accesible desde los pares. Revise **Sistema → Nodos → \[nodo]** para ver el estado y las marcas de tiempo de última detección. Si el nodo arranca pero no se une, no **no** lo elimine a la fuerza -- póngase en contacto con el soporte.
* **Problema:** vSAN no se monta / almacenamiento fuera de línea.
  * **Solución:** Confirme **Los nodos mínimos de vSAN están en línea** en **Sistema → Nodos** (p. ej., en una configuración predeterminada: 3 de 4 en un clúster de 4 nodos, 5 de 6 en un clúster de 6 nodos). Confirme la conectividad entre nodos (switches principales de la infraestructura, estado del enlace, MTU). Si se cumple el umbral pero el almacenamiento sigue sin montarse, capture un sysdiag y contacte con soporte.
* **Problema:** El conteo de reparaciones está atascado o creciendo.
  * **Solución:** Un conteo pequeño y decreciente **Reparaciones** es normal después de la recuperación. Un conteo que **deja de disminuir** o **aumenta** indica bloques que vSAN no puede reconstruir a partir de los pares. **No reinicie ningún nodo.** Póngase en contacto con soporte antes de tomar medidas de remediación.
* **Problema:** Se sospecha split-brain o un estado inconsistente del clúster.
  * **Solución:** Durante la recuperación, un problema de red puede hacer que dos subconjuntos de nodos arranquen sin poder verse entre sí. Si ve indicios de que se están formando dos clústeres independientes (raro, pero posible después de una restauración parcial de la red), **no intente fusionarlos usted mismo**. Capture sysdiags de cada nodo y contacte con soporte de inmediato.
    {% endhint %}

## Prevención/Mitigación

* **Dimensionamiento y cobertura del UPS/SAI** -- dimensione el UPS/SAI para cubrir la duración del apagado controlado más un margen para cada nodo. Incluya los switches principales de la red en la misma cobertura. Pruebe anualmente la autonomía del UPS/SAI -- las baterías se degradan.
* **Apagado controlado automatizado** -- Use software de gestión de UPS/SAI (NUT, scripting de IPMI o el agente de su proveedor de UPS/SAI en un host de gestión) para detectar un evento de batería baja y desencadenar un apagado controlado del clúster -- ya sea mediante la **Apagar** acción del Panel del clúster, la API de VergeOS (`POST /v4/cluster_actions` con el cuerpo `{"cluster": <cluster_id>, "action": "shutdown", "params": "{}"}`), o nuestra [**CLI VRG**](https://github.com/verge-io/vrg) envoltura, que puede automatizar la misma llamada de apagado desde un host Linux/macOS/Windows. Valide la automatización en una ventana de mantenimiento antes de confiar en ella.
* **Ajustes de VM "Al perder energía"** -- configure deliberadamente el comportamiento de cada VM para que el estado posterior a la recuperación sea predecible. Tres opciones:
  * ***Último estado*** -- la VM solo se enciende si estaba encendida en el momento de la pérdida de energía
  * ***Dejar apagada*** -- la VM permanece apagada cuando se restablece la energía, independientemente del estado previo
  * ***Encendido*** -- la VM se enciende cuando se restablece la energía, independientemente del estado previo
* **Servidor de reparación (ioGuardian)** -- un [servidor de reparación](/automate-protect-and-extend/backup-and-dr/repair-server.md) proporciona a VergeFS una fuente de respaldo para los bloques faltantes si los nodos pares no pueden suministrarlos después de un corte. Se construye a partir de una configuración de sincronización saliente de sitio existente y extrae los bloques necesarios de un sistema remoto de VergeOS sincronizado. Los servidores de reparación se recomiendan encarecidamente para cualquier despliegue de producción.
* **Rotación de instantáneas adecuada** -- mantenga un plan de retención de instantáneas que conserve disponibles instantáneas recientes previas al evento para poder revertir cuando sea necesario. También se recomienda replicar instantáneas a un sitio remoto como parte de una estrategia integral de protección de datos.

## Cuándo contactar con soporte

Abra un caso de soporte **antes de** reiniciar nodos o realizar cualquier otro cambio importante, si se cumple alguna de las siguientes condiciones:

* vSAN no se monta después de que N nodos estén en línea (p. ej., el número total de nodos menos uno en una redundancia N+1 predeterminada)
* Un nivel muestra **Redundante: false** durante un período prolongado después de que se completen los Full Walks
* El **Reparaciones** el conteo está atascado o creciendo
* Hay una alerta de reparaciones atascadas (VergeOS v26+)
* Varios discos informan errores después de la recuperación
* Sospecha split-brain o un estado inconsistente del clúster
* Algún nodo no logra reincorporarse y la causa no es obviamente de hardware

## Generación de un diagnóstico del sistema para soporte

Antes de abrir el caso, capture un sysdiag y adjúntelo (o envíelo directamente al soporte):

Consulte [Generación de diagnósticos del sistema](/knowledge-base/es/troubleshooting/generating-system-diagnostics.md) y la completa [Diagnósticos del sistema](/run-the-platform/system-administration/diagnostics.md) referencia.

## Recursos adicionales

* [Secuencia correcta de encendido y apagado](/knowledge-base/es/system-administration/proper-power-sequence-for-vergeos.md)
* [Procedimiento correcto de apagado del sistema VergeOS](/knowledge-base/es/system-administration/proper-vergeos-system-shutdown-procedure.md)
* [Entender Journal Walks y el estado de los niveles de vSAN](/knowledge-base/es/storage-vsan/understanding-journal-walks-and-vsan-tier-status.md)
* [Generación de diagnósticos del sistema](/knowledge-base/es/troubleshooting/generating-system-diagnostics.md)
* [Servidor de reparación (ioGuardian)](/automate-protect-and-extend/backup-and-dr/repair-server.md)
* [Guía de diagnóstico de vSAN](/run-the-platform/storage/vsan-diagnostics.md)

## Comentarios

{% hint style="info" %}
**¿Necesitas ayuda?**

Si necesita más ayuda o tiene alguna pregunta sobre este artículo, no dude en ponerse en contacto con nuestro equipo de soporte.
{% endhint %}

***

{% hint style="info" %}
**Información del documento**

* Última actualización: 2026-05-08
* Versión de vergeOS: 26.0+
  {% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.verge.io/knowledge-base/es/system-administration/cluster-recovery-after-power-outage.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.