게임 서버 디스크가 꽉 찼을 때: 월드를 지우기 전에 확인할 것
작성·공식 문서 확인일 2026-09-07 · SameOS operator
접속은 되는데 저장이 실패하거나 재시작 뒤 진행 상황이 돌아갔다면 저장장치부터 확인할 필요가 있습니다. 디스크 100%에서 급하게 큰 폴더를 지우면 오래된 백업과 현재 월드를 혼동하기 쉽습니다. 먼저 어느 파일시스템이 부족한지 확인하고, 새 쓰기를 줄인 뒤 보존할 데이터와 정리할 데이터를 구분합니다.
1. 저장 오류가 보이면 재시작 반복부터 멈추기
No space left on device, Disk quota exceeded, Read-only file system, Permission denied는 서로 다른 원인입니다. 정확한 오류와 발생 경로를 남겨야 용량 부족을 권한 문제로 오해하지 않습니다. 게임이 켜져 있다는 이유로 저장까지 정상이라고 볼 수는 없습니다.
플레이어에게 점검을 알리고 새 접속·백업·업데이트 작업을 줄입니다. 게임이 제공하는 저장과 정상 종료를 시도하되 성공 메시지를 확인하세요. 이미 저장할 공간이 없으면 저장 성공을 보장할 수 없습니다. 강제 종료와 재실행을 반복하면 마지막 정상 상태를 찾기 더 어려워집니다.
2. 게임 데이터가 실제로 있는 파일시스템 확인
아래 /srv/minecraft/data는 예시입니다. 실제 월드 경로와 백업 경로를 각각 df에 넣습니다. 루트 디스크에 공간이 있어도 월드가 있는 별도 디스크가 가득 찼을 수 있습니다. df -i는 파일 데이터 용량과 별개인 inode 사용량을 확인합니다.
작은 파일이 매우 많으면 바이트는 남아도 inode가 부족할 수 있습니다. 반대로 바이트가 꽉 차고 inode는 남아 있다면 큰 아카이브나 로그가 후보입니다. 쿼터와 읽기 전용 전환 오류는 사용률만으로 설명되지 않으므로 별도 확인이 필요합니다.
df -hT /srv/minecraft/data
df -i /srv/minecraft/data
df -hT /srv/game-backups3. Docker 볼륨과 마운트 누락도 확인
Docker는 컨테이너 안 경로와 호스트 저장 위치가 다를 수 있습니다. Mounts에서 실제 데이터가 bind mount인지 named volume인지 먼저 확인합니다. 볼륨 이름만 보고 임시 데이터라고 판단하면 안 됩니다. 컨테이너를 다시 만들어도 남겨야 할 월드가 그 안에 있을 수 있습니다.
재부팅 뒤 외장 디스크가 마운트되지 않았는데 같은 경로에 게임이 새 월드를 만들면 루트 디스크가 예상 밖으로 차기도 합니다. findmnt 결과가 기대한 장치를 가리키는지 확인하세요. 빈 폴더가 보인다고 원본 월드가 삭제됐다고 단정하기 전에 마운트부터 봅니다.
docker inspect --format '{{json .Mounts}}' mc-server
findmnt -T /srv/minecraft/data
docker system df4. 큰 항목은 목록으로 찾고 용도를 확인
du는 디렉터리별 사용량을 좁히는 데 씁니다. -x는 다른 파일시스템으로 넘어가지 않게 하고 -d 1은 첫 단계만 요약합니다. 게임 데이터 전체를 무작정 탐색하면 디스크 I/O가 늘 수 있으므로 확인할 경로를 제한합니다.
우선 오래된 배포 압축 파일, 실패한 다운로드, 중복 백업, 필요 이상으로 쌓인 로그를 확인합니다. 현재 세이브, 모드 데이터베이스, 플레이어 파일, 복구 가능한 마지막 백업은 정리 대상으로 자동 분류하지 않습니다.
df와 du가 크게 다르면 삭제됐지만 프로세스가 계속 열고 있는 파일, 파일시스템 스냅샷, 접근하지 못한 디렉터리 등이 원인일 수 있습니다. lsof가 설치돼 있다면 삭제된 열린 파일을 확인할 수 있습니다. 소유 프로세스를 확인하고 정상 재시작을 검토하며, 파일 이름만 보고 게임 프로세스를 죽이지 않습니다.
sudo du -xhd 1 /srv
sudo du -xhd 1 /var/log
sudo lsof +L15. 로그 제한은 다음 장애를 막는 설정
Docker json-file 로그는 회전 설정을 두지 않으면 계속 커질 수 있습니다. 아래는 기존 Compose 서비스에 병합할 logging 부분이며 전체 게임 서버 구성은 아닙니다. 10m·3은 예시 보관량이므로 장애 분석에 필요한 기간과 실제 발생량을 보고 정합니다.
새 로깅 설정은 기존 컨테이너에 자동 적용되지 않습니다. 데이터 마운트와 백업을 확인하고 정상 종료한 뒤 재생성하는 점검 시간을 잡습니다. Docker가 관리하는 로그 파일을 직접 잘라 내는 방식은 피하세요. 이 설정만 추가해도 현재 가득 찬 디스크가 즉시 비워지는 것은 아닙니다.
services:
minecraft:
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"6. 공간 확보 뒤 저장과 재로딩까지 확인
다른 디스크로 파일을 옮길 때는 목적지가 실제로 다른 파일시스템인지, 복사본이 읽히는지 확인한 뒤 원본 정리를 판단합니다. 같은 디스크 안에서 폴더 이름만 바꾸면 여유 공간은 늘지 않습니다. 실패한 백업을 마지막 정상 백업과 혼동하지 않게 날짜뿐 아니라 무결성도 확인합니다.
공간이 생기면 권한·마운트·읽기 전용 상태를 다시 확인하고 게임을 시작합니다. 예상한 월드와 플레이어가 맞는지 확인하고 작은 변경을 저장한 다음 정상 종료·재접속해서 남아 있는지 봅니다. 최근 저장이 손상됐다면 운영 경로 위에 계속 덮지 말고 복구본을 별도 위치에서 검증합니다.
이후 경고 기준은 사용률뿐 아니라 남은 바이트·inode와 증가 속도를 함께 봅니다. 업데이트 다운로드, 압축 전 임시 백업, 월드 저장이 동시에 필요한 여유를 확보하세요. 보관 세대와 로그 회전 한도를 정해 두면 같은 사고를 줄일 수 있습니다.
검증 범위와 공식 참고자료
공식 문서와 명령 옵션을 확인해 작성한 Linux 운영 가이드입니다. 이 글의 경로·서비스명·주소와 진단 상황은 설명용이며 실제 SameOS 게임 서버 장애 기록이나 성능 측정값이 아닙니다. 운영 서버에서 장애를 유발하거나 저장 데이터를 변경하는 실험은 하지 않았습니다. 게임 빌드와 설치 방식에 따라 설정·저장 위치가 다르므로 실제 환경을 확인한 뒤 적용하세요.