Copia de seguridad y restauración en ClickHouse

Esta sección ofrece una visión general de las copias de seguridad y la restauración en ClickHouse. Para obtener una descripción más detallada de cada método de copia de seguridad, consulta las páginas de cada método específico en la barra lateral.

Introducción

Aunque la replicación ofrece protección frente a fallos de hardware, no protege contra errores humanos: eliminación accidental de datos, eliminación de la tabla equivocada o de una tabla en el clúster equivocado, y errores de software que den lugar a un procesamiento incorrecto de los datos o a su corrupción. En muchos casos, errores como estos afectarán a todas las réplicas. ClickHouse incorpora mecanismos de protección para evitar algunos tipos de errores; por ejemplo, de forma predeterminada no se pueden eliminar sin más tablas con un motor de la familia MergeTree que contengan más de 50 Gb de datos. Sin embargo, estas protecciones no cubren todos los casos posibles y los problemas pueden seguir ocurriendo. Para mitigar eficazmente los posibles errores humanos, debe preparar cuidadosamente una estrategia para realizar copias de seguridad y restaurar sus datos con antelación. Cada empresa dispone de recursos diferentes y tiene requisitos de negocio distintos, por lo que no existe una solución universal de copias de seguridad y restauración en ClickHouse que se adapte a todas las situaciones. Lo que funciona para un gigabyte de datos probablemente no funcionará para decenas de petabytes de datos. Existen varios enfoques posibles, cada uno con sus propias ventajas y desventajas, que se presentan en esta sección de la documentación. Conviene usar varios enfoques en lugar de uno solo, para compensar sus distintas limitaciones.

Tenga en cuenta que, si hizo una copia de seguridad de algo y nunca intentó restaurarla, lo más probable es que la restauración no funcione correctamente cuando realmente la necesite (o, al menos, tardará más de lo que la empresa puede tolerar). Por eso, sea cual sea el enfoque de copia de seguridad que elija, asegúrese de automatizar también el proceso de restauración y practíquelo regularmente en un clúster de ClickHouse de reserva.

Las páginas siguientes detallan los distintos métodos de copia de seguridad y restauración disponibles en ClickHouse:

Página	Descripción
Copia de seguridad/restauración con disco local o disco S3	Detalla la copia de seguridad/restauración hacia o desde un disco local o un disco S3
Copia de seguridad/restauración mediante endpoint de S3	Detalla la copia de seguridad/restauración hacia o desde un endpoint de S3
Copia de seguridad/restauración mediante AzureBlobStorage	Detalla la copia de seguridad/restauración hacia o desde Azure blob storage
Métodos alternativos	Analiza métodos alternativos de copia de seguridad
Snapshot backup	Snapshots ligeros para tablas SharedMergeTree que usan Cloud Object Storage

Las copias de seguridad pueden:

ser síncronas o asíncronas
ser síncronas o asíncronas
ser concurrentes o no concurrentes
estar comprimidas o sin comprimir
usar colecciones con nombre
estar protegidas con contraseña
hacerse de tablas del sistema, tablas de registro o tablas de gestión de acceso

Tipos de copias de seguridad

Las copias de seguridad pueden ser completas o incrementales. Las copias de seguridad completas son una copia íntegra de los datos, mientras que las incrementales contienen únicamente los cambios realizados desde la última copia de seguridad completa. Las copias de seguridad completas tienen la ventaja de ofrecer un método de recuperación simple, independiente (de otras copias de seguridad) y fiable. Sin embargo, pueden tardar mucho en completarse y ocupar mucho espacio. Las copias de seguridad incrementales, en cambio, son más eficientes tanto en tiempo como en espacio, pero para restaurar los datos es necesario que todas las copias de seguridad estén disponibles. Según sus necesidades, puede que le convenga usar:

Copias de seguridad completas para bases de datos más pequeñas o datos críticos.
Copias de seguridad incrementales para bases de datos más grandes o cuando sea necesario realizar copias de seguridad con frecuencia y de forma rentable.
Ambas; por ejemplo, copias de seguridad completas semanales y copias de seguridad incrementales diarias.

Copias de seguridad síncronas vs. asíncronas

Los comandos BACKUP y RESTORE también se pueden marcar como ASYNC. En este caso, el comando de copia de seguridad devuelve el control de inmediato y el proceso de copia de seguridad se ejecuta en segundo plano. Si los comandos no se marcan como ASYNC, el proceso de copia de seguridad es síncrono y el comando queda bloqueado hasta que se completa la copia de seguridad.

Copias de seguridad concurrentes y no concurrentes

De forma predeterminada, ClickHouse permite realizar copias de seguridad y restauraciones de forma concurrente. Esto significa que puede iniciar varias operaciones de copia de seguridad o restauración simultáneamente. Sin embargo, hay ajustes a nivel de servidor que permiten desactivar este comportamiento. Si establece estos ajustes en false, solo se permitirá ejecutar una operación de copia de seguridad o restauración en un clúster a la vez. Esto puede ayudar a evitar la contención de recursos o posibles conflictos entre operaciones. Para desactivar las copias de seguridad/restauraciones concurrentes, puede usar estos ajustes, respectivamente:

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

El valor predeterminado de ambos es true, por lo que, por defecto, se permiten las copias de seguridad/restauraciones concurrentes. Cuando estas configuraciones están en false en un clúster, solo se permite que una única copia de seguridad/restauración se ejecute en un clúster a la vez.

Copias de seguridad comprimidas y sin comprimir

Las copias de seguridad de ClickHouse admiten compresión mediante la configuración compression_method y compression_level. Al crear una copia de seguridad, puedes especificar:

BACKUP TABLE test.table
  TO Disk('backups', 'filename.zip')
  SETTINGS compression_method='lzma', compression_level=3

Uso de colecciones con nombre

Las colecciones con nombre le permiten almacenar pares clave-valor (como credenciales de S3, endpoints y opciones de configuración) que pueden reutilizarse en operaciones de copia de seguridad y restauración. Ayudan a:

Ocultar las credenciales a los usuarios sin acceso de administrador
Simplificar los comandos al almacenar configuraciones complejas de forma centralizada
Mantener la coherencia entre operaciones
Evitar la exposición de credenciales en los logs de consultas

Consulte “colecciones con nombre” para obtener más información.

Copia de seguridad de tablas del sistema, de registro o de gestión de acceso

Las tablas del sistema también pueden incluirse en los flujos de trabajo de copia de seguridad y restauración, pero su inclusión depende de su caso de uso específico. Las tablas del sistema que almacenan datos históricos, como aquellas con el sufijo _log (p. ej., query_log, part_log), pueden incluirse en copias de seguridad y restaurarse como cualquier otra tabla. Si su caso de uso depende del análisis de datos históricos —por ejemplo, usar query_log para hacer un seguimiento del rendimiento de las consultas o depurar problemas—, se recomienda incluir estas tablas en su estrategia de copia de seguridad. Sin embargo, si los datos históricos de estas tablas no son necesarios, pueden excluirse para ahorrar espacio de almacenamiento. Las tablas del sistema relacionadas con la gestión de acceso, como users, roles, row_policies, settings_profiles y quotas, reciben un tratamiento especial durante las operaciones de copia de seguridad y restauración. Cuando estas tablas se incluyen en una copia de seguridad, su contenido se exporta a un archivo especial accessXX.txt, que contiene las sentencias SQL equivalentes para crear y configurar las entidades de acceso. Durante la restauración, el proceso de restauración interpreta estos archivos y vuelve a aplicar los comandos SQL para recrear los users, roles y otras configuraciones. Esta funcionalidad garantiza que la configuración de control de acceso de un clúster de ClickHouse pueda incluirse en una copia de seguridad y restaurarse como parte de la configuración general del clúster. Esta funcionalidad solo funciona para configuraciones gestionadas mediante comandos SQL (conocidas como “Control de acceso y gestión de cuentas controlados por SQL”). Las configuraciones de acceso definidas en los archivos de configuración del ClickHouse server (p. ej. users.xml) no se incluyen en las copias de seguridad y no pueden restaurarse mediante este método.

Sintaxis general

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

Consulte “resumen de comandos” para obtener más información sobre cada comando.

Resumen de comandos

A continuación, se detallan cada uno de los comandos anteriores:

Comando	Descripción
`BACKUP`	Crea una copia de seguridad de los objetos especificados
`RESTORE`	Restaura objetos desde una copia de seguridad
`TABLE [db.]table_name [AS [db.]table_name_in_backup]`	Hace una copia de seguridad de una tabla específica o la restaura (se puede cambiar de nombre)
`[PARTITION[S] partition_expr [,...]]`	Solo hace una copia de seguridad de particiones específicas de la tabla o las restaura
`DICTIONARY [db.]dictionary_name [AS [db.]name_in_backup]`	Hace una copia de seguridad de un objeto Diccionario o lo restaura
`DATABASE database_name [AS database_name_in_backup]`	Hace una copia de seguridad de una base de datos completa o la restaura (se puede cambiar de nombre)
`TEMPORARY TABLE table_name [AS table_name_in_backup]`	Hace una copia de seguridad de una tabla temporal o la restaura (se puede cambiar de nombre)
`VIEW view_name [AS view_name_in_backup]`	Hace una copia de seguridad de una vista o la restaura (se puede cambiar de nombre)
`[EXCEPT TABLES ...]`	Excluye tablas específicas al hacer una copia de seguridad de una base de datos
`[EXCEPT DATA FROM {TABLE\|TABLES} ...]`	(Solo BACKUP) Hace una copia de seguridad de la definición de una tabla sin sus filas. A diferencia de `EXCEPT TABLES`, no excluye la tabla por completo. Solo se aplica al elemento en el que se especifica: consulta Cómo hacer una copia de seguridad de una tabla sin sus datos.
`ALL`	Hace una copia de seguridad de todo o lo restaura (todas las bases de datos, tablas, etc.). Antes de la versión 23.4 de ClickHouse, `ALL` solo se aplicaba al comando `RESTORE`.
`[EXCEPT {TABLES\|DATABASES}...]`	Excluye tablas o bases de datos específicas al usar `ALL`
`[ON CLUSTER 'cluster_name']`	Ejecuta la copia de seguridad o la restauración en un clúster de ClickHouse
`TO\|FROM`	Dirección: `TO` para el destino de la copia de seguridad, `FROM` para el origen de la restauración
`File('<path>/<filename>')`	Almacena en el sistema de archivos local o restaura desde él
`Disk('<disk_name>', '<path>/')`	Almacena en un disco configurado o restaura desde él
`S3('<S3 endpoint>/<path>', '<Access key ID>', '<Secret access key>')`	Almacena en Amazon S3 o almacenamiento compatible con S3, o restaura desde ellos
`[SETTINGS ...]`	Consulta a continuación la lista completa de opciones de configuración
`[ASYNC]`	Hace que la operación se ejecute de forma asíncrona (devuelve inmediatamente un ID que puedes supervisar)

Copia de seguridad de una tabla sin sus datos

EXCEPT DATA FROM {TABLE|TABLES} incluye la definición de una tabla en la copia de seguridad, pero no sus filas. Resulta útil para tablas cuyo contenido puede regenerarse después de una restauración, por ejemplo, las tablas de destino de vistas materializadas. La cláusula determina lo que escribe BACKUP; no cambia lo que RESTORE puede hacer con el resultado. En el caso de una tabla que RESTORE puede recrear, una definición sin filas se restaura como una tabla vacía. Sin embargo, no hace restaurable una tabla que de otro modo no lo sería: que una definición de la copia de seguridad pueda convertirse de nuevo en una tabla depende del motor, y algunos motores directamente no lo permiten; consulte Motores que RESTORE no puede recrear. El alcance de la cláusula se limita al elemento en el que se especifica:

En un elemento DATABASE o ALL, puede indicar cualquier tabla incluida en la copia de seguridad de ese elemento:

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

En esta lista, escriba entre comillas invertidas cualquier tabla o base de datos llamada table, dictionary, view, database o all: después de una coma, un nombre sin comillas se interpreta como el inicio del siguiente elemento.

En un elemento que hace referencia a un solo objeto (TABLE, DICTIONARY, VIEW, TEMPORARY TABLE), solo el objeto de ese elemento está dentro del ámbito, por lo que la cláusula debe especificar ese objeto y ningún otro. Defina un elemento y una cláusula propios para cada tabla:

-- 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 una tabla se menciona tanto en un elemento propio como en la cláusula EXCEPT DATA FROM de un elemento más amplio, sus datos sí se incluyen en la copia de seguridad: al especificar una tabla en un elemento, también se solicitan sus datos. Lo mismo ocurre con EXCEPT TABLES, donde una tabla mencionada explícitamente se incluye en la copia de seguridad aunque un elemento más amplio la excluya. Los datos de la tabla interna de una vista materializada (o de las tablas internas de una tabla TimeSeries) se excluyen mediante el nombre del objeto externo; la cláusula no acepta los nombres de las tablas internas. EXCEPT DATA FROM {TABLE|TABLES} solo es válida para BACKUP. RESTORE la rechaza en lugar de aceptarla sin que tenga efecto.

Motores que `RESTORE` no puede recrear

Algunos motores no se pueden recrear con RESTORE bajo ninguna circunstancia, se use o no EXCEPT DATA FROM {TABLE|TABLES}. En esas tablas, la cláusula sigue determinando el tamaño de la copia de seguridad, pero no permite restaurar una tabla vacía: no se restaura ninguna tabla porque RESTORE se niega a crearla. El caso más importante es el de una tabla MaterializedPostgreSQL independiente. En cuanto se creara, empezaría a replicar datos desde la fuente PostgreSQL activa y mezclaría la instantánea de la copia de seguridad con el estado actual de la fuente remota. Por eso, RESTORE rechaza su creación en la fábrica de almacenamiento, antes de que se cree la tabla, con NOT_IMPLEMENTED. Esta limitación es propia del motor y también se aplica a una copia de seguridad completa convencional. El procedimiento admitido consiste en restaurar la tabla con otro nombre en una tabla ReplacingMergeTree creada previamente con la estructura de la tabla anidada (incluidas las columnas _sign y _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 es necesario porque la definición almacenada en la copia de seguridad utiliza el motor MaterializedPostgreSQL, que se restaura deliberadamente como un ReplacingMergeTree estándar. Sin EXCEPT DATA FROM TABLE, el mismo RESTORE transfiere también las filas.

Configuración

Configuración general de copia de seguridad y restauración

Configuración	Descripción	Valor predeterminado
`id`	ID de la operación de copia de seguridad o restauración; si no se especifica, se usa un UUID generado aleatoriamente. Si ya hay una operación en ejecución con el mismo ID, se lanza una excepción.
`compression_method`	Especifica el método de compresión para la copia de seguridad. Consulte la sección “codecs de compresión de columnas”
`compression_level`	Especifica el nivel de compresión de la copia de seguridad
`password`	Contraseña del archivo de copia de seguridad. Solo se admite en archivos ZIP (`.zip`, `.zipx`).
`base_backup`	El destino de la copia de seguridad base utilizada para las copias de seguridad incrementales. Por ejemplo: `Disk('backups', '1.zip')`
`use_same_password_for_base_backup`	Indica si el archivo de la copia de seguridad base debe heredar la contraseña de la consulta.
`structure_only`	Si se habilita, solo realiza la copia de seguridad o la restauración de las sentencias CREATE, sin los datos reales de la tabla.
`restore_table_data`	Indica si se deben restaurar los datos de las tablas. Solo se aplica al comando `RESTORE`. Cuando no se establece, el valor predeterminado es `NOT structure_only`; establecerlo explícitamente sobrescribe `structure_only`. Consulte “Configuración de restauración”.
`restore_access_entities`	Indica si se deben restaurar las entidades de acceso (usuarios, roles, perfiles de configuración, políticas de filas, cuotas). Solo se aplica al comando `RESTORE`. Cuando no se establece, el valor predeterminado es `NOT structure_only`; establecerlo explícitamente sobrescribe `structure_only`. Consulte “Configuración de restauración”.
`restore_functions`	Indica si se deben restaurar las funciones definidas por el usuario. Solo se aplica al comando `RESTORE`. Cuando no se establece, el valor predeterminado es `NOT structure_only`; establecerlo explícitamente sobrescribe `structure_only`. Consulte “Configuración de restauración”.
`storage_policy`	Política de almacenamiento para las tablas que se están restaurando. Consulte “uso de varios dispositivos de bloque para el almacenamiento de datos. Solo se aplica al comando `RESTORE`. Se aplica únicamente a tablas con un motor de la familia `MergeTree`.
`allow_non_empty_tables`	Permite que `RESTORE TABLE` inserte datos en tablas no vacías. Esto mezclará los datos existentes en la tabla con los datos extraídos de la copia de seguridad. Por lo tanto, esta configuración puede provocar la duplicación de datos en la tabla; úsela con precaución.	`0`
`backup_restore_keeper_max_retries`	Número máximo de reintentos para las operaciones de [Zoo]Keeper en medio de una operación BACKUP o RESTORE. Debe ser lo bastante alto para que toda la operación no falle por un fallo temporal de [Zoo]Keeper.	`1000`
`backup_restore_keeper_retry_initial_backoff_ms`	Tiempo de espera del backoff inicial para las operaciones de [Zoo]Keeper durante BACKUP o RESTORE	`100`
`backup_restore_keeper_retry_max_backoff_ms`	Tiempo de espera máximo del backoff para las operaciones de [Zoo]Keeper durante BACKUP o RESTORE	`5000`
`backup_restore_failure_after_host_disconnected_for_seconds`	Si un host, durante una operación `BACKUP ON CLUSTER` o `RESTORE ON CLUSTER`, no vuelve a crear su nodo efímero ‘alive’ en ZooKeeper dentro de este intervalo de tiempo, toda la copia de seguridad o la restauración se considera fallida. Este valor debe ser mayor que cualquier tiempo razonable que un host pueda tardar en volver a conectarse a ZooKeeper después de un fallo. Cero significa sin límite.	`3600`
`backup_restore_keeper_max_retries_while_initializing`	Máximo de reintentos para las operaciones de [Zoo]Keeper durante la inicialización de una operación `BACKUP ON CLUSTER` o `RESTORE ON CLUSTER`.	`20`
`backup_restore_keeper_max_retries_while_handling_error`	Número máximo de reintentos para las operaciones de [Zoo]Keeper al gestionar un error en una operación `BACKUP ON CLUSTER` o `RESTORE ON CLUSTER`.	`20`
`backup_restore_finish_timeout_after_error_sec`	Cuánto tiempo debe esperar el initiator a que el otro host reaccione al nodo de ‘error’ y detenga su trabajo en la operación actual `BACKUP ON CLUSTER` o `RESTORE ON CLUSTER`.	`180`
`backup_restore_keeper_value_max_size`	Tamaño máximo de los datos de un nodo de [Zoo]Keeper durante BACKUP	`1048576`
`backup_restore_batch_size_for_keeper_multi`	Tamaño máximo del lote para solicitudes múltiples a [Zoo]Keeper durante la copia de seguridad o la restauración	`1000`
`backup_restore_batch_size_for_keeper_multiread`	Tamaño máximo del lote para solicitudes de lectura múltiple a [Zoo]Keeper durante la copia de seguridad o la restauración	`10000`
`backup_restore_keeper_fault_injection_probability`	Probabilidad aproximada de fallo de una solicitud a Keeper durante la copia de seguridad o la restauración. El valor válido está en el intervalo `[0.0f, 1.0f]`	`0`
`backup_restore_keeper_fault_injection_seed`	`0` para una semilla aleatoria; de lo contrario, el valor de la configuración	`0`
`backup_restore_s3_retry_attempts`	Configuración de Aws::Client::RetryStrategy; Aws::Client gestiona por sí mismo los reintentos; 0 significa que no hay reintentos. Solo se aplica a la copia de seguridad/restauración.	`1000`
`max_backup_bandwidth`	Velocidad máxima de lectura en bytes por segundo para una copia de seguridad concreta en el servidor. Cero significa ilimitada.	`0`
`max_backups_io_thread_pool_size`	ClickHouse utiliza subprocesos del pool de E/S de copias de seguridad para realizar operaciones de E/S de copias de seguridad en S3. `max_backups_io_thread_pool_size` limita el número máximo de subprocesos del pool.	`1000`
`max_backups_io_thread_pool_free_size`	Si el número de hilos inactivos en el pool de hilos de E/S de copias de seguridad supera `max_backup_io_thread_pool_free_size`, ClickHouse liberará los recursos que ocupan los hilos inactivos y reducirá el tamaño del pool. Los hilos pueden volver a crearse si es necesario.	`0`
`backups_io_thread_pool_queue_size`	El número máximo de trabajos que se pueden programar en el Backups IO Thread pool. Se recomienda mantener esta cola sin límite debido a la lógica actual de las copias de seguridad en S3. Nota: Un valor de `0` (predeterminado) significa sin límite.	`0`
`backup_threads`	El número máximo de hilos para ejecutar solicitudes de `BACKUP`.
`max_backup_bandwidth_for_server`	La velocidad máxima de lectura, en bytes por segundo, para todas las copias de seguridad del servidor. Cero significa sin límite.	`0`
`shutdown_wait_backups_and_restores`	Si se establece en true, ClickHouse esperará a que las copias de seguridad y las restauraciones en curso finalicen antes de apagarse.	`1`

Configuración específica de S3

Configuración	Descripción	Valor predeterminado
`use_same_s3_credentials_for_base_backup`	Indica si la copia de seguridad base en S3 debe heredar las credenciales de la consulta. Solo funciona con `S3`.
`s3_storage_class`	La clase de almacenamiento que se utiliza para la copia de seguridad en S3. Por ejemplo: `STANDARD`

Configuración específica de Azure

Configuración	Descripción	Valor predeterminado
`azure_attempt_to_create_container`	Si, al usar Azure Blob Storage, se intentará crear el contenedor especificado si no existe.	`true`

Administración y resolución de problemas

El comando de copia de seguridad devuelve un id y un status, y ese id puede usarse para obtener el estado de la copia de seguridad. Esto es muy útil para comprobar el progreso de copias de seguridad ASYNC prolongadas. El ejemplo siguiente muestra un error que se produjo al intentar sobrescribir un archivo de copia de seguridad existente:

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

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

1 fila en el conjunto. 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.

Junto con la tabla system.backups, todas las operaciones de copia de seguridad y restauración también quedan registradas en la tabla de registro del sistema 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.

Fundamentos

Conceptos de ClickHouse

Buenas prácticas

Copia de seguridad y restauración en ClickHouse

Introducción

Tipos de copias de seguridad

Copias de seguridad síncronas vs. asíncronas

Copias de seguridad concurrentes y no concurrentes

Copias de seguridad comprimidas y sin comprimir

Uso de colecciones con nombre

Copia de seguridad de tablas del sistema, de registro o de gestión de acceso

Sintaxis general

Resumen de comandos

Copia de seguridad de una tabla sin sus datos

Motores que `RESTORE` no puede recrear

Configuración

Administración y resolución de problemas

​Introducción

​Tipos de copias de seguridad

​Copias de seguridad síncronas vs. asíncronas

​Copias de seguridad concurrentes y no concurrentes

​Copias de seguridad comprimidas y sin comprimir

​Uso de colecciones con nombre

​Copia de seguridad de tablas del sistema, de registro o de gestión de acceso

​Sintaxis general

​Resumen de comandos

​Copia de seguridad de una tabla sin sus datos

​Motores que RESTORE no puede recrear

​Configuración

​Administración y resolución de problemas

Introducción

Tipos de copias de seguridad

Copias de seguridad síncronas vs. asíncronas

Copias de seguridad concurrentes y no concurrentes

Copias de seguridad comprimidas y sin comprimir

Uso de colecciones con nombre

Copia de seguridad de tablas del sistema, de registro o de gestión de acceso

Sintaxis general

Resumen de comandos

Copia de seguridad de una tabla sin sus datos

Motores que `RESTORE` no puede recrear

Configuración

Administración y resolución de problemas