Als ich eine self-hosted Analytics-Plattform baute, war die Query-Engine ClickHouse — und die erste echte Entscheidung war nicht welche Engine, sondern wo sie läuft. Die naheliegende Antwort, weil ich ohnehin einen Kubernetes-Cluster hatte, wäre gewesen: dort, auf netz-angebundenem Storage. Habe ich nicht. Sie sitzt auf einer dedizierten Bare-Metal-Maschine, und genau diese eine Wahl ist der Unterschied zwischen einem Warehouse, das sich sofort anfühlt, und einem, das sich wie eine Cloud-Rechnung anfühlt. Hier die Begründung, was man aufgibt, und der Teil, den die meisten überspringen, bis es weh tut: das Sichern, ohne die Daten zu zerstören.
Warum nicht einfach in Kubernetes?
ClickHouse ist ein Column-Store zum Scannen riesiger Tabellen, was ihn bei den entscheidenden Queries stark IO-bound macht. Genau da schlägt die Deployment-Wahl zu. Lokales NVMe auf einer dedizierten Maschine liefert grob 5 GB/s sequenziellen Lesedurchsatz. Netz-angebundener Cluster-Storage — wie ihn ein typisches Kubernetes-CSI-Volume gibt — liegt eher bei 200–400 MB/s. Bei einem Analytics-Scan ist das kein Rundungsfehler, sondern ein Faktor 10 in der Latenz, genau auf der Last, die du wirklich fährst.
Der Rest verstärkt es. Merges und In-Memory-Parts lieben RAM, also verhält sich eine Maschine mit 128 GB völlig anders als ein speicherbegrenzter Pod. Eine CPU mit großem Cache (in meinem Fall ein AMD-X3D-Teil) passt zu den großen Working Sets, die Analytics-Queries durchkauen. Und das Geld läuft anders herum als in der üblichen Cloud-Geschichte: eine dedizierte Hetzner-Maschine um die 120 €/Monat schlägt einen vergleichbaren managed Cluster, der 400 €+/Monat verlangt. Für einen IO-bound Column-Store ist dedizierte Hardware schneller und günstiger — selten genug, um es zu erwähnen.
Was man aufgibt
Das ist nicht gratis, und so zu tun ist der Weg, auf dem sich Leute die Finger verbrennen. Eine dedizierte Maschine ist eine zweite Wartungs-Domäne außerhalb von Kubernetes — eigenes OS zum Patchen, eigenes Netzwerk, das zurück in den Cluster verdrahtet werden muss. Ein einzelner Knoten ist ein Single Point of Failure: Bis du eine Replik hinzufügst, bedeutet ein toter Host Downtime, kein automatisches Failover. Und Backups schenkt dir niemand — die verantwortest du komplett selbst.
Keiner dieser Punkte ist ein Ausschlusskriterium, wenn man mit offenen Augen hineingeht. Der SPOF ist real, aber begrenzt, weil die Rohdaten im Lake liegen (siehe die Beschreibung des Gesamt-Stacks) — ein Totalverlust der Maschine kostet dich den transformierten Zustand und die ClickHouse-Internals, nicht die Quelldaten. Aber jede Transformation von Grund auf neu zu bauen sind trotzdem Stunden ungeplanter Arbeit, und genau deshalb ist die Backup-Geschichte unten nicht optional.
Sichern — der Teil, den man leicht falsch macht
Das mit Abstand Wichtigste: kopiere nicht das Datenverzeichnis per File-Copy. ClickHouse merged MergeTree-Parts ständig im Hintergrund. Kopierst du die Dateien mitten im Merge, bekommst du einen inkonsistenten, teils korrupten Snapshot, der gut aussieht — bis du ihn zurückspielen willst. Ein simpler Cron mit cp oder rsync über das laufende Datenverzeichnis ist ein Backup, das dich anlügt.
Das richtige Werkzeug ist clickhouse-backup (die gepflegte CLI von Altinity). Sie setzt ein FREEZE auf die MergeTree-Parts, das einen konsistenten Point-in-time-Snapshot per Hardlink in einen Shadow-Pfad legt, tarrt das und lädt es hoch. Konsistent per Konstruktion, keine Korruption, und sie versteht das On-Disk-Layout von ClickHouse, statt dagegen zu arbeiten.
Drei Regeln drumherum, die so wichtig sind wie das Tool selbst:
Leg das Ziel weg von der Maschine. Wenn der Host stirbt, muss das Backup woanders liegen, um etwas wert zu sein. S3-kompatibler Object Storage ist das naheliegende Primärziel. Ein günstiges Sekundärziel — ein wöchentliches rsync auf eine Storage Box — deckt den Fall ab, dass der Object Store selbst einen schlechten Tag hat.
Automatisiere es, verlass dich nicht aufs Erinnern. Ein systemd-Timer, der nächtlich läuft, mit echter Retention (ich halte 14 tägliche Full-Backups). Ein Backup, an das du denken musst, ist ein Backup, das du nicht hast.
Setz ein RTO und RPO, das du ernst meinst. Meine sind 4–8 Stunden Recovery-Zeit und 24 Stunden tolerierbarer Datenverlust — womit ein tägliches Backup wirklich ausreicht, ohne inkrementelles Streaming für eine Last zu überbauen, die einen Tag verträgt.
Die Zugangsdaten des Backup-Jobs liegen in einer 0600-Config-Datei auf der Maschine, getrennt von dem Profil, das du vom Laptop nutzt, und niemals im Git. Das ist der langweilige Teil, der auch der Teil ist, der leakt, wenn man schlampt.
Würde ich es wieder so machen?
Für eine IO-bound Analytics-Engine ohne Zögern. Dedizierte Hardware ist die seltene Wahl, die zugleich schneller und günstiger ist, und die Trade-offs — ein zweites Ding zum Patchen, ein einzelner Knoten, eigene Backups — sind alle mit ein paar Stunden Setup und einem nächtlichen Timer beherrschbar. Managed ClickHouse Cloud ist die richtige Antwort, wenn dir Betriebs-Kapazität fehlt; wenn nicht, bringt dich eine dedizierte Maschine plus ein korrekter Backup-Job für einen Bruchteil des Preises fast bis zum vollen Warehouse.
Häufige Fragen
Ist ein einzelner ClickHouse-Knoten nicht zu riskant für Produktion?
Es ist ein echter Single Point of Failure, ja. Die Absicherung ist zweischichtig: korrekte, getestete Backups, damit ein Host-Verlust innerhalb deines RTO wiederherstellbar ist, und — wenn die Verfügbarkeit es verlangt — eine zweite Replik fürs automatische Failover. Für viel interne Analytics, wo ein paar Stunden Downtime verkraftbar sind, ist ein gut gesicherter Einzelknoten eine vernünftige Phase 1.
Kann ich nicht einfach die ganze Maschine snapshotten?
Eine dedizierte Bare-Metal-Maschine hat meist keinen Hypervisor zum Snapshotten, und selbst wo ein VM-Snapshot existiert, ist er für Parts mitten im Merge nicht ClickHouse-konsistent — dasselbe Korruptionsrisiko wie ein File-Copy. Nimm ein Werkzeug, das MergeTree spricht; ein Snapshot auf Maschinenebene ist eine trügerische Sicherheit.
Warum nicht managed ClickHouse Cloud und sich das alles sparen?
Kosten und Kontrolle. Managed nimmt dir die Betriebslast ab, was echtes Geld wert ist, wenn dir die Kapazität fehlt — aber du zahlst ein Vielfaches, und deine Daten liegen auf fremder Infrastruktur. Wer eine Linux-Maschine und eine Datenbank betreiben kann, für den ist Self-Hosting drastisch günstiger und hält die Daten bei sich.
Wie lange dauert ein Restore wirklich?
Das hängt vom Datenvolumen ab und davon, wie schnell du vom Backup-Ziel ziehen kannst — genau deshalb solltest du einen echten Restore timen, bevor du ihn brauchst. Ein ungetestetes Backup ist eine Hypothese, kein Wiederherstellungsplan.