Claude에게 경의를 표하며
Hats off to claude
핵심 요약
Claude의 도움으로 8TB 규모의 손상된 BTRFS 데이터를 99.94% 복구한 엔지니어의 놀라운 사례.
- 데이터 복구 성공 — Claude와 함께 8TB 규모의 손상된 BTRFS 파일 시스템을 99.94% 복구함
- 기술적 난제 해결 — 일반적인 복구 도구로 불가능했던 바이너리 트리 노드 재구성을 성공적으로 수행함
- 엔지니어링 역량 — 20년 경력의 엔지니어도 포기할 뻔한 상황을 AI와의 협업으로 극복함
- 사례 공유 — 복구 과정을 담은 사례 연구를 BTRFS 깃허브에 공개하여 기술적 기여를 함
데이터 서버에서 커널을 교체하고 튜닝하던 중, 강제 재부팅으로 12TB BTRFS 어레이가 완전히 손상되고 파괴되었습니다..
BTRFS 기본 도구로 모든 방법을 시도해 봤지만 아무것도 통하지 않았습니다..
Claude와 몇 시간 동안 분석한 끝에, 그는 제게 단호하게 말했습니다...
"마이크, 인덱스 테이블이 약 80% 지점에서 파괴되었습니다. 그 지점의 모든 노드가 손실되고 손상되어 8TB 이상의 데이터 중 80% 이상이 유실된 상태입니다."
기본 복구 도구를 실행할 때마다 상황은 더 악화되었습니다. 이런 종류의 치명적인 오류는 기존 도구들로는 해결할 수 없는 문제들이 많습니다..
안타깝게도 fs_tree에 대한 백업이 없었기 때문에, 제가 직접 뛰어들어 메모리 상에서 전체 바이너리 트리를 매핑하고, 예측을 수행하며 노드별로 수동으로 재구축해야 했습니다. C 언어로 전체를 패치할 수 있는 도구를 만들기 위해서 말이죠..
저는 그에게 "좋아, 진행해"라고 했습니다.. 저에게 남은 대안은 8TB의 데이터 손실을 받아들이는 것뿐이었으니까요.
금요일부터 가끔 그의 활동을 모니터링했습니다.. 그는 제가 20년 경력의 소프트웨어 엔지니어임에도 거의 알지 못하는 바이너리 배열과 하드 디스크 용어들에 대해 이야기하고 있었습니다..
오늘 아침, 저는 그가 발견한 내용과 해결책을 설명하는 에세이 보고서를 보고 잠에서 깼습니다..
결과적으로 8.4TB의 데이터 중 7MB의 쓰레기 파일만 제외하고, 전체 트리를 처음부터 다시 구축하여 99.94%의 데이터를 복구했습니다. 오류 없이 100% 정상 작동합니다..
심지어 BTRFS 깃허브에 사례 연구를 게시하기도 했습니다...
저와 같은 절망적인 상황에 처한 누군가에게 도움이 되길 바랍니다...
https://github.com/kdave/btrfs-progs/issues/1107
TLDR: Claude는 시행착오를 거쳐 12TB(4TB 디스크 3개) BTRFS 어레이의 완전히 파괴된 fs_tree를 복구하는 방법을 학습했고, 99.94%의 데이터를 완벽하게 복구하여 모든 것을 100% 정상 상태로 되돌렸습니다.

