> ## Documentation Index > Fetch the complete documentation index at: https://private-7c7dfe99-mintlify-fbfa8bee.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > Vue d’ensemble de la sauvegarde et de la restauration dans ClickHouse # Sauvegarde et restauration dans ClickHouse > Cette section présente de manière générale les sauvegardes et les restaurations dans ClickHouse. Pour une > description plus détaillée de chaque méthode de sauvegarde, consultez les pages consacrées aux méthodes spécifiques > dans la barre latérale.
## Introduction
Bien que la [réplication](/fr/reference/engines/table-engines/mergetree-family/replication) offre une protection contre les pannes matérielles, elle ne protège pas contre les erreurs humaines : suppression accidentelle de données, suppression de la mauvaise table ou d'une table sur le mauvais cluster, et bogues logiciels entraînant un traitement incorrect des données ou leur corruption. Dans de nombreux cas, ce type d'erreur affectera toutes les répliques. ClickHouse intègre des mécanismes de protection pour éviter certains types d'erreurs. Par exemple, [par défaut](/fr/reference/settings/session-settings#max_table_size_to_drop), vous ne pouvez pas simplement supprimer des tables utilisant un moteur de la famille `MergeTree` contenant plus de 50 Go de données. Cependant, ces mécanismes de protection ne couvrent pas tous les cas possibles et des problèmes peuvent malgré tout survenir. Pour limiter efficacement les erreurs humaines potentielles, vous devez préparer avec soin une stratégie de sauvegarde et de restauration de vos données **à l'avance**. Chaque entreprise dispose de ressources et d'exigences métier différentes. Il n'existe donc pas de solution universelle de sauvegarde et de restauration ClickHouse qui convienne à toutes les situations. Ce qui fonctionne pour un gigaoctet de données ne fonctionnera probablement pas pour des dizaines de pétaoctets de données. Il existe diverses approches possibles, chacune avec ses avantages et ses inconvénients, présentées dans cette section de la documentation. Il est judicieux d'utiliser plusieurs approches plutôt qu'une seule afin de compenser leurs différentes limites. Gardez à l'esprit que si vous avez sauvegardé quelque chose sans jamais essayer de le restaurer, il y a de fortes chances que la restauration ne fonctionne pas correctement lorsque vous en aurez réellement besoin (ou qu'à tout le moins, elle prenne plus de temps que ce que l'entreprise peut tolérer). Quelle que soit l'approche de sauvegarde que vous choisissez, veillez également à automatiser le processus de restauration et entraînez-vous régulièrement sur un cluster ClickHouse de rechange. Les pages suivantes détaillent les différentes méthodes de sauvegarde et de restauration disponibles dans ClickHouse : | Page | Description | | ----------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | | [Sauvegarde/restauration à l'aide d'un disque local ou d'un disque S3](/fr/concepts/features/backup-restore/local-disk) | Détaille la sauvegarde/restauration vers ou depuis un disque local ou un disque S3 | | [Sauvegarde/restauration à l'aide d'un endpoint S3](/fr/concepts/features/backup-restore/s3-endpoint) | Détaille la sauvegarde/restauration vers ou depuis un endpoint S3 | | [Sauvegarde/restauration à l'aide d'AzureBlobStorage](/fr/concepts/features/backup-restore/azure-blob-storage) | Détaille la sauvegarde/restauration vers ou depuis Azure Blob Storage | | [Méthodes alternatives](/fr/concepts/features/backup-restore/alternative-methods) | Présente des méthodes de sauvegarde alternatives | | [Sauvegarde snapshot](/fr/concepts/features/backup-restore/snapshot) | Snapshots légers pour les tables SharedMergeTree utilisant le stockage d'objets cloud | Les sauvegardes peuvent : * être [complètes ou incrémentielles](#backup-types) * être [synchrones ou asynchrones](#synchronous-vs-asynchronous) * être [concurrentes ou non concurrentes](#concurrent-vs-non-concurrent) * être [compressées ou non compressées](#compressed-vs-uncompressed) * utiliser des [collections nommées](#using-named-collections) * être protégées par mot de passe * porter sur des [tables système, tables de logs ou tables de gestion des accès](#system-backups)
## Types de sauvegarde
Les sauvegardes peuvent être complètes ou incrémentielles. Les sauvegardes complètes constituent une copie intégrale des données, tandis que les sauvegardes incrémentielles ne contiennent que les modifications apportées depuis la dernière sauvegarde complète. Les sauvegardes complètes offrent l’avantage d’être une méthode de récupération simple, indépendante (des autres sauvegardes) et fiable. Cependant, elles peuvent prendre beaucoup de temps à s’exécuter et occuper beaucoup d’espace. Les sauvegardes incrémentielles, en revanche, sont plus efficaces à la fois en temps et en espace, mais la restauration des données nécessite que toutes les sauvegardes soient disponibles. Selon vos besoins, vous pouvez privilégier : * **Les sauvegardes complètes** pour les petites bases de données ou les données critiques. * **Les sauvegardes incrémentielles** pour les grandes bases de données ou lorsque les sauvegardes doivent être effectuées fréquemment et à moindre coût. * **Les deux**, par exemple des sauvegardes complètes hebdomadaires et des sauvegardes incrémentielles quotidiennes.
## Sauvegardes synchrones et asynchrones
Les commandes `BACKUP` et `RESTORE` peuvent également être marquées `ASYNC`. Dans ce cas, la commande de sauvegarde renvoie immédiatement, et le processus de sauvegarde s'exécute en arrière-plan. Si les commandes ne sont pas marquées `ASYNC`, le processus de sauvegarde est synchrone et la commande reste bloquée jusqu'à ce que la sauvegarde soit terminée.
## Sauvegardes concurrentes ou non concurrentes
Par défaut, ClickHouse autorise les sauvegardes et les restaurations concurrentes. Cela signifie que vous pouvez lancer simultanément plusieurs opérations de sauvegarde ou de restauration. Cependant, des paramètres au niveau du serveur permettent de désactiver ce comportement. Si vous définissez ces paramètres sur false, une seule opération de sauvegarde ou de restauration peut s’exécuter sur un cluster à la fois. Cela peut aider à éviter la contention des ressources ou d’éventuels conflits entre les opérations. Pour interdire les sauvegardes/restaurations concurrentes, vous pouvez utiliser respectivement les paramètres suivants : ```xml theme={null} false false ``` La valeur par défaut des deux est true ; par défaut, les sauvegardes/restaurations concurrentes sont donc autorisées. Lorsque ces paramètres sont définis sur false sur un cluster, une seule sauvegarde/restauration peut être exécutée sur un cluster à la fois.
## Sauvegardes compressées ou non compressées
Les sauvegardes ClickHouse prennent en charge la compression via les paramètres `compression_method` et `compression_level`. Lors de la création d’une sauvegarde, vous pouvez spécifier : ```sql theme={null} BACKUP TABLE test.table TO Disk('backups', 'filename.zip') SETTINGS compression_method='lzma', compression_level=3 ```
## Utilisation des collections nommées
Les collections nommées vous permettent de stocker des paires clé-valeur (comme des identifiants S3, des endpoints et des paramètres) réutilisables dans les opérations de sauvegarde/restauration. Elles permettent de : * Masquer les identifiants aux utilisateurs sans accès administrateur * Simplifier les commandes en centralisant les configurations complexes * Assurer la cohérence entre les opérations * Éviter l’exposition des identifiants dans les journaux de requêtes Voir [« collections nommées »](/fr/concepts/features/configuration/server-config/named-collections) pour plus de détails.
## Sauvegarde des tables système, de journalisation ou de gestion des accès
Les tables système peuvent également être incluses dans vos workflows de sauvegarde et de restauration, mais leur prise en compte dépend de votre cas d’usage. Les tables système qui stockent des données historiques, comme celles avec le suffixe `_log` (par ex., `query_log`, `part_log`), peuvent être sauvegardées et restaurées comme n’importe quelle autre table. Si votre cas d’usage repose sur l’analyse de données historiques — par exemple, l’utilisation de `query_log` pour suivre les performances des requêtes ou déboguer des problèmes — il est recommandé d’inclure ces tables dans votre stratégie de sauvegarde. En revanche, si les données historiques de ces tables ne sont pas nécessaires, elles peuvent être exclues afin d’économiser de l’espace de stockage pour les sauvegardes. Les tables système liées à la gestion des accès, telles que users, roles, row\_policies, settings\_profiles et quotas, font l’objet d’un traitement particulier lors des opérations de sauvegarde et de restauration. Lorsque ces tables sont incluses dans une sauvegarde, leur contenu est exporté dans un fichier spécial `accessXX.txt`, qui contient les instructions SQL équivalentes pour créer et configurer les entités d’accès. Lors de la restauration, le processus de restauration interprète ces fichiers et réapplique les commandes SQL pour recréer les utilisateurs, les rôles et les autres configurations. Cette fonctionnalité garantit que la configuration du contrôle d’accès d’un cluster ClickHouse peut être sauvegardée et restaurée dans le cadre de la configuration globale du cluster. Cette fonctionnalité ne fonctionne que pour les configurations gérées au moyen de commandes SQL (désignées sous le nom de ["contrôle d’accès et gestion des comptes pilotés par SQL"](/fr/concepts/features/security/access-rights#enabling-access-control)). Les configurations d’accès définies dans les fichiers de configuration du serveur ClickHouse (par ex. `users.xml`) ne sont pas incluses dans les sauvegardes et ne peuvent pas être restaurées par cette méthode.
## Syntaxe générale
```sql theme={null} -- core commands BACKUP | RESTORE --- what to backup/restore (or exclude) TABLE [db.]table_name [AS [db.]table_name_in_backup] | DICTIONARY [db.]dictionary_name [AS [db.]name_in_backup] | DATABASE database_name [AS database_name_in_backup] | TEMPORARY TABLE table_name [AS table_name_in_backup] | VIEW view_name [AS view_name_in_backup] | [EXCEPT TABLES ...] | ALL [EXCEPT {TABLES|DATABASES}...] } [,...] --- [ON CLUSTER 'cluster_name'] --- where to backup or restore to or from TO|FROM File('/') | Disk('', '/') | S3('/', '', '', '') | AzureBlobStorage('/', '', '', '', '') --- additional settings [SETTINGS ...] [ASYNC] ``` **Consultez ["résumé des commandes"](/fr/concepts/features/backup-restore/overview#command-summary) pour obtenir plus de détails sur chaque commande.**
### Résumé des commandes
Chacune des commandes ci-dessus est détaillée ci-dessous : | **Commande** | **Description** | | | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | - | | `BACKUP` | Crée une sauvegarde des objets spécifiés | | | `RESTORE` | Restaure des objets à partir d’une sauvegarde | | | `TABLE [db.]table_name [AS [db.]table_name_in_backup]` | Sauvegarde/restaure une table spécifique (peut être renommée) | | | `[PARTITION[S] partition_expr [,...]]` | Sauvegarde/restaure uniquement certaines partitions de la table | | | `DICTIONARY [db.]dictionary_name [AS [db.]name_in_backup]` | Sauvegarde/restaure un dictionnaire | | | `DATABASE database_name [AS database_name_in_backup]` | Sauvegarde/restaure une base de données entière (peut être renommée) | | | `TEMPORARY TABLE table_name [AS table_name_in_backup]` | Sauvegarde/restaure une table temporaire (peut être renommée) | | | `VIEW view_name [AS view_name_in_backup]` | Sauvegarde/restaure une vue (peut être renommée) | | | `[EXCEPT TABLES ...]` | Exclut certaines tables lors de la sauvegarde d’une base de données | | | `ALL` | Sauvegarde/restaure tout (toutes les bases de données, tables, etc.). Avant la version 23.4 de ClickHouse, `ALL` ne s’appliquait qu’à la commande `RESTORE`. | | | `[EXCEPT {TABLES\|DATABASES}...]` | Exclut certaines tables ou bases de données lors de l’utilisation de `ALL` | | | `[ON CLUSTER 'cluster_name']` | Exécute la sauvegarde/restauration sur l’ensemble d’un cluster ClickHouse | | | `TO\|FROM` | Direction : `TO` pour la destination de sauvegarde, `FROM` pour la source de restauration | | | `File('/')` | Stocke dans/restaure depuis le système de fichiers local | | | `Disk('', '/')` | Stocke sur/restaure depuis un disque configuré | | | `S3('/', '', '')` | Stocke sur/restaure depuis Amazon S3 ou un stockage compatible S3 | | | `[SETTINGS ...]` | Voir ci-dessous pour la liste complète des paramètres | | | `[ASYNC]` | Exécute l’opération de manière asynchrone (renvoie immédiatement un ID que vous pouvez surveiller) | |
### Paramètres
**Paramètres génériques de sauvegarde/restauration** | Paramètre | Description | Valeur par défaut | | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------- | | `id` | Identifiant de l’opération de sauvegarde ou de restauration ; un UUID généré aléatoirement est utilisé s’il n’est pas spécifié. S’il existe déjà une opération en cours avec le même identifiant, une exception est levée. | | | `compression_method` | Spécifie la méthode de compression de la sauvegarde. Voir la section ["codecs de compression des colonnes"](/fr/reference/statements/create/table#column_compression_codec) | | | `compression_level` | Définit le niveau de compression de la sauvegarde | | | `password` | Mot de passe de l’archive de sauvegarde. Uniquement pris en charge pour les archives ZIP (`.zip`, `.zipx`). | | | `base_backup` | La destination de la sauvegarde de base utilisée pour les sauvegardes incrémentielles. Par exemple : `Disk('backups', '1.zip')` | | | `use_same_password_for_base_backup` | Indique si l’archive de sauvegarde de base doit hériter du mot de passe de la requête. | | | `structure_only` | Si ce paramètre est activé, seules les instructions CREATE sont sauvegardées ou restaurées, sans les données de la table. | | | `storage_policy` | Politique de stockage des tables en cours de restauration. Voir ["utilisation de plusieurs périphériques bloc pour le stockage des données](/fr/reference/engines/table-engines/mergetree-family/mergetree#table_engine-mergetree-multiple-volumes). Applicable uniquement à la commande `RESTORE`. S’applique uniquement aux tables utilisant un moteur de la famille `MergeTree`. | | | `allow_non_empty_tables` | Permet à `RESTORE TABLE` d’insérer des données dans des tables non vides. Les données déjà présentes dans la table seront alors mélangées à celles extraites de la sauvegarde. Ce paramètre peut donc entraîner une duplication des données dans la table ; à utiliser avec prudence. | `0` | | `backup_restore_keeper_max_retries` | Nombre maximal de tentatives pour les opérations \[Zoo]Keeper au cours d’une opération BACKUP ou RESTORE. Il doit être suffisamment élevé pour que l’ensemble de l’opération n’échoue pas en raison d’une défaillance temporaire de \[Zoo]Keeper. | `1000` | | `backup_restore_keeper_retry_initial_backoff_ms` | Délai de backoff initial pour les opérations \[Zoo]Keeper pendant une sauvegarde ou une restauration | `100` | | `backup_restore_keeper_retry_max_backoff_ms` | Délai de backoff maximal pour les opérations \[Zoo]Keeper pendant une sauvegarde ou une restauration | `5000` | | `backup_restore_failure_after_host_disconnected_for_seconds` | Si, lors d’une opération `BACKUP ON CLUSTER` ou `RESTORE ON CLUSTER`, un hôte ne recrée pas son nœud éphémère 'alive' dans ZooKeeper pendant cette durée, l’ensemble de la sauvegarde ou de la restauration est considéré comme ayant échoué. Cette valeur doit être supérieure à tout délai raisonnable nécessaire à un hôte pour se reconnecter à ZooKeeper après une défaillance. Zéro signifie illimité. | `3600` | | `backup_restore_keeper_max_retries_while_initializing` | Nombre maximal de tentatives pour les opérations \[Zoo]Keeper lors de l'initialisation d'une opération `BACKUP ON CLUSTER` ou `RESTORE ON CLUSTER`. | `20` | | `backup_restore_keeper_max_retries_while_handling_error` | Nombre maximal de tentatives pour les opérations \[Zoo]Keeper lors de la gestion d’une erreur survenant pendant une opération `BACKUP ON CLUSTER` ou `RESTORE ON CLUSTER`. | `20` | | `backup_restore_finish_timeout_after_error_sec` | Durée pendant laquelle l’initiateur doit attendre que les autres hôtes réagissent au nœud 'error' et arrêtent leur travail sur l’opération `BACKUP ON CLUSTER` ou `RESTORE ON CLUSTER` en cours. | `180` | | `backup_restore_keeper_value_max_size` | Taille maximale des données d’un nœud \[Zoo]Keeper pendant une sauvegarde | `1048576` | | `backup_restore_batch_size_for_keeper_multi` | Taille maximale du batch pour une requête multiple vers \[Zoo]Keeper lors d'une sauvegarde ou d'une restauration | `1000` | | `backup_restore_batch_size_for_keeper_multiread` | Taille maximale du batch pour une requête de lecture multiple vers \[Zoo]Keeper lors d'une sauvegarde ou d'une restauration | `10000` | | `backup_restore_keeper_fault_injection_probability` | Probabilité approximative d’échec d’une requête Keeper lors d’une sauvegarde ou d’une restauration. La valeur doit être comprise dans l’intervalle `[0.0f, 1.0f]` | `0` | | `backup_restore_keeper_fault_injection_seed` | `0` pour une valeur d’initialisation aléatoire, sinon la valeur du paramètre | `0` | | `backup_restore_s3_retry_attempts` | Paramètre pour Aws::Client::RetryStrategy ; Aws::Client gère lui-même les tentatives de nouvelle exécution, 0 signifie aucune tentative. S'applique uniquement à la sauvegarde/restauration. | `1000` | | `max_backup_bandwidth` | Vitesse de lecture maximale en octets par seconde pour une sauvegarde donnée sur le serveur. Zéro signifie illimité. | `0` | | `max_backups_io_thread_pool_size` | ClickHouse utilise des threads du pool de threads IO des sauvegardes pour effectuer les opérations IO des sauvegardes S3. `max_backups_io_thread_pool_size` limite le nombre maximal de threads dans le pool. | `1000` | | `max_backups_io_thread_pool_free_size` | Si le nombre de threads **inactifs** dans le Backups IO Thread pool dépasse `max_backup_io_thread_pool_free_size`, ClickHouse libère les ressources occupées par ces threads et réduit la taille du pool. Des threads pourront être recréés si nécessaire. | `0` | | `backups_io_thread_pool_queue_size` | Le nombre maximal de jobs pouvant être planifiés dans le pool de threads d’E/S des sauvegardes. Il est recommandé de laisser cette file d’attente illimitée en raison du fonctionnement actuel des sauvegardes S3. Remarque : une valeur de `0` (par défaut) signifie qu’elle est illimitée. | `0` | | `backup_threads` | Le nombre maximal de threads utilisés pour exécuter les requêtes `BACKUP`. | | | `max_backup_bandwidth_for_server` | La vitesse de lecture maximale, en octets par seconde, pour toutes les sauvegardes sur le serveur. Zéro signifie aucune limite. | `0` | | `shutdown_wait_backups_and_restores` | Si cette option est définie sur true, ClickHouse attendra la fin des sauvegardes et restaurations en cours avant de s’arrêter. | `1` | **Paramètres spécifiques à S3** | Paramètre | Description | Valeur par défaut | | ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | ----------------- | | `use_same_s3_credentials_for_base_backup` | Indique si la sauvegarde de base vers S3 doit hériter des identifiants de la requête. Fonctionne uniquement avec `S3`. | | | `s3_storage_class` | Classe de stockage utilisée pour la sauvegarde S3. Par exemple : `STANDARD` | | **Paramètres spécifiques à Azure** | Paramètre | Description | Valeur par défaut | | | | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | ----------------- | - | - | | `azure_attempt_to_create_container` | Lors de l'utilisation d'Azure Blob Storage, indique s'il faut essayer de créer le conteneur spécifié s'il n'existe pas. | `true` | | |
## Administration et dépannage
La commande de sauvegarde renvoie un `id` et un `status`, et cet `id` peut être utilisé pour obtenir l’état de la sauvegarde. C’est très utile pour suivre l’avancement de sauvegardes `ASYNC` de longue durée. L’exemple ci-dessous montre un échec survenu lors d’une tentative d’écrasement d’un fichier de sauvegarde existant : ```sql theme={null} BACKUP TABLE helloworld.my_first_table TO Disk('backups', '1.zip') ASYNC ``` ```response theme={null} ┌─id───────────────────────────────────┬─status──────────┐ │ 7678b0b3-f519-4e6e-811f-5a0781a4eb52 │ CREATING_BACKUP │ └──────────────────────────────────────┴─────────────────┘ 1 row in set. Elapsed: 0.001 sec. ``` ```sql theme={null} SELECT * FROM system.backups WHERE id='7678b0b3-f519-4e6e-811f-5a0781a4eb52' FORMAT Vertical ``` ```response highlight={5,9} theme={null} Row 1: ────── id: 7678b0b3-f519-4e6e-811f-5a0781a4eb52 name: Disk('backups', '1.zip') status: BACKUP_FAILED num_files: 0 uncompressed_size: 0 compressed_size: 0 error: Code: 598. DB::Exception: Backup Disk('backups', '1.zip') already exists. (BACKUP_ALREADY_EXISTS) (version 22.8.2.11 (official build)) start_time: 2022-08-30 09:21:46 end_time: 2022-08-30 09:21:46 1 row in set. Elapsed: 0.002 sec. ``` Outre la table [`system.backups`](/fr/reference/system-tables/backups), toutes les opérations de sauvegarde et de restauration sont également consignées dans la table de journalisation système [`system.backup_log`](/fr/reference/system-tables/backup_log) : ```sql theme={null} SELECT * FROM system.backup_log WHERE id = '7678b0b3-f519-4e6e-811f-5a0781a4eb52' ORDER BY event_time_microseconds ASC FORMAT Vertical ``` ```response highlight={26} theme={null} Row 1: ────── event_date: 2023-08-18 event_time_microseconds: 2023-08-18 11:13:43.097414 id: 7678b0b3-f519-4e6e-811f-5a0781a4eb52 name: Disk('backups', '1.zip') status: CREATING_BACKUP error: start_time: 2023-08-18 11:13:43 end_time: 1970-01-01 03:00:00 num_files: 0 total_size: 0 num_entries: 0 uncompressed_size: 0 compressed_size: 0 files_read: 0 bytes_read: 0 Row 2: ────── event_date: 2023-08-18 event_time_microseconds: 2023-08-18 11:13:43.174782 id: 7678b0b3-f519-4e6e-811f-5a0781a4eb52 name: Disk('backups', '1.zip') status: BACKUP_FAILED error: Code: 598. DB::Exception: Backup Disk('backups', '1.zip') already exists. (BACKUP_ALREADY_EXISTS) (version 23.8.1.1) start_time: 2023-08-18 11:13:43 end_time: 2023-08-18 11:13:43 num_files: 0 total_size: 0 num_entries: 0 uncompressed_size: 0 compressed_size: 0 files_read: 0 bytes_read: 0 2 rows in set. Elapsed: 0.075 sec. ```