Protecting self-managed ClickHouse against deletion, corruption and site loss with BACKUP and RESTORE, part freezes, source replay and regular restore tests.
Choosing backup methods, frequency and retention for a self-managed ClickHouse cluster: what replication does not cover, full and incremental schedules, recovery point and time objectives, and combining methods.
Writing ClickHouse backups to Amazon S3 or S3-compatible storage such as MinIO or Ceph: credentials in named collections, password protection, asynchronous backups and tracking progress in system.backups.
Using base_backup to take incremental ClickHouse backups: chain length, storage savings, restore dependencies, and periodic full backups to limit risk.
Running ClickHouse BACKUP and RESTORE against Azure Blob Storage containers: connection strings, container layout, and restore tests for clusters hosted on Azure.
Partition-level backups with FREEZE and hard links, copying the shadow directory off the server, restoring with ATTACH PARTITION, and when tools such as clickhouse-backup automate it.
Proving backups work: automated restores to a spare cluster, partial and table-level restores, restore settings, verifying row counts and checksums, and recording evidence for audits.
Including SQL-managed users, roles, row policies, quotas and settings profiles in ClickHouse backups, plus the config.d and users.d files that live outside the database.
Keeping a second copy of the ingestion stream in object storage or HDFS so ClickHouse tables can be rebuilt after corruption, and how retention on the stream sets the recovery window.
Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.