Definitions
It is helpful to cover some definitions first. RPO (Recovery Point Objective): The maximum acceptable data loss measured in time following a disruptive event. Example: An RPO of 30 mins means that in the event of a failure the DB should be restorable to data no older than 30 mins. This, of course, depends on how frequently backups are taken. RTO (Recovery Time Objective): The maximum allowable downtime before normal operations must resume following an outage. Example: An RTO of 30 mins means that in the event of a failure, the team is able to restore data and applications and get normal operations going within 30 mins. Database Backups and Snapshots: Backups provide durable long-term storage with a separate copy of the data. Snapshots don’t create an additional copy of the data, are usually faster, and provide better RPOs.Database backups
Having a backup of your primary service is an effective way to utilize the backup and restore from it in the event of primary service downtime. ClickHouse Cloud supports the following capabilities for backups.- Default backups
- External backups (in the customer’s own storage bucket)
This feature isn’t currently available in PCI/ HIPAA services
- Configurable backups
Restoring from a Backup
- Default backups, in the ClickHouse Cloud bucket, can be restored to a new service in the same region.
- External backups (in customer object storage) can be restored to a new service in the same or different region.
Backup and restore duration guidance
Backup and restore durations vary significantly with data size, schema complexity, and the number of tables. The figures below are observations from internal testing and are not performance commitments. In our testing, a backup of roughly 1 TB has taken about 10 to 15 minutes, and 20 TB about an hour. Larger datasets take proportionally longer, and backups of several hundred TB or more can take many hours, although there are economies of scale that help at larger sizes. Restores are typically slower than the equivalent backup, particularly when the restore includes a long chain of incremental backups, since the full backup and all subsequent incremental backups in the chain must be applied. Restoring a very large service can take longer than a day. Because durations depend heavily on your data, schema, and backup configuration, we strongly recommend testing a restore against your own data before relying on any target recovery time.There is currently NO support for automatic failover between 2 ClickHouse Cloud instances whether in the same or different region.
There is currently NO automatic syncing of data between different ClickHouse Cloud services in the same or different regions .i.e. Active-Active replication
Recovery process
This section explains the various recovery options and the process that can be followed in each case.Primary service data corruption
In this case, the data can be restored from the backup to another service in the same region. The backup could be up to 24 hours old if using the default backup policy, or up to 6 hours old (if using configurable backups with 6 hours frequency).Restoration steps
To restore from an existing backup- Go to the “Backups” section of the ClickHouse Cloud console.
- Click on the three dots under “Actions” for the specific backup that you want to restore from.
- Give the new service a specific name and restore from this backup
Primary region downtime
You can export backups to your own cloud provider bucket. If you’re concerned about regional failures, we recommend exporting backups to a different region. Keep in mind that cross-region data transfer charges will apply. If the primary region goes down, the backup in another region can be restored to a new service in a different region. Once the backup has been restored to another service, you will need to ensure that any DNS, load balancer, or connection string configurations are updated to point to the new service. This may involve:- Updating environment variables or secrets
- Restarting application services to establish new connections
Backup / restore to an external bucket is currently not supported for services utilizing Transparent Data Encryption (TDE).
Additional options
There are some additional options to consider.- Dual-writing to separate clusters
- Utilize CSP replication