system.backups

Tabla del sistema que contiene registros con información sobre las operaciones BACKUP y RESTORE.

​

Descripción

Contiene una lista de todas las operaciones BACKUP o RESTORE, con sus estados actuales y otras propiedades. Tenga en cuenta que esta tabla no es persistente y solo muestra las operaciones ejecutadas después del último reinicio del servidor.

​

Columnas

• id (String) — ID de la operación; puede proporcionarse mediante SETTINGS id=… o generarse como un UUID aleatorio.
• name (String) — Nombre de la operación, una cadena como Disk('backups', 'my_backup')
• base_backup_name (String) — Nombre de la operación de copia de seguridad base, una cadena como Disk('backups', 'my_base_backup')
• query_id (String) — ID de la consulta que inició la copia de seguridad.
• status (Enum8(‘CREATING_BACKUP’ = 0, ‘BACKUP_CREATED’ = 1, ‘BACKUP_FAILED’ = 2, ‘RESTORING’ = 3, ‘RESTORED’ = 4, ‘RESTORE_FAILED’ = 5, ‘BACKUP_CANCELLED’ = 6, ‘RESTORE_CANCELLED’ = 7)) — Estado de la operación de copia de seguridad o restauración.
• error (String) — El mensaje de error, si lo hay.
• start_time (DateTime64(6)) — La hora de inicio de la operación.
• end_time (DateTime64(6)) — La hora de finalización de la operación.
• num_files (UInt64) — Número de archivos almacenados en la copia de seguridad.
• total_size (UInt64) — Tamaño total de los archivos almacenados en la copia de seguridad.
• num_entries (UInt64) — Número de entradas de la copia de seguridad; es decir, el número de archivos de la carpeta si la copia de seguridad se almacena como carpeta.
• uncompressed_size (UInt64) — Tamaño sin comprimir de la copia de seguridad.
• compressed_size (UInt64) — Tamaño comprimido de la copia de seguridad.
• files_read (UInt64) — Devuelve el número de archivos leídos durante RESTORE desde esta copia de seguridad.
• bytes_read (UInt64) — Devuelve el tamaño total de los archivos leídos durante RESTORE desde esta copia de seguridad.
• ProfileEvents (Map(LowCardinality(String), UInt64)) — Todos los eventos de perfil registrados durante esta operación.
• settings (Map(LowCardinality(String), String)) — Configuración específica de la copia de seguridad o restauración utilizada para esta operación (procedente de la cláusula SETTINGS, incluidos los valores predeterminados). No se exponen los ajustes confidenciales.
• engine_settings (Map(LowCardinality(String), String)) — Configuración utilizada por el lector/escritor del motor de copia de seguridad (por ejemplo, allow_native_copy de S3). Está vacío cuando la operación implica más de un motor y no puede representarse mediante un mapa plano: copias de seguridad incrementales y restauraciones, restauraciones de instantáneas ligeras y operaciones ON CLUSTER no internas.

​

Atomicidad de la restauración

RESTORE no es transaccional y no revierte los cambios en caso de error. En cada tabla, todas las partes seleccionadas se copian antes de adjuntar cualquiera de ellas, pero la fase de adjuntar en sí no es transaccional: las partes pasan a ser visibles una a una. Las tablas se procesan de forma independiente.

Las tablas son independientes. Una tabla cuya restauración se completa permanece en su lugar aunque más adelante falle otra tabla del mismo comando:

RESTORE TABLE db.t0, TABLE db.t1
FROM S3('<endpoint>', '<access_key>', '<secret_key>')
SETTINGS
    allow_non_empty_tables = true;

Si este comando falla después de que db.t0 se haya restaurado por completo, pero db.t1 aún no haya terminado, db.t0 sigue restaurada.

La cláusula PARTITIONS no marca un límite de commit. Solo selecciona qué partes de una tabla se restauran:

RESTORE TABLE db.t0 PARTITIONS '2026-06-01', '2026-06-02', '2026-06-03'
FROM S3('<endpoint>', '<access_key>', '<secret_key>')
SETTINGS
    allow_non_empty_tables = true;

Primero se copian todas las partes seleccionadas de la tabla y solo se adjuntan cuando todas están listas. Por lo tanto, si este comando falla durante la fase de copia —por ejemplo, después de que la partición 2026-06-01 se haya copiado por completo pero 2026-06-02 y 2026-06-03 no hayan terminado— entonces no se hace commit de 2026-06-01 y la tabla queda sin datos restaurados por este comando. Una vez que finaliza la fase de copia y comienza el paso de adjuntar, se hace commit de las partes de una en una, por lo que un fallo durante el adjuntar puede dejar la tabla parcialmente restaurada, sin rollback.

Para hacer commit de las particiones de forma independiente (de modo que una partición completada sobreviva a un fallo posterior y pueda reintentarse de forma aislada), ejecute un RESTORE independiente por partición, usando SETTINGS allow_non_empty_tables = true después de la primera.