Hi, I ran a Clickhouse server in production at non-trivial scale for storage and query of application logs (semi-structured JSON documents).
In our case we were consuming from a kafka topic which was the source of truth, so we opted not to use Clickhouse's built-in write replication and instead manually sharded and wrote to each replica independently (this meant replicas weren't always in perfect sync for brand-new data, but in practice this was acceptable).
The distributed query side still worked perfectly despite this weird setup, even when we were doing weird things like re-sharding or taking some replicas down for one reason or another.
I can't speak to backups as, once again, we were considering the kafka stream the source of truth and not the clickhouse datastore. We archived the data directly out of kafka, in a format more suitable to long term archival instead of live query.
My experience with Clickhouse was that the core primitives were rock solid, but you were often on shaky ground when using more niche features - we encountered crashes when trying to use bloom filters for text search, for example.
The performance of Clickhouse absolutely blew me away. It could read, filter and aggregate results as fast as the underlying disks could serve it data. I'll point out though that while Clickhouse is very good at what it does, it puts a lot of onus on the person designing the schema and writing the query to make sure it does it in the right way. In our case this worked well because we only had a small number of "shapes" of query we needed to serve, and we had a CLI tool that translated the user's query written in a simple DSL (really just a key-matches-value filter expression) into the SQL that would result in an efficient query on clickhouse's end. But for more flexibility-demanding workloads this could be a major issue as you need to know the system pretty well to write good queries.