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

Page	Description
Sauvegarde/restauration à l’aide d’un disque local ou d’un disque S3	Détaille la sauvegarde/restauration vers ou depuis un disque local ou un disque S3
Sauvegarde/restauration à l’aide d’un endpoint S3	Détaille la sauvegarde/restauration vers ou depuis un endpoint S3
Sauvegarde/restauration à l’aide d’AzureBlobStorage	Détaille la sauvegarde/restauration vers ou depuis Azure Blob Storage
Méthodes alternatives	Présente des méthodes de sauvegarde alternatives
Sauvegarde snapshot	Snapshots légers pour les tables SharedMergeTree utilisant le stockage d’objets cloud

Les sauvegardes peuvent :

être complètes ou incrémentielles
être synchrones ou asynchrones
être concurrentes ou non concurrentes
être compressées ou non compressées
utiliser des collections nommées
être protégées par mot de passe
porter sur des tables système, tables de journalisation ou tables de gestion des accès

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 :

<clickhouse>
    <backups>
        <allow_concurrent_backups>false</allow_concurrent_backups>
        <allow_concurrent_restores>false</allow_concurrent_restores>
    </backups>
</clickhouse>

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 :

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 » 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

-- 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 ...] |
[EXCEPT DATA FROM {TABLE|TABLES} ...] | -- BACKUP only, rejected on RESTORE
ALL [EXCEPT {TABLES|DATABASES}...] } [,...]
--- 
[ON CLUSTER 'cluster_name']
--- where to backup or restore to or from
TO|FROM 
File('<path>/<filename>') | 
Disk('<disk_name>', '<path>/') | 
S3('<S3 endpoint>/<path>', '<Access key ID>', '<Secret access key>', '<extra_credentials>') |
AzureBlobStorage('<connection string>/<url>', '<container>', '<path>', '<account name>', '<account key>')
--- additional settings
[SETTINGS ...]
[ASYNC]

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 :

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
`[EXCEPT DATA FROM {TABLE\|TABLES} ...]`	(`BACKUP` uniquement) Sauvegarde la définition d’une table sans ses lignes. Contrairement à `EXCEPT TABLES`, cette option n’exclut pas entièrement la table. Elle s’applique à l’élément sur lequel elle est spécifiée : voir Sauvegarder une table sans ses 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('<path>/<filename>')`	Stocke dans/restaure depuis le système de fichiers local
`Disk('<disk_name>', '<path>/')`	Stocke sur/restaure depuis un disque configuré
`S3('<S3 endpoint>/<path>', '<Access key ID>', '<Secret access key>')`	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)

Sauvegarder une table sans ses données

EXCEPT DATA FROM {TABLE|TABLES} inclut la définition d’une table dans la sauvegarde, mais pas ses lignes. Cette clause est utile pour les tables dont les données peuvent être régénérées après une restauration, comme les tables cibles des vues matérialisées. La clause détermine ce que BACKUP écrit dans la sauvegarde ; elle ne change pas ce que RESTORE peut faire avec celle-ci. Si RESTORE peut recréer une table, la restauration de sa définition sans ses lignes produit une table vide. La clause ne permet pas pour autant de restaurer une table qui ne pourrait pas l’être autrement : la possibilité de recréer une table à partir de sa définition sauvegardée dépend du moteur, et certains moteurs ne le permettent pas du tout. Voir Moteurs que RESTORE ne peut pas recréer. La portée de la clause se limite à l’élément auquel elle s’applique :

Sur un élément DATABASE ou ALL, elle peut désigner n’importe quelle table sauvegardée par cet élément :

BACKUP DATABASE mydb EXCEPT DATA FROM TABLES events, metrics TO Disk('backups', 'mydb/')

Dans cette liste, entourez de backquotes toute table ou base de données nommée table, dictionary, view, database ou all : après une virgule, un nom sans backquotes est interprété comme le début de l’élément suivant.

Pour un élément portant sur un seul objet (TABLE, DICTIONARY, VIEW, TEMPORARY TABLE), seul l’objet de cet élément est pris en compte : la clause doit donc désigner cet objet, et aucun autre. Définissez un élément et une clause distincts pour chaque table :

-- Backs up both tables, without the data of `t1`
BACKUP TABLE mydb.t1 EXCEPT DATA FROM TABLE mydb.t1, TABLE mydb.t2 TO Disk('backups', 'tables/')

-- Rejected: the clause of the `mydb.t2` element names a different table
BACKUP TABLE mydb.t1, TABLE mydb.t2 EXCEPT DATA FROM TABLE mydb.t1 TO Disk('backups', 'tables/')

Si une table est désignée à la fois par un élément qui lui est propre et par la clause EXCEPT DATA FROM d’un élément plus large, ses données sont sauvegardées : désigner une table revient à demander la sauvegarde de ses données. C’est également le cas avec EXCEPT TABLES, où une table désignée explicitement est sauvegardée même si un élément plus large l’exclut. Les données de la table interne d’une vue matérialisée (ou des tables internes d’une table TimeSeries) sont exclues en indiquant le nom de l’objet externe ; la clause n’accepte pas les noms des tables internes. EXCEPT DATA FROM {TABLE|TABLES} n’est valide que pour BACKUP. RESTORE le rejette au lieu de l’accepter comme une opération sans effet.

Moteurs que `RESTORE` ne peut pas recréer

Certains moteurs ne peuvent pas être recréés par RESTORE, que l’option EXCEPT DATA FROM {TABLE|TABLES} soit utilisée ou non. Pour ces tables, la clause détermine toujours la taille de la sauvegarde, mais elle ne permet pas de restaurer une table vide : aucune table n’est restaurée à sa place, car RESTORE refuse de la créer. Le cas à retenir est celui d’une table MaterializedPostgreSQL autonome. Dès sa création, elle commencerait à répliquer les données depuis la source PostgreSQL active, mêlant ainsi le snapshot de la sauvegarde à l’état actuel de la source distante. C’est pourquoi RESTORE la rejette au niveau de la fabrique de stockage, avant même la création de la table, avec l’erreur NOT_IMPLEMENTED. Cette limitation est propre au moteur et s’applique aussi à une sauvegarde complète ordinaire. La procédure prise en charge consiste à restaurer les données sous un autre nom, dans une table ReplacingMergeTree créée au préalable avec la structure de la table imbriquée (y compris les colonnes _sign et _version) :

-- Back up the definition without the rows: they are replicated from PostgreSQL and can be replicated again
BACKUP DATABASE mydb EXCEPT DATA FROM TABLE mydb.pg_table TO Disk('backups', 'mydb/')

CREATE TABLE mydb.plain_target
(
    key Int32,
    value Int32,
    _sign Int8 MATERIALIZED 1,
    _version UInt64 MATERIALIZED 1
)
ENGINE = ReplacingMergeTree(_version) ORDER BY key

-- Succeeds, and leaves `mydb.plain_target` empty because the backup carries no rows for `mydb.pg_table`
RESTORE TABLE mydb.pg_table AS mydb.plain_target FROM Disk('backups', 'mydb/')
SETTINGS allow_different_table_def = 1

allow_different_table_def est nécessaire, car la définition enregistrée dans la sauvegarde utilise le moteur MaterializedPostgreSQL, alors que la restauration cible volontairement un simple ReplacingMergeTree. Sans EXCEPT DATA FROM TABLE, la même commande RESTORE restaure aussi les lignes.

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”
`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.
`restore_table_data`	Indique s’il faut restaurer les données des tables. Applicable uniquement à la commande `RESTORE`. Lorsqu’il n’est pas défini, sa valeur par défaut est `NOT structure_only` ; le définir explicitement surcharge `structure_only`. Voir “Paramètres de restauration”.
`restore_access_entities`	Indique s’il faut restaurer les entités d’accès (utilisateurs, rôles, profils de paramètres, politiques de lignes, quotas). Applicable uniquement à la commande `RESTORE`. Lorsqu’il n’est pas défini, sa valeur par défaut est `NOT structure_only` ; le définir explicitement surcharge `structure_only`. Voir “Paramètres de restauration”.
`restore_functions`	Indique s’il faut restaurer les fonctions définies par l’utilisateur. Applicable uniquement à la commande `RESTORE`. Lorsqu’il n’est pas défini, sa valeur par défaut est `NOT structure_only` ; le définir explicitement surcharge `structure_only`. Voir “Paramètres de restauration”.
`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. 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 :

BACKUP TABLE helloworld.my_first_table TO Disk('backups', '1.zip') ASYNC

┌─id───────────────────────────────────┬─status──────────┐
│ 7678b0b3-f519-4e6e-811f-5a0781a4eb52 │ CREATING_BACKUP │
└──────────────────────────────────────┴─────────────────┘

1 row in set. Elapsed: 0.001 sec.

SELECT
*
FROM system.backups
WHERE id='7678b0b3-f519-4e6e-811f-5a0781a4eb52'
FORMAT Vertical

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, toutes les opérations de sauvegarde et de restauration sont également consignées dans la table de journalisation système system.backup_log :

SELECT *
FROM system.backup_log
WHERE id = '7678b0b3-f519-4e6e-811f-5a0781a4eb52'
ORDER BY event_time_microseconds ASC
FORMAT Vertical

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.

Principes fondamentaux

Concepts de ClickHouse

Bonnes pratiques

Sauvegarde et restauration dans ClickHouse

Introduction

Types de sauvegarde

Sauvegardes synchrones et asynchrones

Sauvegardes concurrentes ou non concurrentes

Sauvegardes compressées ou non compressées

Utilisation des collections nommées

Sauvegarde des tables système, de journalisation ou de gestion des accès

Syntaxe générale

Résumé des commandes

Sauvegarder une table sans ses données

Moteurs que `RESTORE` ne peut pas recréer

Paramètres

Administration et dépannage

​Introduction

​Types de sauvegarde

​Sauvegardes synchrones et asynchrones

​Sauvegardes concurrentes ou non concurrentes

​Sauvegardes compressées ou non compressées

​Utilisation des collections nommées

​Sauvegarde des tables système, de journalisation ou de gestion des accès

​Syntaxe générale

​Résumé des commandes

​Sauvegarder une table sans ses données

​Moteurs que RESTORE ne peut pas recréer

​Paramètres

​Administration et dépannage

Introduction

Types de sauvegarde

Sauvegardes synchrones et asynchrones

Sauvegardes concurrentes ou non concurrentes

Sauvegardes compressées ou non compressées

Utilisation des collections nommées

Sauvegarde des tables système, de journalisation ou de gestion des accès

Syntaxe générale

Résumé des commandes

Sauvegarder une table sans ses données

Moteurs que `RESTORE` ne peut pas recréer

Paramètres

Administration et dépannage