{"id":"IL-0281","org":"PostHog","date":"2026-02-19","docs":[],"title":{"en":"PostHog's Logs ClickHouse cluster silently deleted almost all its S3 data, losing US logs older than 3 days","ko":"PostHog US 리전 Logs 제품의 ClickHouse 클러스터가 S3 에 둔 로그 데이터를 거의 다 지워 3일보다 오래된 로그가 사라졌다"},"domain":["database","aws"],"impact":{"scope":"Logs product: logs collected more than 3 days before the incident were lost; all other PostHog products and data were unaffected","users":"unknown","region":"US region"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Running Logs in its own cluster kept every other product unaffected, and 3 days of Kafka retention saved the recent data. An experimental setting chosen for an early internal stage was allowed to stay in production. Monitoring covered only incoming and recent data, so petabytes were deleted over 8 hours without an alarm. Relying on database replication alone over shared storage was a single point of failure, and S3 versioning would have let the deleted files be recovered.","ko":"Logs 제품을 따로 떼어 둔 덕분에 다른 제품과 기능은 전혀 영향을 받지 않았고, Kafka 보존 기간 3일 덕분에 최근 데이터는 잃지 않았다. 반면 MVP 와 알파 단계에 쓰려던 실험 설정이 운영 환경까지 그대로 남았다. PostHog 는 들어오는 데이터와 핫 데이터의 상태만 감시해 과거 데이터가 지워지는 것을 보지 못했다. 공유 저장소를 쓰면서 데이터 내구성을 데이터베이스 복제에만 맡겨 단일 장애 지점이 생겼고, S3 Versioning 이 없어 지워진 파일을 되살릴 수 없었다."},"related":[],"sources":[{"url":"https://posthog.com/handbook/company/post-mortems/2026-02-20-posthog-us-logs-data-loss","kind":"blog","archived":"https://web.archive.org/web/20260615173914/https://posthog.com/handbook/company/post-mortems/2026-02-20-posthog-us-logs-data-loss"}],"summary":{"en":"PostHog stores Logs data in a dedicated ClickHouse cluster, separate from the main ClickHouse cluster shared by most other PostHog products. The Logs cluster uses S3 disks: data parts are uploaded to S3 automatically after 24 hours, which lets it hold very large volumes (PostHog's own systems alone produce about 500MB/s of logs, or about 1PB/month uncompressed). The database has two replicas, but zero-copy replication, an experimental ClickHouse feature that ClickHouse does not recommend for production, had been turned on very early, when Logs was an internal-only tool, and the setting was not revisited when Logs was released to external users. With zero-copy replication the replicas share the same S3 objects, so there was no redundancy between the database logic and the storage, and S3 versioning was not enabled on the bucket.\n\nAt 11:02 UTC on 19 February the finished mutation triggered a zero-copy replication bug, and one replica wrongly concluded that none of the data parts in the database were referenced any more. Until 19:40 the replicas deleted the S3 data of the whole database; a fault that should have removed one replica's data removed it everywhere. At 19:40 a node crashed and could not start, and engineers found most S3-backed data missing. At 21:45 the data was judged most likely unrecoverable and disaster recovery began. At 22:15 the team decided to move to a new table and restore data from Kafka, which kept 3 days of retention, and by 23:00 the new table, without zero-copy replication, was in use and had caught up on recent messages. The backfill from Kafka history ran on 20 February from 10:05 to 12:21 UTC. Data older than the Kafka retention could not be restored.","ko":"PostHog 는 Logs 제품의 데이터를 다른 제품들이 함께 쓰는 주 ClickHouse 클러스터와 분리된 전용 클러스터에 저장했다. 이 클러스터는 ClickHouse 의 S3 디스크를 써서 24시간이 지난 데이터 파트를 자동으로 S3 에 올렸다. 데이터베이스에는 복제본이 둘 있었지만, PostHog 는 프로젝트 초기에 Zero Copy Replication 을 켜 두었다. Zero Copy Replication 은 ClickHouse 가 운영 환경에 권하지 않는 실험 기능이고, 이 기능을 켜면 여러 복제본이 S3 라는 같은 저장소를 함께 쓴다.\n\n2026년 2월 19일 10:54 UTC 에 인덱스를 materialize 하는 mutation 을 돌렸고, 11:02 에 mutation 이 끝나면서 zero-copy replication 버그가 터졌다. 복제본 하나가 모든 데이터 파트를 더는 아무도 참조하지 않는다고 판단해 S3 객체 삭제 명령을 냈다. 복제본들이 저장소를 함께 쓰므로 파일은 클러스터 전체에서 바로 사라졌다. 19:40 까지 복제본들이 데이터베이스 전체의 S3 데이터를 지우는 동안 알람은 울리지 않았다. S3 에 둔 콜드 데이터의 무결성을 보는 모니터링이 없었고, 알림은 수집 지연, 쿼리 지연, 활성 쿼리의 오류율을 보도록 맞춰져 있었기 때문이다.\n\n19:40 에 노드 하나가 죽었고, 재시작하다 없는 데이터 때문에 뜨지 못했다. 엔지니어가 이를 살피다 S3 데이터 대부분이 사라진 것을 찾았다. 21:45 에 데이터를 되살리기 어렵다고 판단해 재해 복구 절차를 시작했고, 22:15 에 새 테이블로 넘어가 보존 기간 3일인 Kafka 에서 데이터를 복원하기로 했다. 23:00 에 zero-copy replication 을 쓰지 않는 새 테이블로 전환해 최근 메시지를 따라잡았다. 2월 20일 10:05 에 시작한 Kafka 기록 백필은 12:21 에 끝났다. 버킷에 S3 Versioning 이 꺼져 있어 지워진 파일을 되살릴 수 없었고, 3일보다 오래된 로그는 잃었다. 다른 PostHog 제품과 데이터는 영향을 받지 않았다."},"trigger":{"en":"At 10:54 UTC a routine mutation was run to materialise an index. When it finished at 11:02, it set off a bug in ClickHouse's zero-copy replication.","ko":"인덱스를 materialize 하는 일상적인 mutation 이 끝나면서 ClickHouse 의 zero-copy replication 버그가 터졌고, 복제본 하나가 데이터베이스의 모든 데이터 파트를 더는 아무도 참조하지 않는다고 잘못 판단했다."},"severity":"unknown","symptoms":["data-loss"],"timeline":{"detected_after":"8h 38m","resolved_after":"25h 19m"},"date_kind":"incident","detection":{"en":"No automated alarm fired. At 19:40 UTC a node in the cluster crashed, restarted and failed to start because of the missing data, and the engineers who investigated found that most of the S3-backed data was gone.","ko":"19:40 UTC 에 클러스터 노드 하나가 죽었고, 재시작하다 없는 데이터가 많아 뜨지 못했다. 엔지니어가 이를 조사하다 S3 에 저장된 데이터 대부분이 없는 것을 발견했다. 그 전 8시간 동안 자동 알람은 하나도 울리지 않았다."},"components":["database","database-replication","object-storage","database-backup"],"root_cause":"software-bug","remediation":[{"text":{"en":"Switched Logs to a new table without zero-copy replication and caught up on recent messages","ko":"zero-copy replication 을 쓰지 않는 새 테이블로 전환하고 최근 메시지를 따라잡았다."}},{"text":{"en":"Backfilled the Logs data from the 3 days of Kafka history","ko":"보존 기간 3일인 Kafka 기록에서 데이터를 새 테이블로 백필했다. 2월 20일 10:05 UTC 에 시작해 12:21 에 끝났다."}}],"action_items":[{"text":{"en":"Disable zero-copy replication on all clusters","ko":"모든 클러스터에서 Zero Copy Replication 을 바로 끈다."}},{"text":{"en":"Audit the whole Logs ClickHouse configuration and keep experimental features out of production","ko":"Logs ClickHouse 설정 전체를 감사하고 운영 환경에서 실험 기능을 쓰지 않게 한다."}},{"text":{"en":"Enable S3 versioning on the storage buckets so objects deleted by a database bug can be recovered","ko":"저장소 버킷에 S3 Versioning 을 켜서 데이터베이스가 버그로 파괴적인 명령을 내도 객체를 되살릴 수 있게 한다."}},{"text":{"en":"Spot-check configurations and data integrity strategies for single points of failure before a product becomes generally available","ko":"제품을 정식 출시하기 전에 설정과 데이터 무결성 전략을 표본 점검한다. 이 점검으로 단일 장애 지점을 찾아 고친다."}}],"contributing":["monitoring-blind-spot","single-point-of-failure","backup-unverified"],"recurrence_of":null,"symptoms_text":{"en":"On 19 February 2026, a node of the ClickHouse cluster behind PostHog's Logs product crashed, restarted and could not start again because it could not find a large amount of its data. Engineers then found that almost all of the Logs data stored on S3 was gone, so logs collected in the US region more than 3 days earlier were lost. Only the Logs product was affected.\n\nThe deletion had run in the background for about eight hours, from 11:02 to 19:40 UTC, without a single alarm. The Logs cluster moves data parts to S3 only after 24 hours and most queries read recent logs, so query errors stayed few. Alerts covered ingestion lag, query latency and error rates on active queries, nothing measured the integrity of the older data on S3, and the deletion raised no application-level errors, so dashboards stayed green until the node restart forced a consistency check.","ko":"Logs 클러스터의 노드 하나가 죽었고, 다시 시작하는 중에 찾을 수 없는 데이터가 너무 많아 뜨지 못했다. 엔지니어가 확인해 보니 S3 에 저장된 데이터 대부분이 없었다.\n\n삭제는 노드가 죽기 전 약 8시간 동안 조용히 진행됐다. 데이터는 24시간이 지나야 S3 로 옮겨지고 쿼리 대부분은 최근 데이터를 찾으므로 쿼리 오류가 적었다. 자동 알람은 하나도 울리지 않았다. 애플리케이션 수준의 오류도 나지 않아, 노드 재시작으로 일관성 검사가 돌기 전까지 대시보드는 초록색이었다."},"updated_at":"2026-11-14T12:33:53.563120Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0281","org_slug":"posthog"}