> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-revert-104359-revert-104251-parquet-single.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Guide expliquant comment configurer les sauvegardes

# Configurer la planification des sauvegardes

export const CloudNotSupportedBadge = () => {
  return <a href="https://clickhouse.com/docs/products/cloud/guides/cloud-compatibility#list-of-unsupported-features" className="cloudNotSupportedBadge">
            <div className="cloudNotSupportedIcon">
            <svg width="16" height="16" viewBox="0 0 16 16" fill="none" xmlns="http://www.w3.org/2000/svg">
                <path strokeWidth="1.5" d="M6.33366 12.6666L12.3739 12.6667C13.6593 12.6667 14.7073 11.6187 14.7073 10.3334C14.7073 9.04804 13.6593 8.00003 12.3739 8.00003C12.3739 8.00003 12.3337 7.66659 12.0003 7.33325M10.667 5.33322C8.00033 2.33325 4.45395 4.78537 4.14195 6.68203C2.55728 6.7627 1.29395 8.06203 1.29395 9.6667C1.29395 11.3234 2.66699 12.6666 4.00033 12.6666" stroke="currentColor" strokeLinecap="round" strokeLinejoin="round" />
                <path strokeWidth="1.5" d="M2.66699 14L12.0003 4.66663" stroke="currentColor" strokeLinecap="round" strokeLinejoin="round" />
            </svg>

        </div>
            Non pris en charge par ClickHouse Cloud
        </a>;
};

Cette page explique comment consulter et modifier la planification des sauvegardes d'un service ClickHouse Cloud depuis la ligne de commande, à l'aide du [ClickHouse CLI](/fr/products/cloud/features/cli) (`clickhousectl`). Les commandes sont non interactives ; `clickhousectl` produit du JSON avec l'option `--json`.

Les sauvegardes configurables sont disponibles dans les plans Scale et Enterprise.

<h2 id="prerequisites">
  Prérequis
</h2>

Installez la ClickHouse CLI :

```bash theme={null}
curl https://clickhouse.com/cli | sh
```

Vous avez également besoin de `jq`.

La modification de la configuration de sauvegarde est une opération d'écriture et nécessite une [authentification par API key](/fr/products/cloud/features/admin-features/api/openapi) ; la connexion OAuth est en lecture seule :

```bash theme={null}
clickhousectl cloud auth login --api-key <YOUR_KEY> --api-secret <YOUR_SECRET>
```

Vous pouvez également définir les variables d'environnement `CLICKHOUSE_CLOUD_API_KEY` et `CLICKHOUSE_CLOUD_API_SECRET`. Vérifiez avec `clickhousectl cloud auth status` : assurez-vous que le credential **actif** est bien celui dont le scope est `read/write`. Les credentials enregistrés par un précédent `auth login` priment sur les variables d'environnement ; dans ce cas, la ligne `Env vars` peut afficher le scope `read/write` tout en étant marquée comme inactive (`Configured (inactive, outranked by credentials file)`), et les commandes d'écriture ci-dessous s'exécutent alors avec les credentials enregistrés. Exécutez d'abord `clickhousectl cloud auth logout` si vous souhaitez que les variables d'environnement soient prises en compte.

<h2 id="find-the-service-id">
  Trouver l'ID du service
</h2>

La configuration de sauvegarde se définit par service. Recherchez l'ID du service à partir de son nom :

```bash theme={null}
CH_ID=$(clickhousectl cloud service list --json \
  | jq -r '.[] | select(.name=="<service-name>") | .id')
```

Si vous appartenez à plusieurs organizations, l'organization ne peut pas être détectée automatiquement et cette commande échoue avec le message `Multiple organizations found. Specify --org-id to choose one.`. Listez vos organizations avec `clickhousectl cloud org list`, puis passez `--org-id <org-id>` à cette commande ainsi qu'à chacune des commandes `backup-config` ci-dessous.

<h2 id="read-the-current-backup-configuration">
  Lire la configuration de sauvegarde actuelle
</h2>

```bash theme={null}
clickhousectl cloud service backup-config get "$CH_ID" --json
```

Un service qui utilise encore le schedule par défaut renvoie :

```json theme={null}
{
  "backupPeriodInHours": 24.0,
  "backupRetentionPeriodInHours": 24.0
}
```

`backupStartTime` n'apparaît dans la sortie qu'une fois qu'un horodatage de début a été défini.

<h2 id="change-retention-and-frequency">
  Modifier la rétention et la fréquence
</h2>

`backup-config update` accepte les mêmes paramètres que le formulaire de la console — la rétention (`--backup-retention-period-hours`), la fréquence (`--backup-period-hours`) et l'horodatage de début (`--backup-start-time`) — et affiche la configuration obtenue. Les options que vous omettez conservent leurs valeurs actuelles :

```bash theme={null}
clickhousectl cloud service backup-config update "$CH_ID" \
  --backup-period-hours 12 \
  --backup-retention-period-hours 48 \
  --json
```

```json theme={null}
{
  "backupPeriodInHours": 12.0,
  "backupRetentionPeriodInHours": 48.0
}
```

La modification prend effet immédiatement ; relisez la configuration pour vous en assurer :

```bash theme={null}
clickhousectl cloud service backup-config get "$CH_ID" --json
```

```json theme={null}
{
  "backupPeriodInHours": 12.0,
  "backupRetentionPeriodInHours": 48.0
}
```

<h2 id="set-a-backup-start-time">
  Définir un horodatage de début de sauvegarde
</h2>

`--backup-start-time` attend un horodatage de début quotidien en UTC, à l'heure pile (`HH:00`). Un horodatage de début contraint la fréquence : la période de sauvegarde doit être de `24` ou `48` heures, qu'elle soit passée dans la même commande ou déjà enregistrée sur le service. Depuis `clickhousectl 0.4.2`, le format et la règle de période sont tous deux vérifiés côté client, avant tout appel d'API. Une heure qui ne tombe pas pile — ou qui n'est pas complétée par un zéro, comme `2:00` — est rejetée par le parser d'arguments avec le code de sortie `2` :

```bash theme={null}
clickhousectl cloud service backup-config update "$CH_ID" --backup-start-time 02:30 --json
```

```text theme={null}
error: invalid value '02:30' for '--backup-start-time <BACKUP_START_TIME>': invalid backup start time '02:30': expected HH:00 with HH from 00 to 23
```

De même, l'utilisation de `--backup-start-time` avec une valeur de `--backup-period-hours` autre que `24` ou `48` est rejetée avant l'envoi de la requête, avec le code de sortie `1` :

```text theme={null}
Error: --backup-period-hours must be 24 or 48 when --backup-start-time is set
```

`--backup-period-hours` peut être omis ; dans ce cas, le service conserve la période dont il dispose déjà — mais cette période stockée doit elle-même être de `24` ou `48`. Sur un service utilisant encore le schedule par défaut, la période est de `24` : un horodatage de début suffit donc à lui seul. Le service ci-dessus a été défini à `12` à l'étape précédente ; omettre la période échoue donc : `clickhousectl` lit d'abord la configuration stockée et refuse avec le code de sortie `1`, là encore sans appeler l'API :

```bash theme={null}
clickhousectl cloud service backup-config update "$CH_ID" --backup-start-time 03:00 --json
```

```text theme={null}
Error: the stored backup period is 12 hours, but --backup-start-time requires 24 or 48. Pass --backup-period-hours 24 or --backup-period-hours 48 in the same call.
```

Passer explicitement la période constitue la combinaison valide :

```bash theme={null}
clickhousectl cloud service backup-config update "$CH_ID" \
  --backup-start-time 02:00 \
  --backup-period-hours 24 \
  --json
```

```json theme={null}
{
  "backupPeriodInHours": 24.0,
  "backupRetentionPeriodInHours": 48.0,
  "backupStartTime": "02:00"
}
```

Le cas inverse n'est pas détecté côté client : si un horodatage de début est déjà enregistré, une mise à jour qui modifie uniquement `--backup-period-hours` en lui donnant une valeur autre que `24` ou `48` parvient jusqu'à l'API et y échoue, avec le code de sortie `1` :

```bash theme={null}
clickhousectl cloud service backup-config update "$CH_ID" --backup-period-hours 12 --json
```

```text theme={null}
Error: BAD_REQUEST: customBackupPeriod must be 24 or 48 hours when customBackupStartTime is set
```

Effacer l'horodatage de début dans la même commande permet d'éviter ce problème, comme illustré ci-dessous.

<h2 id="clear-the-backup-start-time">
  Effacer l'horodatage de début de sauvegarde
</h2>

`--clear-backup-start-time` supprime l'horodatage de début stocké et lève la restriction de `24`/`48` heures sur la période :

```bash theme={null}
clickhousectl cloud service backup-config update "$CH_ID" \
  --clear-backup-start-time \
  --json
```

```json theme={null}
{
  "backupPeriodInHours": 24.0,
  "backupRetentionPeriodInHours": 48.0
}
```

`backupStartTime` disparaît de la sortie au lieu d'être signalé comme `null`, et `backup-config get` ne le renvoie plus. Effacer un horodatage de début qui n'a jamais été défini est un no-op qui se termine malgré tout avec le code `0`.

Combinez cette option avec `--backup-period-hours` pour effacer l'horodatage de début et définir une période en une seule commande — c'est ainsi que l'on contourne l'erreur d'API évoquée ci-dessus :

```bash theme={null}
clickhousectl cloud service backup-config update "$CH_ID" \
  --clear-backup-start-time \
  --backup-period-hours 12 \
  --json
```

```json theme={null}
{
  "backupPeriodInHours": 12.0,
  "backupRetentionPeriodInHours": 48.0
}
```

`--clear-backup-start-time` et `--backup-start-time` ne peuvent pas être combinés ; le parser rejette cette paire avec le code de sortie `2` :

```text theme={null}
error: the argument '--clear-backup-start-time' cannot be used with '--backup-start-time <BACKUP_START_TIME>'
```

Pour déplacer un horodatage de début plutôt que de le supprimer, passez la nouvelle valeur `--backup-start-time` seule : elle écrase celle qui est enregistrée.

<Note>
  Modifier la planification des sauvegardes peut entraîner des frais mensuels de stockage plus élevés, car certaines sauvegardes risquent de ne pas être couvertes par les sauvegardes par défaut du service. Voir [« Comprendre le coût des sauvegardes »](/fr/products/cloud/guides/backups/review-and-restore-backups#understanding-backup-cost).
</Note>