> For the complete documentation index, see [llms.txt](https://academy.cegedim.cloud/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://academy.cegedim.cloud/francais/bases-de-donnees/opensearch/opensearch-architecture/opensearch-sauvegarde-s3.md).

# OpenSearch - Sauvegarde S3

## Vue d'ensemble

### Dispositif antérieur

La protection des données hébergées sur un cluster OpenSearch s'appuyait jusqu'à présent sur deux dispositifs distincts, dont la portée et les modalités d'administration diffèrent sensiblement :

* **La sauvegarde de la machine virtuelle**, intégralement administrée par cegedim.cloud, protégeait à la fois la machine virtuelle du cluster et les données qu'elle héberge, indices compris. Sa granularité de restauration demeurait toutefois celle de la machine virtuelle dans son ensemble : il n'était pas possible d'en restaurer un seul indice indépendamment du reste.
* **Un repository de sauvegarde S3 propre au client** (dit « repository client »), qu'un client pouvait déjà déployer et administrer de manière autonome au sein d'OpenSearch, avec ses propres identifiants S3, indépendamment de cegedim.cloud. Ce dispositif demeure inchangé : les clients l'ayant déjà mis en œuvre, ou souhaitant le faire, conservent l'entière responsabilité de sa configuration et de son exploitation.

### Évolution apportée

cegedim.cloud met désormais à disposition un repository de sauvegarde S3 supplémentaire, dénommé **repository admin**, intégralement administré par cegedim.cloud sur l'ensemble des clusters. Cette évolution s'accompagne d'une redéfinition du périmètre de la sauvegarde de la machine virtuelle : celle-ci est désormais limitée au seul système (binaires, disques), à l'exclusion des données OpenSearch, dont la protection est intégralement reprise par le repository admin.

|                               | Sauvegarde de la machine virtuelle (périmètre redéfini)                     | Repository client S3 (existant, optionnel)       | Repository admin S3 (nouveau)                                                                        |
| ----------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------ | ---------------------------------------------------------------------------------------------------- |
| Administration                | cegedim.cloud                                                               | Le client                                        | cegedim.cloud                                                                                        |
| Périmètre sauvegardé          | La machine virtuelle : système, binaires, disques (hors données OpenSearch) | Les indices que le client choisit de sauvegarder | L'ensemble des indices, de manière automatique                                                       |
| Granularité de restauration   | La machine virtuelle, en bloc                                               | Selon la configuration retenue par le client     | Un indice précis, à une date précise                                                                 |
| Délai de restauration typique | Plusieurs heures                                                            | Selon la configuration retenue par le client     | Quelques minutes                                                                                     |
| Cas d'usage privilégié        | Perte totale d'une machine virtuelle, sinistre infrastructure               | Besoin de sauvegarde spécifique au client        | Indice corrompu, supprimé ou affecté par une migration incorrecte, sans démarche préalable du client |

Antérieurement, la sauvegarde de la machine virtuelle couvrait à la fois le système et les données OpenSearch ; la récupération d'un indice supposait néanmoins la restauration intégrale de l'ensemble des machines virtuelles du cluster, suivie de leur reconfiguration, pour n'en extraire finalement qu'un seul indice. Le repository admin répond précisément à cette limitation : la protection des données est désormais assurée à un niveau applicatif, permettant une restauration fine, sans qu'aucune démarche ne soit requise du client.

Les trois dispositifs demeurent complémentaires, chacun sur un périmètre désormais clairement délimité : le système pour la sauvegarde de la machine virtuelle, les données pour le repository admin, avec la possibilité pour le client de maintenir en parallèle son propre repository. La suite du présent document est consacrée au fonctionnement du **repository admin**.

## Principe de fonctionnement

* Chaque nuit, OpenSearch procède à un **instantané** (« snapshot ») de l'ensemble de ses indices et le transmet vers un espace de stockage S3 dédié.
* Cet instantané est **incrémental** : seules les données modifiées depuis la veille sont transférées, ce qui exclut tout impact perceptible sur les performances du cluster.
* Les instantanés sont conservés pendant une durée déterminée, puis supprimés automatiquement, sauf lorsque l'indice qu'ils contiennent demeure présent dans le cluster, auquel cas leur conservation est prolongée.

## Fréquence et durée de conservation

| Environnement | Fréquence              | Durée de conservation |
| ------------- | ---------------------- | --------------------- |
| Production    | Quotidienne (nocturne) | 14 jours              |
| QA / Recette  | Quotidienne (nocturne) | 7 jours               |

Lors de la suppression d'un cluster, les instantanés associés ne sont pas supprimés immédiatement : ils demeurent disponibles durant une période de grâce, permettant le cas échéant la récupération d'une donnée postérieurement à la suppression.

## Sécurité et accès

Le tableau suivant porte sur le repository admin. Les clients administrant par ailleurs leur propre repository client conservent l'entière responsabilité de leurs identifiants S3, comme c'était déjà le cas antérieurement.

|                                       | Administré par cegedim.cloud | Accessible au client | Commentaires                                            |
| ------------------------------------- | :--------------------------: | :------------------: | ------------------------------------------------------- |
| Stockage des instantanés              |               ✅              |                      | Sur l'infrastructure de stockage objet de cegedim.cloud |
| Identifiants d'accès au repository S3 |               ✅              |                      | Ne sont à aucun moment communiqués au client            |
| Déclenchement d'une restauration      |               ✅              |                      | Exécuté par le support, sur demande via ticket          |
| Suppression des instantanés expirés   |               ✅              |                      | Purge automatique, sans démarche requise                |

## Demander une restauration

La restauration d'un indice s'effectue sur requête, via le canal de support habituel (ticket ITCare / ServiceDesk). Il convient de préciser :

1. Le nom du cluster concerné.
2. Le ou les indices à restaurer.
3. La date de référence souhaitée (par exemple : « l'état de l'indice au matin du 4 juin 2026 »).
4. Le mode de restauration retenu :
   * **Restauration parallèle** *(recommandée)* : l'indice est restauré sous un nouveau nom (par exemple `restored_<indice>`), sans affecter l'indice actuel, ce qui permet une comparaison préalable à toute bascule.
   * **Restauration en remplacement** : l'indice actuel est remplacé par la version restaurée ; cette option requiert la fermeture ou la suppression préalable de l'indice actuel, à valider avec l'équipe applicative concernée.

Une fois initiée, la restauration d'un indice de taille standard s'effectue généralement en quelques minutes.

## Questions fréquentes

**Le client peut-il consulter lui-même les instantanés disponibles pour son cluster ?** Oui. Le client disposant du compte administrateur de son cluster OpenSearch, il peut interroger directement l'API OpenSearch (par exemple `GET /_snapshot/<repository>/_all`) pour consulter la liste des instantanés disponibles, sans passer par le support.

**Le client peut-il restaurer un indice lui-même, via l'API OpenSearch ?** Non. Les identifiants d'accès au repository de sauvegarde ne sont pas communiqués aux équipes utilisatrices. Toute restauration s'effectue par l'intermédiaire d'une demande adressée au support.

**Ce dispositif se substitue-t-il à la sauvegarde de la machine virtuelle ?** Non, mais leurs périmètres respectifs ont été redéfinis. La sauvegarde de la machine virtuelle protège désormais exclusivement le système (binaires, disques), contre une perte totale de celui-ci ; la protection des données OpenSearch est intégralement reprise par le repository admin, qui permet une restauration fine, indice par indice, indépendamment de toute restauration de machine virtuelle.

**Un indice créé puis supprimé au cours de la même journée sera-t-il sauvegardé ?** Uniquement s'il existait au moment de l'instantané quotidien nocturne. Une création suivie d'une suppression au cours de la même journée peut ne laisser aucune trace exploitable.

**Une fréquence de sauvegarde supérieure à la fréquence quotidienne peut-elle être demandée ?** La fréquence quotidienne du repository admin constitue l'offre standard et n'est pas modifiable à la demande. Le client conserve néanmoins l'entière liberté de déployer et d'administrer son propre repository client (cf. « Vue d'ensemble »), avec la fréquence de son choix, si son besoin métier exige une cadence de sauvegarde différente.

**Que se passe-t-il en cas de suppression d'un cluster, si une donnée doit être récupérée ultérieurement ?** Les instantanés demeurent disponibles durant une période de grâce postérieure à la suppression. Il est recommandé de prévenir le support avant la suppression du cluster si un tel besoin est anticipé.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://academy.cegedim.cloud/francais/bases-de-donnees/opensearch/opensearch-architecture/opensearch-sauvegarde-s3.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.