Saltar al contenido principal
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áginaDescripción
Copia de seguridad/restauración con disco local o disco S3Detalla la copia de seguridad/restauración hacia o desde un disco local o un disco S3
Copia de seguridad/restauración mediante endpoint de S3Detalla la copia de seguridad/restauración hacia o desde un endpoint de S3
Copia de seguridad/restauración mediante AzureBlobStorageDetalla la copia de seguridad/restauración hacia o desde Azure blob storage
Métodos alternativosAnaliza métodos alternativos de copia de seguridad
Snapshot backupSnapshots ligeros para tablas SharedMergeTree que usan Cloud Object Storage
Las copias de seguridad pueden:

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

-- comandos principales
BACKUP | RESTORE 
--- qué respaldar/restaurar (o excluir)
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']
--- dónde respaldar o restaurar (destino u origen)
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>')
--- configuración adicional
[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:
ComandoDescripción
BACKUPCrea una copia de seguridad de los objetos especificados
RESTORERestaura 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
ALLHace 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|FROMDirecció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)

Configuración

Configuración general de copia de seguridad y restauración
ConfiguraciónDescripciónValor predeterminado
idID 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_methodEspecifica el método de compresión para la copia de seguridad. Consulte la sección “codecs de compresión de columnas”
compression_levelEspecifica el nivel de compresión de la copia de seguridad
passwordContraseña del archivo de copia de seguridad. Solo se admite en archivos ZIP (.zip, .zipx).
base_backupEl 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_backupIndica si el archivo de la copia de seguridad base debe heredar la contraseña de la consulta.
structure_onlySi se habilita, solo realiza la copia de seguridad o la restauración de las sentencias CREATE, sin los datos reales de la tabla.
storage_policyPolí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_tablesPermite 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_retriesNú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_msTiempo de espera del backoff inicial para las operaciones de [Zoo]Keeper durante BACKUP o RESTORE100
backup_restore_keeper_retry_max_backoff_msTiempo de espera máximo del backoff para las operaciones de [Zoo]Keeper durante BACKUP o RESTORE5000
backup_restore_failure_after_host_disconnected_for_secondsSi 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_initializingMá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_errorNú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_secCuá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_sizeTamaño máximo de los datos de un nodo de [Zoo]Keeper durante BACKUP1048576
backup_restore_batch_size_for_keeper_multiTamaño máximo del lote para solicitudes múltiples a [Zoo]Keeper durante la copia de seguridad o la restauración1000
backup_restore_batch_size_for_keeper_multireadTamaño máximo del lote para solicitudes de lectura múltiple a [Zoo]Keeper durante la copia de seguridad o la restauración10000
backup_restore_keeper_fault_injection_probabilityProbabilidad 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_seed0 para una semilla aleatoria; de lo contrario, el valor de la configuración0
backup_restore_s3_retry_attemptsConfiguració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_bandwidthVelocidad 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_sizeClickHouse 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_sizeSi 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_sizeEl 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_threadsEl número máximo de hilos para ejecutar solicitudes de BACKUP.
max_backup_bandwidth_for_serverLa 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_restoresSi 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ónDescripciónValor predeterminado
use_same_s3_credentials_for_base_backupIndica si la copia de seguridad base en S3 debe heredar las credenciales de la consulta. Solo funciona con S3.
s3_storage_classLa clase de almacenamiento que se utiliza para la copia de seguridad en S3. Por ejemplo: STANDARD
Configuración específica de Azure
ConfiguraciónDescripciónValor predeterminado
azure_attempt_to_create_containerSi, 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.
Última modificación el 10 de junio de 2026