Backup e restauração no ClickHouse

Esta seção apresenta uma visão geral de backups e restaurações no ClickHouse. Para uma descrição mais detalhada de cada método de backup, consulte as páginas dos métodos específicos na barra lateral.

Introdução

Embora a replicação ofereça proteção contra falhas de hardware, ela não protege contra erros humanos: exclusão acidental de dados, exclusão da tabela errada ou de uma tabela no cluster errado, e bugs de software que resultam em processamento incorreto de dados ou corrupção de dados. Em muitos casos, erros como esses afetam todas as réplicas. O ClickHouse tem salvaguardas integradas para evitar alguns tipos de erro; por exemplo, por padrão você não pode simplesmente excluir tabelas com um motor da família MergeTree contendo mais de 50 Gb de dados. No entanto, essas salvaguardas não cobrem todos os casos possíveis, e problemas ainda podem ocorrer. Para mitigar com eficácia possíveis erros humanos, você deve preparar cuidadosamente uma estratégia de backup e restauração dos seus dados com antecedência. Cada empresa tem recursos disponíveis e requisitos de negócio diferentes, portanto não há uma solução universal de backups e restaurações do ClickHouse que sirva para todas as situações. O que funciona para um gigabyte de dados provavelmente não funcionará para dezenas de petabytes de dados. Há várias abordagens possíveis, cada uma com seus próprios prós e contras, que são apresentadas nesta seção da documentação. É uma boa ideia usar várias abordagens em vez de apenas uma, para compensar suas diferentes limitações.

Lembre-se de que, se você fez backup de algo e nunca tentou restaurá-lo, há grandes chances de que a restauração não funcione corretamente quando você realmente precisar dela (ou, pelo menos, leve mais tempo do que a empresa pode tolerar). Portanto, qualquer que seja a abordagem de backup escolhida, certifique-se de automatizar também o processo de restauração e pratique-o regularmente em um cluster ClickHouse de contingência.

As páginas a seguir detalham os vários métodos de backup e restauração disponíveis no ClickHouse:

Página	Descrição
Backup/restore using local disk or S3 disk	Detalha o backup/restauração para ou a partir de um disco local ou disco S3
Backup/restore using S3 endpoint	Detalha o backup/restauração para ou a partir de um endpoint S3
Backup/restore using AzureBlobStorage	Detalha o backup/restauração para ou a partir do Azure Blob Storage
Alternative methods	Discute métodos alternativos de backup
Snapshot backup	Snapshots leves para tabelas SharedMergeTree usando armazenamento de objetos em nuvem

Os backups podem:

ser completos ou incrementais
ser síncronos ou assíncronos
ser concorrentes ou não concorrentes
ser compactados ou não compactados
usar coleções nomeadas
ser protegidos por senha
incluir tabelas de sistema, tabelas de log ou tabelas de gerenciamento de acesso

Tipos de backup

Os backups podem ser completos ou incrementais. Os backups completos são uma cópia completa dos dados, enquanto os backups incrementais contêm apenas as alterações nos dados desde o último backup completo. Os backups completos têm a vantagem de serem um método de recuperação simples, independente (de outros backups) e confiável. No entanto, podem levar muito tempo para serem concluídos e podem consumir muito espaço. Os backups incrementais, por outro lado, são mais eficientes tanto em termos de tempo quanto de espaço, mas a restauração dos dados exige que todos os backups estejam disponíveis. Dependendo das suas necessidades, você pode optar por usar:

Backups completos para bancos de dados menores ou dados críticos.
Backups incrementais para bancos de dados maiores ou quando os backups precisam ser feitos com frequência e com bom custo-benefício.
Ambos, por exemplo, backups completos semanais e backups incrementais diários.

Backups síncronos vs. assíncronos

Os comandos BACKUP e RESTORE também podem ser marcados como ASYNC. Nesse caso, o comando de backup retorna imediatamente, e o processo de backup é executado em segundo plano. Se os comandos não forem marcados como ASYNC, o processo de backup será síncrono, e o comando ficará bloqueado até que o backup seja concluído.

Backups concorrentes vs. não concorrentes

Por padrão, o ClickHouse permite backups e restaurações concorrentes. Isso significa que você pode iniciar várias operações de backup ou restauração simultaneamente. No entanto, há configurações no nível do servidor que permitem desativar esse comportamento. Se você definir essas configurações como false, apenas uma operação de backup ou restauração poderá ser executada em um cluster por vez. Isso pode ajudar a evitar contenção de recursos ou possíveis conflitos entre operações. Para desativar backups/restaurações concorrentes, você pode usar estas configurações, respectivamente:

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

O valor padrão de ambos é true, então, por padrão, backups/restaurações concorrentes são permitidos. Quando essas configurações são false em um cluster, apenas um único backup/restauração pode ser executado no cluster por vez.

Backups compactados vs. não compactados

Os backups do ClickHouse suportam compactação por meio das configurações compression_method e compression_level. Ao criar um backup, você pode especificar:

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

Usando coleções nomeadas

Coleções nomeadas permitem armazenar pares chave-valor (como credenciais do S3, endpoints e configurações) que podem ser reutilizados em operações de backup e restauração. Elas ajudam a:

Ocultar credenciais de usuários sem acesso de Admin
Simplificar comandos armazenando configurações complexas de forma centralizada
Manter a consistência entre as operações
Evitar a exposição de credenciais nos logs de consultas

Consulte “coleções nomeadas” para mais detalhes.

Backup de tabelas de sistema, de log ou de gerenciamento de acesso

As tabelas de sistema também podem ser incluídas nos seus fluxos de trabalho de backup e restauração, mas isso depende do seu caso de uso específico. Tabelas de sistema que armazenam dados históricos, como aquelas com o sufixo _log (por exemplo, query_log, part_log), podem ser submetidas a backup e restauração como qualquer outra tabela. Se o seu caso de uso depender da análise de dados históricos — por exemplo, usar query_log para acompanhar o desempenho de consultas ou depurar problemas —, é recomendável incluir essas tabelas na sua estratégia de backup. No entanto, se os dados históricos dessas tabelas não forem necessários, elas podem ser excluídas para economizar espaço de armazenamento de backup. Tabelas de sistema relacionadas ao gerenciamento de acesso, como usuários, roles, row_policies, settings_profiles e quotas, recebem tratamento especial durante as operações de backup e restauração. Quando essas tabelas são incluídas em um backup, seu conteúdo é exportado para um arquivo especial accessXX.txt, que contém as instruções SQL equivalentes para criar e configurar as entidades de acesso. Durante a restauração, o processo interpreta esses arquivos e reaplica os comandos SQL para recriar os usuários, roles e outras configurações. Esse recurso garante que a configuração de controle de acesso de um cluster ClickHouse possa ser submetida a backup e restauração como parte da configuração geral do cluster. Essa funcionalidade só funciona para configurações gerenciadas por meio de comandos SQL (chamadas de “Controle de acesso e gerenciamento de contas orientados por SQL”). As configurações de acesso definidas em arquivos de configuração do servidor ClickHouse (por exemplo, users.xml) não são incluídas em backups e não podem ser restauradas por esse método.

Sintaxe geral

-- 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 “resumo dos comandos” para obter mais detalhes sobre cada comando.

Resumo dos comandos

Cada um dos comandos acima é detalhado a seguir:

Comando	Descrição
`BACKUP`	Cria um backup dos objetos especificados
`RESTORE`	Restaura objetos de um backup
`TABLE [db.]table_name [AS [db.]table_name_in_backup]`	Faz backup/restauração de uma tabela específica (pode ser renomeada)
`[PARTITION[S] partition_expr [,...]]`	Faz backup/restauração apenas de partições específicas da tabela
`DICTIONARY [db.]dictionary_name [AS [db.]name_in_backup]`	Faz backup/restauração de um objeto de Dicionário
`DATABASE database_name [AS database_name_in_backup]`	Faz backup/restauração de um banco de dados inteiro (pode ser renomeado)
`TEMPORARY TABLE table_name [AS table_name_in_backup]`	Faz backup/restauração de uma tabela temporária (pode ser renomeada)
`VIEW view_name [AS view_name_in_backup]`	Faz backup/restauração de uma view (pode ser renomeada)
`[EXCEPT TABLES ...]`	Exclui tabelas específicas ao fazer backup de um banco de dados
`[EXCEPT DATA FROM {TABLE\|TABLES} ...]`	(Apenas BACKUP) Faz backup da definição de uma tabela sem suas linhas. Difere de `EXCEPT TABLES`, que omite a tabela por completo. Aplica-se apenas ao elemento em que é especificado: consulte Como fazer backup de uma tabela sem seus dados.
`ALL`	Faz backup/restauração de tudo (todos os bancos de dados, tabelas etc.). Antes da versão 23.4 do ClickHouse, `ALL` se aplicava apenas ao comando `RESTORE`.
`[EXCEPT {TABLES\|DATABASES}...]`	Exclui tabelas ou bancos de dados específicos ao usar `ALL`
`[ON CLUSTER 'cluster_name']`	Executa o backup/restauração em todo o cluster do ClickHouse
`TO\|FROM`	Direção: `TO` para o destino do backup, `FROM` para a origem da restauração
`File('<path>/<filename>')`	Armazena no/restaura do sistema de arquivos local
`Disk('<disk_name>', '<path>/')`	Armazena em/restaura de um disco configurado
`S3('<S3 endpoint>/<path>', '<Access key ID>', '<Secret access key>')`	Armazena no/restaura do Amazon S3 ou de armazenamento compatível com S3
`[SETTINGS ...]`	Veja abaixo a lista completa de configurações
`[ASYNC]`	Faz com que a operação seja executada de forma assíncrona (retorna imediatamente com um ID que você pode monitorar)

Fazer backup de uma tabela sem seus dados

EXCEPT DATA FROM {TABLE|TABLES} inclui no backup a definição de uma tabela, mas não suas linhas. Isso é útil para tabelas cujo conteúdo pode ser regenerado após uma restauração, como as tabelas de destino de visões materializadas. A cláusula determina o que BACKUP grava, mas não altera o que RESTORE pode fazer com o resultado. Se RESTORE puder recriar a tabela, a definição sem linhas será restaurada como uma tabela vazia. Isso não permite restaurar uma tabela que, de outra forma, não poderia ser restaurada: a possibilidade de recriar uma tabela a partir da definição no backup depende do motor, e alguns motores não permitem essa operação. Consulte Motores que RESTORE não pode recriar. A cláusula se aplica apenas ao elemento em que é especificada:

Em um elemento DATABASE ou ALL, ela pode indicar qualquer tabela incluída no backup por esse elemento:

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

Nessa lista, coloque entre crases o nome de uma tabela ou banco de dados chamado table, dictionary, view, database ou all: após uma vírgula, um nome sem crases é interpretado como o início do próximo elemento.

Em um elemento que se refere a um único objeto (TABLE, DICTIONARY, VIEW, TEMPORARY TABLE), somente o objeto desse elemento está no escopo; portanto, a cláusula deve especificar apenas esse objeto. Use um elemento e uma cláusula para cada tabela:

-- 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/')

Se uma tabela for especificada tanto em um elemento próprio quanto na cláusula EXCEPT DATA FROM de um elemento mais abrangente, seus dados são incluídos no backup: ao especificar uma tabela, o elemento também solicita seus dados. Isso segue o comportamento de EXCEPT TABLES, em que uma tabela especificada explicitamente é incluída no backup mesmo que um elemento mais abrangente a exclua. Os dados da tabela interna de uma visão materializada (ou das tabelas internas de uma tabela TimeSeries) são excluídos pelo nome do objeto externo; a cláusula não aceita nomes de tabelas internas. EXCEPT DATA FROM {TABLE|TABLES} só é válido para BACKUP. RESTORE rejeita essa cláusula, em vez de aceitá-la como uma operação sem efeito.

Motores que `RESTORE` não consegue recriar

Alguns motores não podem ser recriados por RESTORE, com ou sem EXCEPT DATA FROM {TABLE|TABLES}. Para essas tabelas, a cláusula ainda controla o tamanho do backup, mas não permite restaurá-las vazias — a tabela não é restaurada, pois RESTORE se recusa a criá-la. O caso a destacar é o de uma tabela MaterializedPostgreSQL independente. Assim que fosse criada, ela começaria a replicar dados da origem PostgreSQL ativa, misturando o snapshot do backup com o estado remoto atual. Por isso, RESTORE a rejeita na fábrica de armazenamento — antes que a tabela seja criada — com NOT_IMPLEMENTED. Essa é uma característica do motor e também se aplica a um backup completo comum. O procedimento aceito é restaurar com outro nome, em uma tabela ReplacingMergeTree criada previamente com a estrutura da tabela aninhada (incluindo as colunas _sign e _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 é necessário porque a definição armazenada no backup usa o motor MaterializedPostgreSQL, mas a restauração é feita intencionalmente em um ReplacingMergeTree comum. Sem EXCEPT DATA FROM TABLE, o mesmo RESTORE também restaura as linhas.

Configurações

Configurações genéricas de backup e restauração

Configuração	Descrição	Valor padrão
`id`	ID da operação de backup ou de restauração; se não for especificado, será usado um UUID gerado aleatoriamente. Se já houver uma operação em execução com o mesmo ID, uma exceção será lançada.
`compression_method`	Especifica o método de compressão para o backup. Consulte a seção “codecs de compressão de coluna”
`compression_level`	Especifica o nível de compressão do backup
`password`	Senha do arquivo de backup. Suportado apenas para arquivos ZIP (`.zip`, `.zipx`).
`base_backup`	O destino do backup base usado em backups incrementais. Por exemplo: `Disk('backups', '1.zip')`
`use_same_password_for_base_backup`	Indica se o arquivo do backup base deve herdar a senha da consulta.
`structure_only`	Se habilitado, faz backup ou restaura apenas as instruções CREATE, sem os dados da tabela.
`restore_table_data`	Indica se os dados das tabelas devem ser restaurados. Aplicável apenas ao comando `RESTORE`. Quando não definido, o padrão é `NOT structure_only`; defini-lo explicitamente substitui `structure_only`. Consulte “Configurações de restauração”.
`restore_access_entities`	Indica se as entidades de acesso (usuários, funções, perfis de configuração, políticas de linha, cotas) devem ser restauradas. Aplicável apenas ao comando `RESTORE`. Quando não definido, o padrão é `NOT structure_only`; defini-lo explicitamente substitui `structure_only`. Consulte “Configurações de restauração”.
`restore_functions`	Indica se as funções definidas pelo usuário devem ser restauradas. Aplicável apenas ao comando `RESTORE`. Quando não definido, o padrão é `NOT structure_only`; defini-lo explicitamente substitui `structure_only`. Consulte “Configurações de restauração”.
`storage_policy`	Política de armazenamento para as tabelas que estão sendo restauradas. Consulte “uso de vários dispositivos de bloco para armazenar dados. Aplicável apenas ao comando `RESTORE`. Aplica-se somente a tabelas com um engine da família `MergeTree`.
`allow_non_empty_tables`	Permite que `RESTORE TABLE` insira dados em tabelas não vazias. Isso combinará os dados já existentes na tabela com os dados extraídos do backup. Portanto, essa configuração pode causar duplicação de dados na tabela; use com cautela.	`0`
`backup_restore_keeper_max_retries`	Número máximo de tentativas para operações do [Zoo]Keeper no decorrer de uma operação de BACKUP ou RESTORE. Deve ser alto o suficiente para que toda a operação não falhe por causa de uma falha temporária do [Zoo]Keeper.	`1000`
`backup_restore_keeper_retry_initial_backoff_ms`	Timeout de backoff inicial para operações do [Zoo]Keeper durante backup ou restore	`100`
`backup_restore_keeper_retry_max_backoff_ms`	Timeout máximo de backoff para operações do [Zoo]Keeper durante backup ou restore	`5000`
`backup_restore_failure_after_host_disconnected_for_seconds`	Se um host, durante uma operação `BACKUP ON CLUSTER` ou `RESTORE ON CLUSTER`, não recriar seu nó efêmero ‘alive’ no ZooKeeper dentro desse período, todo o backup ou restore será considerado como falho. Esse valor deve ser maior do que qualquer tempo razoável para um host se reconectar ao ZooKeeper após uma falha. Zero significa ilimitado.	`3600`
`backup_restore_keeper_max_retries_while_initializing`	Máximo de novas tentativas para operações do [Zoo]Keeper durante a inicialização de uma operação `BACKUP ON CLUSTER` ou `RESTORE ON CLUSTER`.	`20`
`backup_restore_keeper_max_retries_while_handling_error`	Número máximo de tentativas para operações do [Zoo]Keeper ao tratar um erro em uma operação `BACKUP ON CLUSTER` ou `RESTORE ON CLUSTER`.	`20`
`backup_restore_finish_timeout_after_error_sec`	Por quanto tempo o initiator deve esperar que os outros hosts reajam ao nó ‘error’ e interrompam seu trabalho na operação atual de `BACKUP ON CLUSTER` ou `RESTORE ON CLUSTER`.	`180`
`backup_restore_keeper_value_max_size`	Tamanho máximo dos dados de um nó do [Zoo]Keeper durante o backup	`1048576`
`backup_restore_batch_size_for_keeper_multi`	Tamanho máximo do lote para solicitação múltipla ao [Zoo]Keeper durante backup ou restauração	`1000`
`backup_restore_batch_size_for_keeper_multiread`	Tamanho máximo do lote para solicitação de multileitura ao [Zoo]Keeper durante backup ou restauração	`10000`
`backup_restore_keeper_fault_injection_probability`	Probabilidade aproximada de falha de uma solicitação ao Keeper durante o backup ou a restauração. O valor válido está no intervalo `[0.0f, 1.0f]`	`0`
`backup_restore_keeper_fault_injection_seed`	`0` para uma semente aleatória; caso contrário, o valor da configuração	`0`
`backup_restore_s3_retry_attempts`	Configuração de Aws::Client::RetryStrategy; o Aws::Client faz as novas tentativas por conta própria, e 0 significa nenhuma nova tentativa. Isso se aplica apenas a backup/restauração.	`1000`
`max_backup_bandwidth`	Velocidade máxima de leitura, em bytes por segundo, para um backup específico no servidor. Zero significa ilimitada.	`0`
`max_backups_io_thread_pool_size`	O ClickHouse usa threads do pool de threads de E/S de backups para realizar operações de E/S de backup no S3. `max_backups_io_thread_pool_size` limita o número máximo de threads no pool.	`1000`
`max_backups_io_thread_pool_free_size`	Se o número de threads ociosas no Backups IO Thread pool exceder `max_backup_io_thread_pool_free_size`, ClickHouse liberará os recursos ocupados pelas threads ociosas e reduzirá o tamanho do pool. As threads poderão ser criadas novamente, se necessário.	`0`
`backups_io_thread_pool_queue_size`	O número máximo de jobs que podem ser agendados no Backups IO Thread pool. Recomenda-se manter esta fila sem limite devido à lógica atual de backups no S3. Observação: um valor de `0` (padrão) significa sem limite.	`0`
`backup_threads`	O número máximo de threads para executar solicitações `BACKUP`.
`max_backup_bandwidth_for_server`	A velocidade máxima de leitura, em bytes por segundo, para todos os backups no servidor. Zero significa ilimitado.	`0`
`shutdown_wait_backups_and_restores`	Se definido como true, o ClickHouse aguardará a conclusão dos backups e restaurações em execução antes de ser desligado.	`1`

Configurações específicas do S3

Configuração	Descrição	Valor padrão
`use_same_s3_credentials_for_base_backup`	Se o backup base no S3 deve herdar as credenciais da consulta. Funciona apenas com `S3`.
`s3_storage_class`	A classe de armazenamento usada para backup no S3. Por exemplo: `STANDARD`

Configurações específicas do Azure

Configuração	Descrição	Valor padrão
`azure_attempt_to_create_container`	Ao usar o Azure Blob Storage, indica se deve haver uma tentativa de criar o contêiner especificado caso ele não exista.	`true`

Administração e solução de problemas

O comando de backup retorna um id e um status, e esse id pode ser usado para consultar o status do backup. Isso é muito útil para verificar o andamento de backups longos ASYNC. O exemplo abaixo mostra uma falha que ocorreu ao tentar sobrescrever um arquivo de backup existente:

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.

Além da tabela system.backups, todas as operações de backup e restauração também são registradas na tabela de log do 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

Conceitos do ClickHouse

Boas práticas

Introdução

Tipos de backup

Backups síncronos vs. assíncronos

Backups concorrentes vs. não concorrentes

Backups compactados vs. não compactados

Usando coleções nomeadas

Backup de tabelas de sistema, de log ou de gerenciamento de acesso

Sintaxe geral

Resumo dos comandos

Fazer backup de uma tabela sem seus dados

Motores que `RESTORE` não consegue recriar

Configurações

Administração e solução de problemas

​Introdução

​Tipos de backup

​Backups síncronos vs. assíncronos

​Backups concorrentes vs. não concorrentes

​Backups compactados vs. não compactados

​Usando coleções nomeadas

​Backup de tabelas de sistema, de log ou de gerenciamento de acesso

​Sintaxe geral

​Resumo dos comandos

​Fazer backup de uma tabela sem seus dados

​Motores que RESTORE não consegue recriar

​Configurações

​Administração e solução de problemas

Introdução

Tipos de backup

Backups síncronos vs. assíncronos

Backups concorrentes vs. não concorrentes

Backups compactados vs. não compactados

Usando coleções nomeadas

Backup de tabelas de sistema, de log ou de gerenciamento de acesso

Sintaxe geral

Resumo dos comandos

Fazer backup de uma tabela sem seus dados

Motores que `RESTORE` não consegue recriar

Configurações

Administração e solução de problemas