> ## Documentation Index > Fetch the complete documentation index at: https://private-7c7dfe99-home-button.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > Descripción general de la copia de seguridad y la restauración en ClickHouse # 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](/es/reference/engines/table-engines/mergetree-family/replication) 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](/es/reference/settings/session-settings#max_table_size_to_drop) 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](/es/concepts/features/backup-restore/local-disk) | 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](/es/concepts/features/backup-restore/s3-endpoint) | Detalla la copia de seguridad/restauración hacia o desde un endpoint de S3 | | [Copia de seguridad/restauración mediante AzureBlobStorage](/es/concepts/features/backup-restore/azure-blob-storage) | Detalla la copia de seguridad/restauración hacia o desde Azure blob storage | | [Métodos alternativos](/es/concepts/features/backup-restore/alternative-methods) | Analiza métodos alternativos de copia de seguridad | | [Snapshot backup](/es/concepts/features/backup-restore/snapshot) | Snapshots ligeros para tablas SharedMergeTree que usan Cloud Object Storage | Las copias de seguridad pueden: * ser [completas o incrementales](#backup-types) * ser [sincrónicas o asincrónicas](#synchronous-vs-asynchronous) * ser [concurrentes o no concurrentes](#concurrent-vs-non-concurrent) * estar [comprimidas o sin comprimir](#compressed-vs-uncompressed) * usar [colecciones con nombre](#using-named-collections) * estar protegidas con contraseña * hacerse de [system tables, log tables o tablas de gestión de acceso](#system-backups)
## 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: ```xml theme={null} false false ``` 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: ```sql theme={null} 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"](/es/concepts/features/configuration/server-config/named-collections) 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"](/es/concepts/features/security/access-rights#enabling-access-control)). 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
```sql theme={null} -- 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('/') | Disk('', '/') | S3('/', '', '', '') | AzureBlobStorage('/', '', '', '', '') --- configuración adicional [SETTINGS ...] [ASYNC] ``` **Consulte ["resumen de comandos"](/es/concepts/features/backup-restore/overview#command-summary) 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 | | | `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('/')` | Almacena en el sistema de archivos local o restaura desde él | | | `Disk('', '/')` | Almacena en un disco configurado o restaura desde él | | | `S3('/', '', '')` | 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ó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"](/es/reference/statements/create/table#column_compression_codec) | | | `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. | | | `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](/es/reference/engines/table-engines/mergetree-family/mergetree#table_engine-mergetree-multiple-volumes). 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: ```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 fila en el conjunto. 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. ``` Junto con la tabla [`system.backups`](/es/reference/system-tables/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`](/es/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. ```