While [replication](table_engines/replication.md#table_engines-replication) provides protection from hardware failures, it does not protect against human errors: accidentally deleting data, deleting the wrong table or on the wrong cluster, software bugs leading to incorrect data processing or data corruption. In many cases commands like these will affect all replicas. ClickHouse has built-in safeguards to prevent some of mistakes, for example by default [you can't just drop tables with MergeTree-like engine containing more than 50Gb of data](https://github.com/yandex/ClickHouse/blob/v18.14.18-stable/dbms/programs/server/config.xml), but they don't cover all possible cases and can be circumvented.
While [replication](../table_engines/replication.md#table_engines-replication) provides protection from hardware failures, it does not protect against human errors: accidental deletion of data, deletion of the wrong table or a table on the wrong cluster, and software bugs that result in incorrect data processing or data corruption. In many cases mistakes like these will affect all replicas. ClickHouse has built-in safeguards to prevent some types of mistakes — for example, by default [you can't just drop tables with a MergeTree-like engine containing more than 50 Gb of data](https://github.com/yandex/ClickHouse/blob/v18.14.18-stable/dbms/programs/server/config.xml#L322-L330). However, these safeguards don't cover all possible cases and can be circumvented.
So in order to effectively mitigate possible human errors, you should carefully prepare your backup and restore strategy **in advance**.
In order to effectively mitigate possible human errors, you should carefully prepare a strategy for backing up and restoring your data **in advance**.
Each company has different resources available and different business requirements so there's no universal solution for ClickHouse backups and restores that will fit any situation. What works for gigabyte of data likely won't work for tens of petabytes. There are different possible approaches with their own pros and cons, which will be discussed below. Often it makes to employ few of those instead of just one to compensate their trade-offs.
Each company has different resources available and different business requirements, so there's no universal solution for ClickHouse backups and restores that will fit every situation. What works for one gigabyte of data likely won't work for tens of petabytes. There are a variety of possible approaches with their own pros and cons, which will be discussed below. It is often a good idea to use several approaches instead of just one in order to compensate for their various shortcomings.
!!! note "Note"
Keep in mind that if you backed something up and never tried to restore it, chances are that restore will not work properly when you'll need it (or at least will take longer than business can tolerate). So whatever backup approach you'll choose, make sure to automate restore process too and practice it on spare ClickHouse cluster regularly.
Keep in mind that if you backed something up and never tried to restore it, chances are that restore will not work properly when you actually need it (or at least it will take longer than business can tolerate). So whatever backup approach you choose, make sure to automate the restore process as well, and practice it on a spare ClickHouse cluster regularly.
## Duplicating Source Data Somewhere Else
Often data that is ingested into ClickHouse is delivered through some sort of persistent queue, for example [Apache Kafka](https://kafka.apache.org). In this case it is possible to set up additional set of subscribers that will read same data stream as is written to ClickHouse and store it in some cold storage. Most companies already have some default recommended cold storage, it could be an object store or a distributed filesystem, for example [HDFS](https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html).
Often data that is ingested into ClickHouse is delivered through some sort of persistent queue, such as [Apache Kafka](https://kafka.apache.org). In this case it is possible to configure an additional set of subscribers that will read the same data stream while it is being written to ClickHouse and store it in cold storage somewhere. Most companies already have some default recommended cold storage, which could be an object store or a distributed filesystem like [HDFS](https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html).
## Filesystem Snapshots
Some local filesystems provide functionality to create snapshots, for example [ZFS](https://en.wikipedia.org/wiki/ZFS), but they might be not best choice for serving live queries. Possible solution is to create additional replicas with this kind of filesystems and exclude them from distributed tables that are used for SELECT queries. Snapshots on such replicas will be out of reach of any queries modifying data. As a bonus these replicas might have different hardware configuration with much more disks attached per server, which will be cost-effective.
Some local filesystems provide snapshot functionality (for example, [ZFS](https://en.wikipedia.org/wiki/ZFS)), but they might not be the best choice for serving live queries. A possible solution is to create additional replicas with this kind of filesystem and exclude them from distributed tables that are used for SELECT queries. Snapshots on such replicas will be out of reach of any queries that modify data. As a bonus, these replicas might have different hardware configurations with more disks attached per server, which would be cost-effective.
## clickhouse-copier
[clickhouse-copier](utils/clickhouse-copier.md) is a versatile tool initially created to re-shard petabytes-sized tables, but it can be used for backup and restore purposes as well because it just reliably copies data between ClickHouse tables and clusters.
[clickhouse-copier](utils/clickhouse-copier.md) is a versatile tool that was initially created to re-shard petabyte-sized tables. It can also be used for backup and restore purposes because it reliably copies data between ClickHouse tables and clusters.
For smaller volumes of data simple `INSERT INTO ... SELECT ...` to remote tables might work as well.
For smaller volumes of data, a simple `INSERT INTO ... SELECT ...` to remote tables might work as well.
## Manipulations with Parts
ClickHouse allows to create a local copy of table partitions using `ALTER TABLE ... FREZE PARTITION ...` query. It's implemented using hardlinks to `/var/lib/clickhouse/shadow/` folder, so for old data it usually does not consume extra disk space. As created file copies are no longer touched by ClickHouse server, you can just leave them there: it's still be a simple backup that doesn't require any additional external system, but will be prone to hardware issues since. It's better to remotely copy them somewhere and then probably remove the local copies. Distributed filesystems and object stores are still a good options for this, but normal file servers attached with large enough capacity might work as well (in this case the transfer will happen via network filesystem or maybe [rsync](https://en.wikipedia.org/wiki/Rsync)).
ClickHouse allows using the `ALTER TABLE ... FREZE PARTITION ...` query to create a local copy of table partitions. This is implemented using hardlinks to the `/var/lib/clickhouse/shadow/` folder, so it usually does not consume extra disk space for old data. The created copies of files are not handled by ClickHouse server, so you can just leave them there: you will have a simple backup that doesn't require any additional external system, but it will still be prone to hardware issues. For this reason, it's better to remotely copy them to another location and then remove the local copies. Distributed filesystems and object stores are still a good options for this, but normal attached file servers with a large enough capacity might work as well (in this case the transfer will occur via the network filesystem or maybe [rsync](https://en.wikipedia.org/wiki/Rsync)).
More details on queries related to partition manipulations can be found in [respective section of ALTER documentation](../query_language/alter.md).
For more information about queries related to partition manipulations, see the [ALTER documentation](../query_language/alter.md#query_language-manipulation-with-partitions-and-parts).
There's a third-party tool to automate this approach: [clickhouse-backup](https://github.com/AlexAkulov/clickhouse-backup).
A third-party tool is available to automate this approach: [clickhouse-backup](https://github.com/AlexAkulov/clickhouse-backup).
## Data Dump
[Console client](../interfaces/cli.md) can be used to run queries like `SELECT * FROM my_table;` to dump the tables into files using any of the [supported serialization formats](../interfaces/formats.md#formats). Though if you are using ClickHouse as intended and have large enough volumes of data, this will hardly be practical.
