SQLite 공식 문서가 직접 정리한 'DB 파일 손상 시나리오'다. 핵심은 손상 대부분이 SQLite 버그가 아니라 운영 환경 탓이라는 점. 첫째, 파일 락 오작동이 가장 흔하다. 특히 NFS 같은 네트워크 파일시스템은 POSIX 락 구현이 부실해 여러 프로세스가 같은 DB를 건드리면 깨진다. 둘째, 핫 저널(rollback journal)이나 WAL 파일을 임의로 삭제·이동하면 복구 로직이 망가진다. 셋째, fsync를 무시하거나 거짓 보고하는 스토리지·드라이버에서 전원이 끊기면 쓰기 순서가 보장되지 않아 손상된다. 넷째, DB가 쓰이는 도중 단순 파일 복사로 백업하면 일관성이 깨진다. 그밖에 같은 파일을 두 연결이 서로 다른 경로명으로 열거나, 메모리 매핑 중 파일 크기를 바꾸는 경우, 디스크 불량 섹터도 원인이다. 교훈: 락·fsync·백업은 신뢰하지 말고 검증하라. WAL 모드와 PRAGMA integrity_check를 적극 활용하고, 운영 중 백업은 반드시 SQLite의 백업 API나 .backup 명령을 써야 한다.