Windows 재부팅 후 WSL/Docker GitLab 컨테이너가 사라졌을 때 복구하는 방법

GitLab Docker 프로젝트가 날아간 것처럼 보일 때 원인 확인과 복구하기

Windows PC를 껐다 켠 뒤 WSL에서 사용하던 GitLab CE Docker 컨테이너가 사라진 것처럼 보이는 경우가 있습니다.

docker ps를 실행했는데 GitLab 컨테이너가 보이지 않거나, Docker Compose 프로젝트 목록에서도 GitLab 프로젝트가 보이지 않으면 순간적으로 GitLab 데이터가 모두 날아간 것처럼 느껴질 수 있습니다.

하지만 이 경우 실제 GitLab 데이터가 삭제된 것이 아니라, 컨테이너만 없어졌거나 현재 Docker context에서 보이지 않는 상태일 수 있습니다.

이번 글에서는 WSL/Docker 환경에서 GitLab CE 컨테이너가 사라진 것처럼 보였을 때, 원인을 확인하고 기존 데이터를 다시 마운트해서 GitLab을 복구한 과정을 정리합니다.

---

문제 상황

Windows PC를 재부팅한 뒤 WSL에서 GitLab을 확인했더니 기존 GitLab 컨테이너가 보이지 않았습니다.

처음에는 GitLab 프로젝트와 저장소 데이터가 모두 삭제된 것처럼 보였지만, 확인해 보니 GitLab 데이터는 Docker volume이 아니라 WSL 내부의 /srv/gitlab 경로에 bind mount 방식으로 저장되어 있었습니다.

즉, 핵심은 다음과 같습니다.

GitLab 컨테이너는 보이지 않음
Docker Compose 프로젝트도 보이지 않을 수 있음
하지만 /srv/gitlab/data 디렉터리에는 기존 GitLab 데이터가 남아 있음
docker-compose.yml로 컨테이너를 다시 만들면 기존 데이터를 다시 연결할 수 있음

---

원인 분석

이번 문제의 핵심 원인은 GitLab 데이터 삭제가 아니라, GitLab 컨테이너 또는 Docker Compose 프로젝트 상태가 사라졌거나 현재 Docker에서 보이지 않게 된 것입니다.

가능한 원인은 다음과 같습니다.

1. Windows 재부팅 후 Docker Desktop 또는 WSL Docker 엔진 상태가 바뀜
2. Docker context가 기존 WSL Docker 엔진이 아닌 다른 엔진을 보고 있음
3. 기존 GitLab 컨테이너가 삭제되었거나 중지된 상태임
4. Docker Compose 프로젝트 정보는 사라졌지만 bind mount 데이터는 남아 있음
5. GitLab 데이터가 named volume이 아니라 /srv/gitlab 경로에 저장되어 있었음

여기서 가장 중요한 부분은 GitLab 데이터 저장 방식입니다.

이번 환경에서는 GitLab 데이터가 Docker named volume이 아니라 아래 경로에 저장되어 있었습니다.

/srv/gitlab/config
/srv/gitlab/logs
/srv/gitlab/data

그리고 docker-compose.yml에서 이 경로들이 GitLab 컨테이너 내부로 마운트되고 있었습니다.

- "/srv/gitlab/config:/etc/gitlab"
- "/srv/gitlab/logs:/var/log/gitlab"
- "/srv/gitlab/data:/var/opt/gitlab"

따라서 컨테이너가 사라졌더라도 /srv/gitlab/data가 남아 있다면 GitLab 프로젝트, 저장소, DB 데이터는 복구 가능성이 높습니다.

---

1. Docker 기본 상태 확인하기

먼저 Docker에서 현재 보이는 컨테이너 목록을 확인합니다.

docker ps -a

전체 컨테이너 목록에서 gitlab 컨테이너가 보이지 않는다면, 컨테이너가 삭제되었거나 현재 Docker context에서 보이지 않는 상태일 수 있습니다.

Docker context도 확인합니다.

docker context ls

이 명령어로 현재 Docker CLI가 어떤 Docker 엔진을 바라보고 있는지 확인할 수 있습니다.

예를 들어 Docker Desktop 엔진을 보고 있는지, WSL 내부 Docker 엔진을 보고 있는지 확인해야 합니다.

Docker Compose 프로젝트 목록도 확인합니다.

docker compose ls -a

여기서 GitLab Compose 프로젝트가 보이지 않더라도 바로 데이터가 삭제되었다고 판단하면 안 됩니다.

Docker volume도 확인합니다.

docker volume ls

이번 환경에서는 GitLab이 Docker named volume을 사용하는 것이 아니라 /srv/gitlab/... 경로를 직접 마운트하는 bind mount 방식이었습니다.

---

2. GitLab compose 파일 위치 확인하기

GitLab 컨테이너를 다시 만들려면 기존 docker-compose.yml 파일이 있는 위치로 이동해야 합니다.

cd /home/greenitkr/gitlab-docker

현재 위치를 확인합니다.

pwd

파일 목록을 확인합니다.

ls -la

docker-compose.yml 파일이 있는지 확인합니다.

---

3. docker-compose.yml 내용 확인하기

이제 GitLab compose 파일 내용을 확인합니다.

sed -n '1,160p' docker-compose.yml

여기서 가장 중요하게 봐야 하는 부분은 GitLab 데이터 마운트 설정입니다.

아래와 같은 설정이 있어야 합니다.

- "/srv/gitlab/config:/etc/gitlab"
- "/srv/gitlab/logs:/var/log/gitlab"
- "/srv/gitlab/data:/var/opt/gitlab"

특히 가장 중요한 줄은 이것입니다.

- "/srv/gitlab/data:/var/opt/gitlab"

GitLab의 실제 데이터, 저장소, DB 관련 데이터가 /var/opt/gitlab 아래에 저장되기 때문입니다.

Compose 설정이 최종적으로 어떻게 해석되는지도 확인합니다.

docker compose config

이 명령어는 docker-compose.yml 파일이 Docker Compose에서 어떻게 적용되는지 최종 결과를 보여줍니다.

---

4. 기존 GitLab 데이터 경로 확인하기

기존 GitLab 데이터가 남아 있는지 확인합니다.

권한이 허용된다면 아래 명령어로 GitLab 저장소 디렉터리를 확인할 수 있습니다.

sudo find /srv/gitlab/data/git-data/repositories -maxdepth 4 -type d | head -80

만약 sudo 비밀번호 문제로 확인이 어렵다면, GitLab 컨테이너를 다시 올린 뒤 컨테이너 내부에서 확인해도 됩니다.

컨테이너가 올라온 뒤에는 아래 명령어로 확인할 수 있습니다.

docker exec gitlab ls -la /var/opt/gitlab/git-data/repositories

여기서 @hashed 디렉터리가 보이면 GitLab 저장소 데이터가 남아 있을 가능성이 높습니다.

---

5. GitLab 이미지 확인하기

컨테이너를 다시 만들기 전에 로컬에 GitLab CE 이미지가 남아 있는지 확인합니다.

docker images gitlab/gitlab-ce

이미지가 남아 있으면 기존 이미지를 사용해 컨테이너를 다시 생성할 수 있습니다.

이미지가 없더라도 docker compose up -d 실행 시 compose 파일에 지정된 이미지를 다시 받을 수 있습니다.

---

6. GitLab 컨테이너 다시 생성하기

반드시 docker-compose.yml 파일이 있는 디렉터리에서 실행해야 합니다.

cd /home/greenitkr/gitlab-docker
docker compose up -d

이 명령어는 docker-compose.yml 기준으로 GitLab 컨테이너를 다시 생성합니다.

이때 /srv/gitlab/data가 그대로 마운트되도록 설정되어 있다면, 새 컨테이너가 기존 GitLab 데이터를 다시 사용하게 됩니다.

즉, 컨테이너는 새로 만들어지지만 데이터는 기존 것을 그대로 연결하는 구조입니다.

---

7. GitLab 컨테이너 생성 상태 확인하기

컨테이너가 생성되었는지 확인합니다.

docker ps -a --filter name=gitlab

GitLab 시작 로그를 확인합니다.

docker logs gitlab --tail 120

처음에는 GitLab이 내부 설정을 다시 구성하면서 reconfigure 과정이 진행될 수 있습니다.

또한 바로 healthy 상태가 되지 않고 health: starting 상태로 보일 수 있습니다. GitLab은 PostgreSQL, Puma, Sidekiq 등 여러 서비스가 순차적으로 올라오기 때문에 몇 분 정도 기다려야 할 수 있습니다.

GitLab 내부 서비스 상태도 확인합니다.

docker exec gitlab gitlab-ctl status

정상적으로 올라오면 주요 서비스들이 run 상태로 표시됩니다.

run: gitaly
run: gitlab-kas
run: nginx
run: puma
run: sidekiq
run: postgresql

처음 실행 직후에는 일부 서비스가 아직 올라오는 중일 수 있으므로, 잠시 기다렸다가 다시 확인하면 됩니다.

---

8. GitLab 마운트 상태 확인하기

이번 복구에서 가장 중요한 확인 단계입니다.

GitLab 컨테이너가 기존 /srv/gitlab 데이터를 제대로 마운트하고 있는지 확인합니다.

docker inspect gitlab --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'

정상이라면 아래와 비슷하게 나와야 합니다.

/srv/gitlab/config -> /etc/gitlab
/srv/gitlab/logs -> /var/log/gitlab
/srv/gitlab/data -> /var/opt/gitlab

특히 가장 중요한 줄은 아래입니다.

/srv/gitlab/data -> /var/opt/gitlab

이 줄이 보여야 GitLab 컨테이너가 기존 데이터 디렉터리를 제대로 보고 있는 것입니다.

만약 /srv/gitlab/data -> /var/opt/gitlab 마운트가 없다면, 새 컨테이너가 빈 데이터 디렉터리를 사용하고 있을 수 있으므로 compose 파일을 다시 확인해야 합니다.

---

9. Git 저장소 파일 확인하기

이제 GitLab 저장소 파일이 실제로 보이는지 확인합니다.

docker exec gitlab ls -la /var/opt/gitlab/git-data/repositories

@hashed 디렉터리가 있는지 확인합니다.

GitLab은 최신 버전에서 저장소를 프로젝트명 그대로 저장하지 않고, @hashed 구조 아래에 저장합니다.

저장소 디렉터리 일부를 확인합니다.

docker exec gitlab find /var/opt/gitlab/git-data/repositories/@hashed -maxdepth 4 -name '*.git' -type d | head -50

저장소 개수도 확인합니다.

docker exec gitlab find /var/opt/gitlab/git-data/repositories/@hashed -name '*.git' -type d | wc -l

이번 상황에서는 저장소가 4개 확인되었습니다.

4

이 값이 0이 아니라면 Git 저장소 파일이 남아 있다는 뜻입니다.

---

10. GitLab DB 프로젝트 확인하기

저장소 파일이 남아 있어도 GitLab DB가 프로젝트 정보를 제대로 보고 있는지 확인해야 합니다.

GitLab 서비스가 완전히 올라온 뒤 아래 명령어를 실행합니다.

docker exec gitlab gitlab-rails runner 'puts Project.count; Project.limit(20).pluck(:full_path).each { |p| puts p }'

이 명령어는 GitLab DB에 등록된 프로젝트 개수와 프로젝트 경로를 출력합니다.

예를 들어 프로젝트 개수가 0이 아니고 기존 프로젝트 경로가 출력된다면, GitLab DB도 기존 데이터를 정상적으로 보고 있는 것입니다.

판단 기준은 다음과 같습니다.

Project.count가 0보다 크다
기존 프로젝트 full_path가 출력된다

이 경우 GitLab 데이터 복구가 정상적으로 된 것으로 볼 수 있습니다.

---

11. 접속 포트 확인하기

GitLab 컨테이너의 포트 매핑을 확인합니다.

docker ps -a --filter name=gitlab

정상이라면 아래와 같은 포트가 잡혀 있어야 합니다.

0.0.0.0:8929->8929/tcp
0.0.0.0:2424->22/tcp

웹 접속 주소는 다음과 같습니다.

http://localhost:8929

Git SSH 접속 포트는 다음입니다.

2424

브라우저에서 http://localhost:8929로 접속했을 때 기존 GitLab 화면과 프로젝트가 보이면 복구가 완료된 것입니다.

---

최종 점검 순서 요약

아래 순서대로 확인하면 됩니다.

cd /home/greenitkr/gitlab-docker

docker compose config
docker compose up -d

docker ps -a --filter name=gitlab
docker inspect gitlab --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'
docker logs gitlab --tail 120

docker exec gitlab gitlab-ctl status

docker exec gitlab ls -la /var/opt/gitlab/git-data/repositories
docker exec gitlab find /var/opt/gitlab/git-data/repositories/@hashed -name '*.git' -type d | wc -l

docker exec gitlab gitlab-rails runner 'puts Project.count; Project.limit(20).pluck(:full_path).each { |p| puts p }'

가장 중요한 판단 기준은 두 가지입니다.

1. /srv/gitlab/data -> /var/opt/gitlab 마운트가 정상인지
2. Project.count가 0이 아닌지

이 두 가지가 정상이라면 GitLab 컨테이너는 새로 생성되었더라도 기존 데이터를 제대로 사용하고 있는 것입니다.

---

적용 전후 상태 비교

항목문제 발생 시복구 후

GitLab 컨테이너	보이지 않음	다시 생성됨
Compose 프로젝트	보이지 않거나 비어 있음	docker compose up -d로 복구
GitLab 데이터	삭제된 것처럼 보임	/srv/gitlab/data에 남아 있음
저장소 파일	확인 필요	@hashed 아래에서 확인
프로젝트 DB	확인 필요	Project.count로 확인
웹 접속	불가	http://localhost:8929 접속 가능
SSH 포트	확인 필요	2424 사용

---

마무리

이번 문제는 GitLab 프로젝트 데이터가 실제로 삭제된 것이 아니라, Windows 재부팅 이후 Docker/WSL 환경에서 기존 GitLab 컨테이너나 Compose 프로젝트가 보이지 않게 된 상황이었습니다.

다행히 GitLab 데이터는 Docker named volume이 아니라 WSL 내부의 /srv/gitlab 경로에 bind mount 방식으로 저장되어 있었습니다.

따라서 기존 docker-compose.yml 파일을 기준으로 컨테이너를 다시 생성하면, /srv/gitlab/data가 다시 /var/opt/gitlab로 연결되면서 기존 GitLab 데이터와 프로젝트를 복구할 수 있었습니다.

이런 상황에서는 바로 데이터가 삭제되었다고 판단하지 말고, 아래 순서로 확인하는 것이 좋습니다.

1. docker ps -a로 컨테이너 존재 여부 확인
2. docker context ls로 Docker 엔진 확인
3. docker compose ls -a로 Compose 프로젝트 확인
4. docker-compose.yml에서 /srv/gitlab 마운트 확인
5. docker compose up -d로 컨테이너 재생성
6. docker inspect로 /srv/gitlab/data 마운트 확인
7. Git 저장소 @hashed 디렉터리 확인
8. gitlab-rails runner로 Project.count 확인

특히 GitLab Docker 환경에서는 컨테이너 자체보다 데이터 디렉터리 마운트가 어디로 잡혀 있는지가 훨씬 중요합니다.

컨테이너는 다시 만들 수 있지만, /srv/gitlab/data가 남아 있고 /var/opt/gitlab로 정상 마운트된다면 기존 GitLab 프로젝트는 복구할 수 있습니다.