분류: 홈서버·셀프호스팅

Docker 볼륨과 바인드 마운트의 차이

예제마다 volumes: 표기가 다른 이유가 있습니다. 데이터의 주인이 누구인지로 두 방식을 가르고, 백업 방법과 이사 난이도 관점에서 어느 쪽을 쓸지 기준을 제시합니다.

마지막 확인

이런 상황일 때

설치 예제마다 volumes: 아래 표기가 다릅니다. 어떤 글은 ./data:/var/lib/mysql 처럼 경로로 쓰고, 어떤 글은 이름 하나만 씁니다. 아무거나 따라 했는데, 백업을 하려고 보니 데이터가 어디 있는지부터 모르겠습니다.

한 줄 결론

데이터의 주인이 누구인가로 갈립니다. 경로로 쓰면(바인드 마운트) 내 폴더가 진실이고 백업은 폴더 복사입니다. 이름으로 쓰면(볼륨) Docker 가 관리하는 저장소가 진실이고 백업은 컨테이너를 한 번 거칩니다. 지금 무엇을 쓰고 있는지 확인하는 명령부터 아래에 있습니다.

핵심 개념

바인드 마운트 — 내 폴더를 그대로 꽂는다

컴퓨터의 실제 경로를 컨테이너 안 경로에 연결합니다. 파일은 그냥 그 폴더에 있으므로 백업·이동·확인이 평범한 파일 작업입니다. 대신 경로·권한 관리가 전부 내 몫입니다.

볼륨 — Docker 가 관리하는 저장소

이름만 정하면 Docker 가 자기 영역에 폴더를 만들어 관리합니다. 시험 환경에서 실제 위치는 /var/lib/docker/volumes/볼륨이름/_data 였습니다. 그 경로를 직접 만지는 것은 권장되지 않고, 백업도 컨테이너를 거치는 것이 공식 방법입니다.

compose 표기는 한 글자 차이다

./ 나 / 로 시작하면 바인드 마운트, 이름이면 볼륨입니다. 볼륨은 파일 맨 아래 최상위 volumes: 에도 이름을 선언해야 합니다. 이 한 줄 차이가 백업 방식을 결정합니다.

어느 쪽도 백업이 아니다

볼륨도 바인드도 저장 위치일 뿐, 자동으로 복사본을 만들지 않습니다. 백업은 어느 쪽이든 따로 해야 하고, 방식만 다릅니다 — 바인드는 폴더 복사, 볼륨은 아래의 tar 명령입니다.

지금 추적 중인 버전

제품 현재 버전 공개일
Docker Compose다중 컨테이너 정의 5.4.0 2026-08-03

이 표의 값은 공식 릴리스에서 가져온 것이며, 아래 마지막 검토일 기준입니다.

이런 분에게 해당됩니다

  • compose 파일을 처음 만지는 홈서버 사용자
  • 백업을 하려는데 데이터 위치부터 막힌 분
  • 예제마다 다른 표기 때문에 헷갈리는 분

확인해야 할 항목

  • 지금 컨테이너가 볼륨과 바인드 중 무엇을 쓰는가
  • compose 파일의 volumes: 가 경로인가 이름인가
  • 데이터베이스처럼 잠그고 백업해야 하는 데이터인가
  • 다른 서버로 옮길 계획이 있는가
  • 백업을 마지막으로 언제 했고, 되살려 본 적이 있는가

잘못 이해하기 쉬운 부분

오해 볼륨이 더 안전한 방식이다.

사실 안전은 백업에서 옵니다. 볼륨은 관리를 Docker 에 맡기는 방식일 뿐, 복사본을 만들어 주지 않습니다. 백업 없는 볼륨은 백업 없는 폴더와 똑같이 위험합니다.

오해 컨테이너를 지우면 데이터도 같이 지워진다.

사실 마운트한 데이터는 남습니다. 사라지는 것은 마운트하지 않은 경로에 쓴 것들입니다. 반대로 말하면, 중요한 데이터인데 마운트 목록에 없다면 그게 바로 고쳐야 할 설정입니다.

오해 compose 의 경로를 바꾸면 데이터가 따라온다.

사실 새 경로의 빈 폴더를 보게 됩니다. 데이터가 사라진 것처럼 보이는 흔한 사고입니다 — 실제로는 옛 경로에 그대로 있으니, 경로를 되돌리고 옮기는 작업을 따로 하면 됩니다.

안전한 행동 순서

  1. 먼저 지금 무엇을 쓰는지 확인합니다. 아래 ① 명령이 마운트 종류와 실제 위치를 보여 줍니다.
  2. compose 파일의 volumes: 표기를 확인합니다 — 경로면 바인드, 이름이면 볼륨입니다.
  3. 새로 정하는 경우: 설정 파일처럼 내가 자주 만질 것은 바인드, 데이터베이스처럼 프로그램만 만질 것은 볼륨이 무난합니다.
  4. 바인드 마운트의 백업은 프로그램을 멈춘 뒤 그 폴더를 복사하면 됩니다.
  5. 볼륨의 백업은 아래 ③ 명령처럼 컨테이너를 한 번 거칩니다. 멈춘 뒤에 하는 것은 같습니다.
  6. 백업 파일이 실제로 풀리는지 한 번 확인합니다 — 되살려 본 적 없는 백업은 백업이 아닙니다.

① 지금 무엇을 쓰는지 확인

docker inspect <컨테이너이름> --format '{{range .Mounts}}{{.Type}} {{.Source}} -> {{.Destination}}{{println}}{{end}}'

서버 셸에서 실행합니다(읽기만 합니다). 시험 환경 출력: volume /var/lib/docker/volumes/…/_data -> /data · 확인: 2026-08-07 · wp3 VM (Debian, Docker Engine 29.7.1)

② 볼륨 이름과 실제 위치

docker volume ls
docker volume inspect <볼륨이름> --format '{{.Mountpoint}}'

읽기만 하는 명령입니다. 위치를 아는 것과 그 경로를 직접 고치는 것은 다릅니다 — 고치는 쪽은 권장되지 않습니다 · 확인: 2026-08-07 · wp3 VM (Debian, Docker Engine 29.7.1)

③ 볼륨을 tar 로 백업

docker run --rm -v <볼륨이름>:/from:ro -v "$PWD":/to alpine tar czf /to/backup.tgz -C /from .
tar tzf backup.tgz

볼륨을 읽기 전용(:ro)으로 물려 백업만 만듭니다. 두 번째 줄로 내용물이 실제로 들어갔는지 확인합니다. 데이터베이스는 먼저 멈추거나 그 DB 의 덤프 도구를 쓰세요 · 확인: 2026-08-07 · wp3 VM (Debian, Docker Engine 29.7.1)

확인 체크리스트

  • 마운트 종류(볼륨/바인드)를 확인했다
  • 데이터의 실제 위치를 안다
  • 백업 방법을 방식에 맞게 정했다
  • 백업 파일이 풀리는지 확인했다
  • 중요한 데이터가 마운트 목록에 빠져 있지 않은지 봤다

관련 도구와 버전 페이지

  • 알려진 문제 추적아직 제공하지 않습니다
    어떤 판에 어떤 문제가 보고됐는지 이 사이트는 아직 모으지 않습니다. 각 제품의 이슈 목록을 직접 보셔야 합니다.

자주 묻는 것

이미 바인드로 쓰고 있는데 볼륨으로 바꿔야 하나요?

문제없이 돌고 백업도 하고 있다면 바꿀 이유가 없습니다. 방식 전환은 데이터 이동 작업이라 그 자체가 위험을 만듭니다. 바꿀 때는 복사 → 확인 → 전환 순서로, 원본을 지우지 않은 채 진행하세요.

named volume 인데 파일 탐색기로 직접 열어 보고 싶습니다.

위치는 ② 명령으로 알 수 있지만, 그 경로에서 직접 고치는 것은 권장되지 않습니다. 내용 확인이 목적이면 컨테이너를 하나 띄워 읽기 전용으로 물려 보는 쪽이 안전합니다 — ③ 명령의 tar tzf 로도 목록은 봅니다.

volumes: 에 이름을 썼는데 처음 띄우니 비어 있습니다.

정상입니다. 볼륨은 처음 만들 때 비어 있고, 이미지에 내용이 있는 경로에 물리면 첫 1회만 그 내용이 복사되는 예외가 있습니다. 있던 데이터가 안 보이는 경우라면 볼륨 이름이 예전과 다른지부터 확인하세요.

공식 출처

마지막 검토일: 2026-08-07

공식 출처

내용이 잘못되었나요? 수정 요청