> 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/storage-vsan/understanding-and-explaining-unexpected-vsan-growth.md).

# Comprendre et expliquer la croissance inattendue de vSAN

Guide de dépannage pour diagnostiquer une croissance inattendue du stockage vSAN, notamment comment consulter l’historique des niveaux et identifier les causes courantes comme les instantanés, les sauvegardes et le stockage des locataires.

Il existe plusieurs raisons pour lesquelles le vSAN peut commencer à croître à un rythme plus rapide que prévu. Les administrateurs doivent d’abord déterminer quand la croissance inexpliquée s’est produite en examinant l’historique de croissance des niveaux vSAN, puis évaluer les zones potentielles de croissance inattendue.

## Examiner l’historique de croissance des niveaux vSAN

Pour isoler une croissance inexpliquée, il est important de préciser à quel moment la croissance s’est accélérée de façon exponentielle. En suivant les étapes ci-dessous, les administrateurs peuvent examiner la croissance du stockage et visualiser la croissance normale liée aux opérations quotidiennes par rapport aux pics de croissance, qui sont généralement inattendus.

1. Accédez à **Infrastructure** > **Niveaux vSAN** depuis le menu supérieur. Si les niveaux vSAN ne sont pas présents, alors cet environnement est un locataire d’un système parent, et le niveau vSAN doit être examiné au niveau du système parent.
2. Ouvrez le niveau vSAN présentant une croissance inattendue (par exemple, niveau vSAN 0).
3. Dans le menu de navigation de gauche, cliquez sur **Historique**.
4. Un nouveau menu apparaîtra affichant l’historique sous différents graphiques. Modifiez la période de filtre afin d’isoler toute croissance sur ce niveau.
   * Il est recommandé de commencer avec un filtre personnalisé d’1 jour et d’examiner le **Utilisation du stockage** graphique.

### Points à noter :

* Si vous observez des baisses et des pics toutes les heures ou une fois par jour, il s’agit probablement du résultat de snapshots sortant de la rétention (les anciens expirent, de nouveaux sont créés). Vérifiez si le stockage total consommé au début de la journée est presque équivalent à celui de la fin de la journée. Si oui, étendez le filtre personnalisé à une semaine.
* Lors de l’examen par semaine, vérifiez si le stockage total consommé au début de la semaine est similaire à celui de la fin. Si, par exemple, la croissance est d’environ 10 %, recommencez pour la semaine précédente. Si le pourcentage de croissance hebdomadaire est cohérent, cela représente votre taux moyen de croissance hebdomadaire, ce qui peut aider à planifier une extension matérielle.
* Filtrez le mois en cours et vérifiez s’il existe des pics soudains de consommation de stockage sur le **Utilisation du stockage** graphique. Cliquez et faites glisser sur la période concernée pour zoomer sur les données, puis survolez le graphique pour obtenir des informations précises sur la date et l’heure.

![vsan\_unexpected\_growth.png](https://2698935919-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQZBMFpokMv2vWTIRbFzA%2Fuploads%2Fgit-blob-217505e650e1d66261f4c837c8106256938aa1c6%2Fvsan_unexpected_growth.png?alt=media)

## Causes possibles de l’augmentation du stockage

Plusieurs zones de la plateforme VergeOS peuvent contribuer à une croissance inattendue du stockage. Les zones courantes à vérifier comprennent :

* **Snapshots système**:
  * Accédez à **Système > Snapshots système**.
  * Certains sont-ils conservés au-delà de leur date d’expiration prévue ?
  * Y a-t-il des snapshots sans profil de snapshot ? Ils ont peut-être été pris manuellement. Vérifiez quand et pourquoi ils ont été pris.
  * Certains snapshots sont-ils définis sur « Jamais expirer » ? Cela peut entraîner une forte consommation de données au fil du temps.
* **Snapshots des machines virtuelles (VM)**:
  * Accédez au **Tableau de bord des machines**. Le **Snapshots** La case de comptage affiche le nombre de snapshots au niveau des machines présents. Cliquez sur cette case pour lister tous les snapshots de VM et leur date/heure de création. Vérifiez si certains peuvent être supprimés.
  * Accédez à **Machines virtuelles > Liste**. Triez par la **Profil de snapshot** colonne pour identifier les VM avec des snapshots au niveau des machines. Les machines virtuelles peuvent être restaurées à partir de snapshots système ; vérifiez donc si des snapshots individuels sont nécessaires ou s’ils peuvent être supprimés.
* **Tâches de sauvegarde VMware**:
  * Accédez à **Backup/DR > Services VMware** et examinez l’historique des tâches de sauvegarde pour chaque instance de service VMware.
  * Dans le menu de gauche, cliquez sur **Tâches de sauvegarde** pour examiner chaque instance spécifique. Vérifiez la **Expire** colonne pour chaque sauvegarde et vérifiez si elle peut être supprimée.
* **Fichiers**:
  * Accédez à **Fichiers** et triez par **Modifié**. Vérifiez si des dates/heures de téléversement correspondent à la période de croissance inexpliquée.
  * Vérifiez si des fichiers, en particulier d’autres formats d’hyperviseur (par ex. .ova ou .vhdx), peuvent être supprimés.
* **Synchronisations entrantes du site**:
  * Accédez à **Backup/DR > Synchronisations entrantes**. Ouvrez le tableau de bord de chaque synchronisation entrante et vérifiez le **Snapshots reçus** compteur. Examinez le site source (d’origine) pour une augmentation du stockage correspondant à cette période.
* **Stockage du locataire**:
  * Accédez à **Locataires > Tableau de bord de chaque locataire**.
  * Examiner **Stockage total utilisé** en cliquant sur **Historique** dans le menu de gauche. Suivez le même processus décrit ci-dessus pour examiner l’historique de croissance.
  * Si une croissance inattendue est constatée, recherchez dans le locataire les causes possibles de l’augmentation du stockage (comme indiqué ci-dessus), ainsi que dans les sous-locataires, le cas échéant.

## Stockage utilisé du niveau vs somme des disques des machines

La métrique de stockage total utilisé d’un niveau vSAN sera généralement supérieure à la somme de l’espace utilisé indiqué pour chacun de ses machine\_drives individuels. Cet écart se produit parce que la capacité utilisée déclarée de chaque disque de machine ne reflète que les blocs actifs actuellement référencés sur ces disques. En revanche, l’utilisation totale du niveau prend en compte tous les blocs de données sous-jacents sur l’ensemble de la plateforme, notamment :

* **Snapshots :** Blocs conservés uniquement pour préserver des états historiques à un instant donné.
* **Services VMware :** Données conservées par les instances de sauvegarde VMware.
* **Fichiers :** Stockage de système de fichiers partagé, médias téléversés ou images d’hyperviseur (par ex. .ova, .vhdx).
* **Modèles IA :** Fichiers de modèle localisés et poids résidant sur le niveau.

### Rétention des snapshots

Lorsque les autres consommateurs (services VMware, modèles IA et fichiers) ont été écartés, la rétention des snapshots est presque toujours le principal facteur de l’utilisation inattendue du niveau. Comme les snapshots conservent les blocs modifiés ou supprimés qui ne sont plus référencés par les disques de machine actifs, des planifications de snapshots agressives ou des politiques de rétention longues peuvent augmenter considérablement la consommation du niveau.

{% hint style="warning" %}
**Faites preuve de prudence avant de supprimer des snapshots système** Avant de supprimer manuellement des snapshots système pour récupérer du stockage local, vérifiez si des snapshots en attente sont mis en file d’attente ou se synchronisent activement hors site vers une cible de reprise après sinistre :

* Si la synchronisation hors site est essentielle : vérifiez que le snapshot a terminé sa synchronisation vers la cible distante avant de le supprimer localement. La suppression d’un snapshot en cours de synchronisation interrompra le transfert ; le snapshot n’est pas rendu disponible sur le site distant tant que sa synchronisation complète n’est pas terminée.
* Si le stockage local est à un niveau critique : la récupération immédiate de capacité peut primer sur les tâches de synchronisation en attente afin de maintenir les charges de travail en fonctionnement. Évaluez la marge de capacité actuelle de votre niveau local par rapport aux exigences de reprise hors site avant d’effectuer une suppression en masse.
  {% 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/storage-vsan/understanding-and-explaining-unexpected-vsan-growth.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.