이런 상황일 때
설치 예제마다 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 의 경로를 바꾸면 데이터가 따라온다.
사실 새 경로의 빈 폴더를 보게 됩니다. 데이터가 사라진 것처럼 보이는 흔한 사고입니다 — 실제로는 옛 경로에 그대로 있으니, 경로를 되돌리고 옮기는 작업을 따로 하면 됩니다.
안전한 행동 순서
- 먼저 지금 무엇을 쓰는지 확인합니다. 아래 ① 명령이 마운트 종류와 실제 위치를 보여 줍니다.
- compose 파일의 volumes: 표기를 확인합니다 — 경로면 바인드, 이름이면 볼륨입니다.
- 새로 정하는 경우: 설정 파일처럼 내가 자주 만질 것은 바인드, 데이터베이스처럼 프로그램만 만질 것은 볼륨이 무난합니다.
- 바인드 마운트의 백업은 프로그램을 멈춘 뒤 그 폴더를 복사하면 됩니다.
- 볼륨의 백업은 아래 ③ 명령처럼 컨테이너를 한 번 거칩니다. 멈춘 뒤에 하는 것은 같습니다.
- 백업 파일이 실제로 풀리는지 한 번 확인합니다 — 되살려 본 적 없는 백업은 백업이 아닙니다.
① 지금 무엇을 쓰는지 확인
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회만 그 내용이 복사되는 예외가 있습니다. 있던 데이터가 안 보이는 경우라면 볼륨 이름이 예전과 다른지부터 확인하세요.
- 볼륨 — Docker
- 바인드 마운트 — Docker
- Compose 파일 volumes 항목 — Docker
마지막 검토일: 2026-08-07