> 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/fr/system-administration/cluster-recovery-after-power-outage.md).

# Récupération du cluster après une panne de courant totale

## Vue d’ensemble

{% hint style="info" %}
**Points clés**

* Les arrêts brutaux doivent être évités dans la mesure du possible, en particulier sur les systèmes de production.
* Ce guide fournit des bonnes pratiques — afin d’atténuer les problèmes potentiels — pour remettre le cluster sous tension après un arrêt inattendu.
* Mettez sous tension **Node1** d’abord. Attendez 30 secondes à une minute, puis mettez sous tension les nœuds restants du cluster.
* Un nombre non nul **Réparations** après la récupération est normal ; il devrait diminuer à mesure que les parcours du journal se terminent.
* Faites appel au support VergeIO si le nombre de réparations ne revient pas à zéro à la fin du parcours du journal ou si d’autres anomalies persistent.
  {% endhint %}

## Portée

Ce guide couvre la remise sous tension d’un cluster VergeOS après un **arrêt non gracieux** — lorsque le cluster a perdu l’alimentation brutalement à cause d’une panne de courant, de l’épuisement de l’onduleur, d’une défaillance du site ou d’un événement similaire. Pour les procédures planifiées et contrôlées d’arrêt et de remise sous tension, voir [Procédure correcte d'arrêt du système VergeOS](/knowledge-base/fr/system-administration/proper-vergeos-system-shutdown-procedure.md) et [Séquence d'alimentation correcte](/knowledge-base/fr/system-administration/proper-power-sequence-for-vergeos.md).

{% hint style="warning" %}
**Éviter autant que possible les arrêts brutaux**

* Bien que VergeOS inclue plusieurs protections intégrées pour préserver l’intégrité des données, aucun système de stockage distribué ne peut garantir totalement l’absence de corruption lorsque des nœuds perdent l’alimentation brutalement et simultanément.
* Les écritures en cours au moment de la perte d’alimentation peuvent être incomplètes ou incohérentes entre les pairs, et dans certains cas, le seul moyen de rétablir l’intégrité consiste à restaurer un volume à partir d’un instantané récent.
* De plus, des problèmes matériels, du système d’exploitation invité et des applications sont fréquents après des arrêts brutaux.
* Une infrastructure d’alimentation appropriée — couverture UPS dimensionnée pour un arrêt gracieux, alimentations redondantes et arrêt automatisé sur batterie faible — est la protection la plus efficace ; voir la [Prévention](#preventionmitigation) section pour plus d’informations.
* Lorsqu’un arrêt brutal se produit malgré ces précautions, la procédure ci-dessous est conçue pour remettre le cluster en ligne en toute sécurité et faire ressortir tout problème d’intégrité nécessitant une intervention.
  {% endhint %}

## Prérequis

* Accès physique ou IPMI/BMC à chaque nœud
* Connaissance du nœud qui est **Node1** (Node1 devra être démarré en premier.)
* Confirmation que l’alimentation en amont, le réseau (commutateurs du cœur du fabric) et l’IPMI sont rétablis et stables
* Un instantané local récent ou répliqué à distance en cas de problèmes d’intégrité détectés
* Familiarité avec le [tableau de bord de niveau vSAN / parcours du journal](/knowledge-base/fr/storage-vsan/understanding-journal-walks-and-vsan-tier-status.md)

## Étapes

### À quoi s’attendre

* VergeFS inclut plusieurs protections intégrées pour aider à préserver l’intégrité des données lors d’événements liés à l’alimentation — notamment le journal d’écriture, la réplication entre pairs, les serveurs de réparation (ioGuardian) et la vérification au démarrage. Au démarrage du contrôleur, VergeFS déclenche un **parcours complet du journal** pour vérifier chaque bloc et le réconcilier avec les pairs. Ces protections sont efficaces dans la plupart des cas, mais aucun système de stockage distribué ne peut garantir totalement l’absence de corruption après une perte d’alimentation brutale ; la vérification après le démarrage est importante, en particulier après un arrêt non gracieux.
* vSAN nécessite **Nombre minimal de nœuds** en ligne avant de pouvoir être monté (par exemple, dans un cluster à 4 nœuds avec protection N+1, le vSAN se monte tant que 3 nœuds sont en ligne). Tant que ce seuil n’est pas atteint, le stockage reste hors ligne et les VM ne démarrent pas.
* Node1 démarrera, mais s’arrêtera avant de monter le vSAN jusqu’à ce qu’assez de pairs rejoignent le cluster.
* Un nombre non nul **Réparations** après la récupération est normal et devrait diminuer à mesure que le parcours progresse.

### Vérifications avant la mise sous tension

{% hint style="warning" %}
**Vérifier d’abord que l’infrastructure est prête**

Avant de mettre sous tension un quelconque nœud du cluster, confirmez que deux conditions critiques sont réunies. Elles sont abordées dans les prérequis, mais il est utile de les rappeler ici — les ignorer peut causer des dommages bien plus importants que l’arrêt initial :

1. **L’alimentation du site est entièrement rétablie et stable.** Remettre le cluster en service pendant une instabilité électrique persistante — variations, baisses de tension ou seconde panne — risque d’aggraver le problème initial et peut entraîner d’autres problèmes d’intégrité des données.

2. **Les commutateurs réseau principaux sont sous tension et complètement démarrés.** Les commutateurs d’entreprise peuvent mettre plusieurs minutes à terminer leur démarrage, comme un serveur. Si les nœuds du cluster se mettent en ligne avant que le réseau soit prêt, ils ne pourront pas détecter leurs pairs, ce qui peut provoquer des problèmes de réconciliation.
   {% endhint %}

3. Confirmez **l’alimentation en amont** est stable. Mettre les nœuds sous tension sur une alimentation instable risque une seconde panne en pleine récupération.

4. Confirmez **les commutateurs réseau principaux** sont en ligne, **complètement démarrés**et que le fabric inter-nœuds est opérationnel. vSAN ne peut pas se reconstituer sans cela, et les commutateurs avancés peuvent mettre plusieurs minutes à finir leur démarrage.

5. Vérifiez **IPMI/BMC** l’accès sur chaque nœud afin de pouvoir surveiller le démarrage à distance si nécessaire.

6. Notez tout nœud présentant des défauts matériels visibles (alimentation défaillante, voyants de disque, alarmes des ventilateurs) — ceux-ci peuvent nécessiter une intervention avant d’être réintégrés.

### Séquence de mise sous tension

Une fois l’alimentation et l’infrastructure réseau confirmées prêtes :

1. **Mettez Node1 sous tension.**
   * Surveillez la console/IPMI. Node1 démarrera l’OS, mais **s’arrêtera avant de monter le vSAN** jusqu’à ce qu’assez de pairs rejoignent le cluster.
2. **Attendez 30 secondes à une minute.**
   * Cette courte pause permet à Node1 de commencer son initialisation avant l’arrivée du reste du cluster. Il n’est pas nécessaire d’attendre que Node1 atteigne complètement son état d’arrêt avant de poursuivre.
3. **Mettez sous tension les nœuds restants.**
   * Les nœuds restants peuvent être mis sous tension ensemble (ou à très courte succession) ; il n’est pas nécessaire de les démarrer un par un.
   * Le vSAN se monte automatiquement dès qu’un nombre minimal de nœuds est en ligne (par exemple, tous sauf un nœud dans une configuration N+1 par défaut).
4. **Environnements multi-clusters :** mettez entièrement en ligne le cluster contrôleur avant de mettre sous tension des clusters supplémentaires.

{% hint style="success" %}
**Conseil pro**

Node1 démarre en premier et attend pendant que vous mettez le reste du cluster sous tension — c’est normal, ce n’est pas un blocage. Le vSAN se monte tout seul dès qu’assez de pairs sont en ligne, et VergeOS gère automatiquement la réconciliation ; aucune commande de réparation manuelle n’est nécessaire.
{% endhint %}

### Vérification après récupération

Une fois que tous les nœuds sont en ligne et que le cluster a eu le temps de se stabiliser, vérifiez que tout est revenu à un état sain. Comme le cluster a été arrêté brutalement, effectuez ces vérifications avec une vigilance accrue — une perte d’alimentation brutale peut laisser des problèmes que le cluster ne peut pas entièrement résoudre seul. Recherchez attentivement des erreurs vSAN persistantes, des charges de travail en échec ou en boucle de crash, et toute erreur de système de fichiers au niveau invité. Si une corruption irrémédiable est détectée, il peut être nécessaire de restaurer un volume à partir d’un instantané récent.

1. **Confirmer l’état de santé global du système**

   Une perte d’alimentation brutale augmente le risque de problèmes matériels. Il est important de vérifier toute anomalie :

   * Consultez les [Alarmes](/run-the-platform/operations/alarms.md) tableau de bord. Confirmez qu’aucune nouvelle alarme n’a été déclenchée.
   * Consultez les **journaux système (tableau de bord principal)** pour détecter des erreurs pendant le démarrage ou le montage initial.
2. **Vérifier l’état de santé du vSAN**
   * Ouvrez le **tableau de bord principal** — tous les voyants d’état doivent être **verts**.
   * Accédez à **Système → vSAN → Niveaux** et double-cliquez sur chaque niveau.
   * Consultez les **tuile** sur le tableau de bord de chaque niveau. L’article de base de connaissances [Comprendre les états des niveaux vSAN / les parcours du journal](/run-the-platform/storage/vsan-diagnostics.md) fournit un guide pour lire les champs d’état des niveaux vSAN.
3. **Vérifier l’état des disques**
   * Accédez à **Système → vSAN → Disques**.
   * Recherchez tout disque affichant des erreurs, des avertissements ou des alertes SMART — cela peut se produire lorsque les disques ne reviennent pas proprement après une perte d’alimentation brutale.
   * **Remplacez les disques défectueux** rapidement afin de maintenir la protection des données vSAN.
4. **Vérifier les charges de travail**

   <div data-gb-custom-block data-tag="hint" data-style="success" class="hint hint-success"><p><strong>Comportement de démarrage automatique des VM</strong></p><p>Par défaut, les VM sont configurées pour démarrer automatiquement lorsque l’alimentation est rétablie sur le cluster. Les VM avec un <strong>En cas de perte d'alimentation</strong> paramètre différent devront être démarrées manuellement.</p></div>

   * Vérifiez les VM critiques : console réactive, système d’exploitation invité sain, services applicatifs opérationnels. Les arrêts brutaux peuvent provoquer des problèmes dans le système d’exploitation invité et les applications installées — surveillez les erreurs de système de fichiers, les services qui ne démarrent pas et les applications qui plantent au lancement.
   * Identifiez le plus tôt possible les candidats potentiels à une restauration — idéalement avant que les applications ne reprennent une utilisation intensive.

{% hint style="warning" %}
**Les décisions de restauration d’instantané sont sensibles au facteur temps**

Si le système global ou des VM individuelles montrent des signes de dommages dus à l’arrêt brutal qui ne peuvent pas être réparés en place, la restauration à partir d’un instantané pré-panne peut être le seul moyen de revenir à un état sain. **Cette décision doit être prise aussi rapidement que possible**, pour deux raisons :

* **La rétention des instantanés est limitée.** Un instantané pré-panne exploitable peut expirer et devenir indisponible si trop de temps s’écoule avant la prise de décision.
* **Les données plus récentes sont perdues lors de la restauration.** Plus la VM affectée reste en production après l’incident, plus le travail légitime effectué après la récupération est perdu lors de la restauration.
  {% endhint %}

## Dépannage

{% hint style="warning" %}
**Problèmes courants**

* **Problème :** Un nœud ne parvient pas à rejoindre le cluster.
  * **Solution :** Vérifiez la sortie IPMI/console pour détecter des erreurs de démarrage. Vérifiez que l’interface réseau principale du nœud est opérationnelle et joignable depuis les pairs. Consultez **Système → Nœuds → \[nœud]** pour l’état et les horodatages de dernière détection. Si le nœud démarre mais ne rejoint pas le cluster, ne **pas** le retirez pas de force — contactez le support.
* **Problème :** vSAN ne se monte pas / stockage hors ligne.
  * **Solution :** Confirmez **Le nombre minimal de nœuds vSAN est en ligne** sous **Système → Nœuds** (par exemple, dans une configuration par défaut : 3 sur 4 dans un cluster à 4 nœuds, 5 sur 6 dans un cluster à 6 nœuds). Confirmez la connectivité inter-nœuds (commutateurs du fabric principal, état des liens, MTU). Si le seuil est atteint mais que le stockage ne se monte toujours pas, capturez un sysdiag et contactez le support.
* **Problème :** Le nombre de réparations est bloqué ou augmente.
  * **Solution :** Un faible nombre, en diminution **Réparations** est normal après la récupération. Un nombre qui **cesse de diminuer** ou **augmente** indique des blocs que le vSAN ne peut pas reconstruire à partir des pairs. **Ne redémarrez aucun nœud.** Faites appel au support avant de prendre des mesures correctives.
* **Problème :** Suspicion de split-brain ou d’état de cluster incohérent.
  * **Solution :** Pendant la récupération, un problème réseau peut faire démarrer deux sous-ensembles de nœuds incapables de se voir. Si vous voyez des signes de formation de deux clusters indépendants (rare, mais possible après une restauration partielle du réseau), **n’essayez pas de les fusionner vous-même**. Capturez des sysdiags sur chaque nœud et contactez immédiatement le support.
    {% endhint %}

## Prévention/atténuation

* **Dimensionnement et couverture de l’UPS** — dimensionnez l’UPS pour couvrir la durée d’un arrêt gracieux avec une marge pour chaque nœud. Incluez les commutateurs réseau principaux dans la même couverture. Testez chaque année l’autonomie de l’UPS — les batteries se dégradent.
* **Arrêt gracieux automatisé** — Utilisez le logiciel de gestion de l’UPS (NUT, scripts IPMI ou l’agent de votre fournisseur d’UPS sur un hôte de gestion) pour détecter un événement de batterie faible et déclencher un arrêt gracieux du cluster — soit via l’action **Mettre hors tension** du tableau de bord du cluster, l’API VergeOS (`POST /v4/cluster_actions` avec le corps `{"cluster": <cluster_id>, "action": "shutdown", "params": "{}"}`), ou notre [**VRG CLI**](https://github.com/verge-io/vrg) wrapper, qui peut automatiser le même appel d’arrêt depuis un hôte Linux/macOS/Windows. Validez l’automatisation dans une fenêtre de maintenance avant de vous y fier.
* **Paramètres « En cas de perte d’alimentation » des VM** — configurez délibérément le comportement de chaque VM afin que l’état après récupération soit prévisible. Trois options :
  * ***Dernier état*** — la VM ne démarre que si elle était allumée au moment de la perte d’alimentation
  * ***Laisser éteint*** — la VM reste éteinte lorsque l’alimentation est rétablie, quel que soit son état précédent
  * ***Mise sous tension*** — la VM démarre lorsque l’alimentation est rétablie, quel que soit son état précédent
* **Serveur de réparation (ioGuardian)** — un [serveur de réparation](/automate-protect-and-extend/backup-and-dr/repair-server.md) fournit à VergeFS une source de repli pour les blocs manquants si les nœuds pairs ne peuvent pas les fournir après une panne. Il est construit à partir d’une configuration de synchronisation sortante de site existante et récupère les blocs nécessaires depuis un système VergeOS distant synchronisé. Les serveurs de réparation sont fortement recommandés pour tout déploiement de production.
* **Rotation adéquate des instantanés** — conservez une politique de rétention des instantanés qui garde disponibles des instantanés récents, antérieurs à l’événement, pour une restauration en cas de besoin. La réplication des instantanés vers un site distant est également recommandée dans le cadre d’une stratégie complète de protection des données.

## Quand contacter le support

Ouvrez un ticket de support **avant** de redémarrer des nœuds ou d’effectuer tout autre changement important, si l’une des conditions suivantes est vraie :

* vSAN ne se monte pas après la mise en ligne de N nœuds (par exemple, le nombre total de nœuds moins un dans une redondance N+1 par défaut)
* Un niveau affiche **Redondant : faux** pendant une période prolongée après la fin des parcours complets
* Le **Réparations** le nombre est bloqué ou augmente
* Une alerte de réparations bloquées est présente (VergeOS v26+)
* Plusieurs disques signalent des erreurs après la récupération
* Vous suspectez un split-brain ou un état de cluster incohérent
* Un nœud ne parvient pas à rejoindre à nouveau le cluster et la cause n’est pas manifestement matérielle

## Générer un diagnostic système pour le support

Avant d’ouvrir le ticket, capturez un sysdiag et joignez-le (ou envoyez-le directement au support) :

Voir [Génération des diagnostics système](/knowledge-base/fr/troubleshooting/generating-system-diagnostics.md) et la référence complète [Diagnostics système](/run-the-platform/system-administration/diagnostics.md) .

## Ressources supplémentaires

* [Séquence d'alimentation correcte](/knowledge-base/fr/system-administration/proper-power-sequence-for-vergeos.md)
* [Procédure correcte d'arrêt du système VergeOS](/knowledge-base/fr/system-administration/proper-vergeos-system-shutdown-procedure.md)
* [Comprendre les parcours du journal et l’état des niveaux vSAN](/knowledge-base/fr/storage-vsan/understanding-journal-walks-and-vsan-tier-status.md)
* [Génération des diagnostics système](/knowledge-base/fr/troubleshooting/generating-system-diagnostics.md)
* [Serveur de réparation (ioGuardian)](/automate-protect-and-extend/backup-and-dr/repair-server.md)
* [Guide de diagnostic vSAN](/run-the-platform/storage/vsan-diagnostics.md)

## Retour

{% hint style="info" %}
**Besoin d’aide ?**

Si vous avez besoin d’une aide supplémentaire ou si vous avez des questions sur cet article, n’hésitez pas à contacter notre équipe de support.
{% endhint %}

***

{% hint style="info" %}
**Informations sur le document**

* Dernière mise à jour : 2026-05-08
* Version 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/fr/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.