> 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/databases/opensearch/opensearch-features/opensearch-backup-s3.md).

# OpenSearch - S3 backup

## Overview

### Previous arrangement

Until now, the protection of data hosted on an OpenSearch cluster relied on two distinct mechanisms, whose scope and administration differ significantly:

* **A virtual machine backup**, fully administered by cegedim.cloud, protected both the cluster's virtual machine and the data it hosted, indices included. Its restore granularity, however, remained that of the virtual machine as a whole: it was not possible to restore a single index independently of the rest.
* **A client-owned S3 backup repository** (referred to as the "client repository"), which a client could already deploy and administer autonomously within OpenSearch, using its own S3 credentials, independently of cegedim.cloud. This mechanism remains unchanged: clients who have already implemented it, or wish to do so, retain full responsibility for its configuration and operation.

### What's changing

cegedim.cloud is now making an additional S3 backup repository available, referred to as the **admin repository**, fully administered by cegedim.cloud across all clusters. This change comes together with a redefinition of the scope of the virtual machine backup: it is now limited to the operating system only (binaries, disks), excluding OpenSearch data, whose protection is now fully taken over by the admin repository.

|                      | Virtual machine backup (redefined scope)                                           | Client S3 repository (existing, optional) | Admin S3 repository (new)                                                                                                  |
| -------------------- | ---------------------------------------------------------------------------------- | ----------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| Administered by      | cegedim.cloud                                                                      | The client                                | cegedim.cloud                                                                                                              |
| Scope covered        | The virtual machine: operating system, binaries, disks (excluding OpenSearch data) | The indices the client chooses to back up | All indices, automatically                                                                                                 |
| Restore granularity  | The virtual machine, as a whole                                                    | Depending on the client's configuration   | A specific index, at a specific point in time                                                                              |
| Typical restore time | Several hours                                                                      | Depending on the client's configuration   | A few minutes                                                                                                              |
| Primary use case     | Total loss of a virtual machine, infrastructure disaster                           | A backup need specific to the client      | A corrupted or accidentally deleted index, or one affected by a faulty migration — with no action required from the client |

Previously, the virtual machine backup covered both the operating system and the OpenSearch data; recovering a single index nonetheless required restoring every virtual machine in the cluster in full, then reconfiguring them, only to extract a single index from them in the end. The admin repository addresses this limitation directly: data protection is now handled at the application level, enabling fine-grained restores with no action required from the client.

All three mechanisms remain complementary, each now with a clearly defined scope: the operating system for the virtual machine backup, data for the admin repository, with the option for clients to keep running their own repository in parallel. The remainder of this document covers how the **admin repository** works.

## How it works

* Every night, OpenSearch takes a **snapshot** of all its indices and sends it to a dedicated S3 storage location.
* This snapshot is **incremental**: only data changed since the previous day is transferred, ruling out any noticeable impact on cluster performance.
* Snapshots are kept for a defined period, then automatically deleted — unless the index they contain is still present in the cluster, in which case their retention is extended.

## Frequency and retention period

| Environment  | Frequency         | Retention period |
| ------------ | ----------------- | ---------------- |
| Production   | Daily (overnight) | 14 days          |
| QA / Staging | Daily (overnight) | 7 days           |

When a cluster is deleted, its associated snapshots are not removed immediately: they remain available for a grace period, allowing data to be recovered after the fact if needed.

## Security and access

The table below applies to the admin repository. Clients who also administer their own client repository retain full responsibility for their own S3 credentials, as was already the case previously.

|                                  | Administered by cegedim.cloud | Accessible to the client | Comments                                         |
| -------------------------------- | :---------------------------: | :----------------------: | ------------------------------------------------ |
| Snapshot storage                 |               ✅               |                          | On cegedim.cloud's object storage infrastructure |
| S3 repository access credentials |               ✅               |                          | Never shared with the client                     |
| Triggering a restore             |               ✅               |                          | Performed by support, upon request via ticket    |
| Deletion of expired snapshots    |               ✅               |                          | Automatic purge, no action required              |

## Requesting a restore

Restoring an index is handled on request, through the usual support channel (ITCare / ServiceDesk ticket). Please specify:

1. The name of the cluster concerned.
2. The index or indices to be restored.
3. The desired reference date (for example: "the state of the index on the morning of June 4, 2026").
4. The preferred restore mode:
   * **Side-by-side restore** *(recommended)*: the index is restored under a new name (e.g. `restored_<index>`), without affecting the current index — allowing a comparison before switching over.
   * **In-place restore**: the current index is replaced by the restored version; this option requires closing or deleting the current index beforehand, to be agreed with the relevant application team.

Once initiated, restoring a standard-sized index typically takes a few minutes.

## Frequently asked questions

**Can the client view the available snapshots for their cluster themselves?** Yes. As the client holds the administrator account for their OpenSearch cluster, they can query the OpenSearch API directly (for example `GET /_snapshot/<repository>/_all`) to view the list of available snapshots, without going through support.

**Can the client restore an index themselves, via the OpenSearch API?** No. Access credentials for the backup repository are not shared with client teams. Every restore is carried out through a request submitted to support.

**Does this mechanism replace the virtual machine backup?** No, but their respective scopes have been redefined. The virtual machine backup now exclusively protects the operating system (binaries, disks) against total loss of that machine; protection of OpenSearch data is now fully handled by the admin repository, which enables fine-grained, index-by-index restores independently of any virtual machine restore.

**Will an index that is created and deleted on the same day be backed up?** Only if it still existed at the time of the nightly snapshot. Creating and deleting an index within the same day may therefore leave no recoverable trace.

**Can a backup frequency higher than daily be requested?** The daily frequency of the admin repository is the standard offering and cannot be changed on request. However, the client retains full freedom to deploy and administer their own client repository (see "Overview"), at whatever frequency they choose, should their business needs require a different backup cadence.

**What happens if a cluster is deleted and data needs to be recovered afterwards?** Snapshots remain available for a grace period after deletion. It is recommended to notify support before deleting a cluster if such a need is anticipated.


---

# 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/databases/opensearch/opensearch-features/opensearch-backup-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.