Passer au contenu principal
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 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, 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 : Les sauvegardes peuvent :

​
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 :
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 :

​
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 » 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”). 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

Consultez “résumé des commandes” pour obtenir plus de détails sur chaque commande.

​
Résumé des commandes

Chacune des commandes ci-dessus est détaillée ci-dessous :

​
Paramètres

Paramètres génériques de sauvegarde/restauration Paramètres spécifiques à S3 Paramètres spécifiques à Azure

​
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 :
Outre la table system.backups, toutes les opérations de sauvegarde et de restauration sont également consignées dans la table de journalisation système system.backup_log :
Dernière modification le 1 juillet 2026