서버가 'No space left' 오류를 뱉던 새벽 — df·du로 범인 폴더 찾기

서비스가 갑자기 멈췄습니다. 로그를 열어보니 No space left on device. 디스크가 꽉 찼다는 뜻이죠. 그런데 막상 뭘 지워야 할지 모르면, 이 짧은 한 줄이 사람을 한 시간씩 붙잡아 둡니다. 저도 처음엔 무작정 로그 폴더만 뒤졌다가 엉뚱한 곳에서 헤맸습니다. 오늘은 디스크가 찰 때 범인 폴더를 빠르게 찾아내는 순서를 차근차근 정리하겠습니다.

디스크 문제는 '지우기'가 아니라 '찾기'가 8할입니다.

먼저 어디가 찼는지부터 본다

급하다고 바로 파일을 지우기 시작하면 안 됩니다. 디스크는 보통 여러 파티션으로 나뉘어 있어서, 정작 꽉 찬 곳이 어디인지부터 확인해야 합니다. 이때 쓰는 명령이 df입니다.

df -h

-h는 사람이 읽기 좋은 단위(G, M)로 보여달라는 뜻입니다. 출력에서 Use%가 100%에 가까운 줄을 찾으세요. 보통 루트(/)나 로그가 쌓이는 /var가 범인입니다. 여기서 어떤 파티션이 문제인지 모른 채 파일부터 지우면, 정작 꽉 찬 파티션은 그대로인 황당한 상황이 벌어집니다.

큰 폴더를 위에서부터 추적한다

꽉 찬 파티션을 알아냈다면, 이제 그 안에서 용량을 많이 잡아먹는 폴더를 따라 내려갑니다. 이때는 du를 씁니다.

du -h --max-depth=1 /var | sort -hr | head

이 명령은 /var 바로 아래 폴더들의 크기를 큰 순서대로 보여줍니다. 가장 큰 폴더로 들어가 같은 명령을 반복하면, 마치 점점 좁혀 들어가듯 진짜 범인 폴더에 도착합니다. 무작정 전체를 뒤지는 것보다 훨씬 빠릅니다.

흔한 범인은 정해져 있다

경험상 디스크를 꽉 채우는 폴더는 거의 비슷합니다.

특히 로그는 조용히 쌓이다가 어느 날 갑자기 터집니다. 한 번 비웠다고 끝이 아니라, 로그 로테이션(자동 정리) 설정을 해두지 않으면 며칠 뒤 똑같은 일이 반복됩니다.

지우기 전, 한 번만 더 확인

용량을 차지하는 파일을 찾았다고 바로 rm 하면 위험합니다. 그게 지금 돌아가는 서비스의 로그이거나, 누군가 보고 있는 파일일 수 있으니까요. 무엇인지 모르는 파일은 먼저 열어 확인하고, 정 급하면 지우는 대신 다른 디스크로 옮기는 것도 방법입니다.

정리하며

새벽에 서버가 멈추면 누구나 당황합니다. 하지만 순서만 기억하면 의외로 금방 끝납니다. 첫째, df -h로 꽉 찬 파티션을 찾고. 둘째, du로 큰 폴더를 위에서부터 좁혀 들어가고. 셋째, 지우기 전 무엇인지 확인하고 로그는 로테이션으로 재발을 막는 것.

혹시 지금 운영 중인 서버가 있다면, 문제가 터지기 전에 오늘 df -h 한 번 찍어보세요. 80%를 넘겼다면 미리 손쓸 시간이 있다는 신호입니다. 작은 점검 하나가 새벽의 장애 알림을 막아줍니다.