s3fs를 폴더 위에 마운트하면 데이터가 '사라진다'

어느 날 /training-clips 아래의 영상이 통째로 사라졌습니다. 분명 어제까지 있던 수십 개의 클립이 0개. 데이터 유실은 인프라에서 가장 가슴 철렁한 순간입니다. 그런데 — 파일은 그대로 있었습니다.

삭제가 아니라 가려짐(shadowing)

진실은 단순한 Unix 마운트 의미론이었습니다. 비어있지 않은 디렉터리 위에 다른 파일시스템을 마운트하면, 원래 내용은 가려져 안 보입니다 — 삭제된 게 아니라요.

도식 렌더링 중…

s3fs(오브젝트 스토리지를 파일처럼 마운트)를 기존 폴더 위에 걸자, 그 아래 원본은 마운트가 걸려 있는 동안 안 보일 뿐이었습니다. 마운트를 풀면 다시 나타납니다.

💡 "사라졌다"의 첫 대응 — 데이터가 사라진 것처럼 보이면, 지우기 전에 마운트 상태부터 확인하세요. mount 출력에 그 경로가 있으면, 십중팔구 삭제가 아니라 shadowing입니다. unmount 한 번이 패닉을 끝냅니다.

복구 — 백업에서 마운트로 write-through

다행히 마운트 전에 만들어 둔 로컬 백업이 있었습니다. 복구는 백업에서 s3fs 마운트 경로로 그대로 복사하는 것 — 이러면 write-through로 버킷에 다시 올라가 모든 노드가 같은 걸 보게 됩니다. 수십 개 클립이 되살아났습니다.

영구 마운트의 진짜 함정 — 한 줄의 설정

이 사건엔 후속편이 있었습니다. 리부팅하면 마운트가 또 풀렸습니다. systemd 서비스로 영구화하려는데 계속 실패 — 원인은 엉뚱한 곳에 있었습니다.

⚠️ allow_other는 /etc/fuse.conf의 user_allow_other가 있어야 한다 — 여러 사용자가 마운트를 읽게 하는 allow_other 옵션은, 시스템 설정 파일에 user_allow_other 한 줄이 없으면 그냥 실패합니다. 마운트가 부팅 때 조용히 안 붙던 근본 원인이 이 한 줄이었습니다. "왜 리부팅하면 마운트가 없지"의 답이 옵션이 아니라 전역 설정에 있었던 것입니다.

교훈

1. 데이터가 "사라지면" 지우지 말고 마운트부터 확인 — shadowing은 삭제가 아니다.
2. 마운트 전 백업 — 이 사건을 살린 건 마운트 전에 떠둔 로컬 백업이었다.
3. "alive ≠ working" — 마운트 프로세스가 떠 있어도 실제로 안 붙어 있을 수 있다. 끝단(파일이 보이는지)을 확인하라.

한 줄 정리

📌 데이터가 통째로 "사라졌다"면, s3fs를 기존 폴더 위에 마운트해 원본이 가려진(shadowing) 경우가 많다 — 삭제가 아니다. unmount하면 다시 보이고, 복구는 백업→마운트 경로 write-through. 영구 마운트가 안 붙으면 /etc/fuse.conf의 user_allow_other를 의심하라.