[IT-방법] 도커 컴포즈 설치 백업 및 복구 가이드 – 데이터 손실 없는 안정적인 컨테이너 운영

데이터를 잃는 순간 시작되는 운영자의 악몽

새벽 2시, 갑작스러운 서버 알람에 잠에서 깨어나 로그를 확인했어요. 설상가상으로 중요한 데이터베이스 볼륨이 통째로 날아가 버렸다는 사실을 깨달았을 때의 그 막막함은 경험해 본 사람만이 알아요. 단순한 설정 오류라면 금방 고치겠지만, 고객의 소중한 정보나 서비스의 핵심 데이터가 사라진 상황이라면 이야기는 완전히 달라져요.

많은 개발자와 운영자가 도커 컴포즈 설치 백업의 중요성을 머리로는 알고 있지만, 정작 실무 환경에서 어떻게 자동화하고 검증해야 할지는 막막해해요. 단순히 파일을 복사하는 것만으로는 데이터 정합성을 보장할 수 없기 때문이에요. 컨테이너가 실행 중인 상태에서 파일을 복사하면 데이터가 깨질 위험이 아주 높아요.

오늘 이 글을 통해 단순한 백업을 넘어, 서비스 중단 없이 데이터를 안전하게 보호하고 어떤 재난 상황에서도 10분 안에 서비스를 정상화할 수 있는 복구 프로세스를 구축하는 방법을 알려드릴게요. 이 과정을 마칠 때쯤이면 여러분은 더 이상 서버 장애 앞에서 밤잠을 설칠 필요가 없을 거예요.

백업 시작 전 반드시 체크해야 할 준비물

무작정 백업 명령어를 입력하기 전에, 우리가 무엇을 보호해야 하는지 명확히 정의해야 해요. 도커 컨테이너 환경은 일반적인 물리 서버와는 구조가 완전히 다르기 때문이에요. 컨테이너 자체는 삭제되어도 상관없지만, 그 안에 담긴 데이터는 절대 사라지면 안 돼요.

우리가 집중해야 할 대상은 크게 세 가지예요. 첫째는 서비스의 뼈대인 docker-compose.yml 설정 파일이고, 둘째는 환경 변수가 담긴 .env 파일이에요. 마지막으로 가장 중요한 요소인 볼륨(Volumes)에 저장된 실제 데이터들이에요.

또한, 백업 데이터를 어디에 저장할지도 미리 결정해야 해요. 서버 내부 디스크에만 저장하는 것은 서버 자체가 고장 났을 때 아무런 의미가 없어요. 따라서 외부 스토리지나 클라우드 저장소를 연동하는 계획이 반드시 포함되어야 해요.

백업 저장소 유형별 특징 비교

실전! 도커 컴포즈 백업 및 복구 프로세스

이제 본격적으로 안정적인 도커 컴포즈 설치 백업복구 체계를 만들어 볼게요. 이 과정은 단순히 파일을 복사하는 것이 아니라, 데이터의 일관성을 지키는 데 목적을 두어야 해요.

STEP 1. 백업 대상 데이터와 경로 파악하기

가장 먼저 해야 할 일은 현재 운영 중인 서비스의 구성을 꼼꼼히 살피는 일이에요. 보통 docker-compose.yml 파일이 위치한 디렉토리가 프로젝트의 루트가 돼요. 이 디렉토리 안에는 설정 파일들과 함께 볼륨 데이터가 연결된 경로들이 적혀 있어요.

두 가지 유형의 볼륨을 확인해야 해요. 첫째는 호스트 머신의 특정 폴더를 직접 연결한 바인드 마운트(Bind Mount) 방식이고, 둘째는 도커가 관리하는 네임드 볼륨(Named Volume) 방식이에요. 바인드 마운트는 경로가 명확해서 찾기 쉽지만, 네임드 볼륨은 docker volume inspect 명령어를 통해 실제 저장 위치를 반드시 확인해야 해요.

STEP 2. 데이터 정합성을 위한 컨테이너 제어

데이터베이스(MySQL, PostgreSQL 등)를 운영 중이라면 가장 주의해야 할 단계예요. 데이터가 열심히 쓰여지고 있는 도중에 파일을 복사하면, 복구했을 때 데이터베이스가 깨져서 실행되지 않을 수 있어요. 이를 방지하기 위해 두 가지 전략 중 하나를 선택해야 해요.

가장 안전한 방법은 백업 직전에 서비스를 잠시 멈추는 거예요. docker compose stop 명령어를 사용하면 컨테이너 프로세스는 종료되지만, 데이터가 담긴 볼륨은 그대로 유지되므로 안전하게 압축할 수 있어요. 만약 서비스 중단이 절대로 허용되지 않는 환경이라면, 데이터베이스 자체의 덤프 기능(예: mysqldump)을 먼저 실행한 뒤 그 결과물(sql 파일)을 백업하는 방식을 택해야 해요.

STEP 3. 자동화 백업 스크립트 작성하기

매번 수동으로 백업할 수는 없으니, 쉘 스크립트를 하나 만들어 두는 것이 좋아요. 아래는 프로젝트 디렉토리와 볼륨 데이터를 날짜별로 압축하여 저장하는 예시 스크립트예요.

#!/bin/bash

# 변수 설정
BACKUP_DIR="/mnt/backups/docker"
PROJECT_DIR="/home/user/my-app"
DATE=$(date +%Y%m%d_%H%M%S)
FILENAME="backup_$DATE.tar.gz"

# 1. 백업 디렉토리 생성
mkdir -p $BACKUP_DIR

# 2. 컨테이너 일시 정지 (데이터 정합성 확보)
cd $PROJECT_DIR
docker compose stop

# 3. 프로젝트 파일과 데이터 볼륨 압축
tar -czf $BACKUP_DIR/$FILENAME $PROJECT_DIR

# 4. 컨테이너 다시 시작
docker compose start

# 5. 오래된 백업 삭제 (7일 경과한 파일)
find $BACKUP_DIR -type f -mtime +7 -name "backup_*.tar.gz" -delete

echo "Backup completed: $FILENAME"

STEP 4. 크론탭(Crontab)을 이용한 정기 스케줄링

작성한 스크립트를 매일 새벽 3시에 자동으로 실행하도록 설정해 볼게요. 리눅스 터미널에서 crontab -e 명령어를 입력하고 아래 줄을 추가하면 돼요.

0 3 * * * /bin/bash /home/user/scripts/backup.sh >> /home/user/logs/backup.log 2>&1

이렇게 설정하면 매일 정해진 시간에 백업이 수행되고, 그 결과가 로그 파일에 기록되어 나중에 문제가 생겼을 때 원인을 파악하기 아주 쉬워져요.

STEP 5. 실제 장애 복구 시나리오 실습

백업만큼 중요한 것이 바로 복구예요. 만약 서버가 완전히 날아갔다고 가정해 볼게요. 새 서버를 준비하고 도커 컴포즈 설치를 마친 후, 아래 순서대로 복구를 진행해요.

1. 백업 파일(.tar.gz)을 새 서버의 원하는 위치로 다운로드해요.
2. 압축을 해제하여 프로젝트 디렉토리를 복원해요: tar -xzf backup_20260722.tar.gz -C /home/user/
3. 해당 디렉토리로 이동하여 docker compose up -d 명령어를 실행해요.

이때 주의할 점은 기존에 사용하던 볼륨의 권한(Permission) 문제예요. 복구된 파일의 소유자가 도커 프로세스와 맞지 않으면 데이터 쓰기 오류가 발생할 수 있으니, chown 명령어로 적절히 조정해 주는 과정이 필요해요.

자주 하는 실수와 해결법

현장에서 운영자들이 가장 많이 저지르는 실수들을 정리했어요. 미리 알고 있으면 큰 사고를 막을 수 있어요.

• ❌ 실행 중인 DB를 그냥 압축하기 → 데이터 파일이 쓰기 작업 중이라 파일이 깨짐 → ✅ DB 덤프(Dump)를 먼저 수행하거나 컨테이너를 stop 상태로 전환하세요.
• ❌ .env 파일을 백업에서 제외하기 → 환경 변수(DB 비번 등)를 몰라 복구 실패 → ✅ 프로젝트 루트의 모든 설정 파일을 반드시 포함하세요.
• ❌ 백업 저장 공간 부족 → 백업 도중 디스크 가득 참 → ✅ 백업 전 디스크 용량을 체크하고, 외부 저장소(S3 등)로 자동 전송하세요.
• ❌ 복구 테스트 생략 → 백업은 성공했으나 정작 복구 시 작동 안 함 → ✅ 최소 한 달에 한 번은 별도 환경에서 복구 실습을 하세요.
• ❌ 볼륨 권한 설정 오류 → 복구 후 컨테이너가 데이터 쓰기 거부 → ✅ 복구 후 디렉토리 소유권을 도커 실행 계정에 맞춰 변경하세요.

자주 묻는 질문

Q. 백업 주기는 어느 정도가 적당할까요?

데이터가 변경되는 빈도에 따라 달라요. 결제 정보처럼 민감한 데이터는 실시간 혹은 시간 단위가 좋고, 일반적인 설정 파일은 하루에 한 번이면 충분해요. 서비스의 RPO(복구 지점 목표)를 먼저 정하세요.

Q. 컨테이너 내부 폴더를 직접 백업해도 되나요?

컨테이너 내부(Writable Layer)에 저장된 데이터는 컨테이너 삭제 시 함께 사라지므로 절대 백업 대상이 되어서는 안 돼요. 반드시 외부 볼륨(Volume)이나 바인드 마운트로 연결된 경로를 백업해야 해요.

Q. 클라우드 스토리지를 쓰면 비용이 너무 많이 들지 않을까요?

데이터가 자주 변하지 않는다면 AWS S3 Glacier 같은 저렴한 아카이브용 스토리지 계층을 활용하는 것을 강력히 추천해요. 비용보다 데이터 손실의 비용이 훨씬 크다는 것을 명심해야 해요.

Q. 백업 파일이 너무 커져서 전송이 힘들어요.

전체 데이터를 매번 백업하기보다는 변경된 부분만 저장하는 증분 백업(Incremental Backup) 방식을 고려해 보세요. 하지만 도커 환경에서는 설정이 복잡할 수 있으니, 우선은 압축률이 높은 tar.gz 형식을 잘 활용하는 것부터 시작하세요.

안정적인 운영을 위한 마지막 약속

도커 환경에서의 운영은 편리하지만, 그만큼 데이터의 위치를 정확히 파악하고 관리하는 능력이 중요해요. 오늘 배운 내용을 바탕으로 지금 바로 여러분의 서버 상태를 점검해 보세요.

백업은 완료하는 것이 끝이 아니에요. 실제로 복구 버튼을 눌렀을 때 데이터가 완벽하게 돌아오는지 확인하는 그 순간 비로소 완성되는 것이죠. 백업 파일은 보험과 같아요. 보험은 가입하는 것보다 실제로 사고가 났을 때 보상이 제대로 되는지를 확인하는 것이 훨씬 중요하니까요.

지금 바로 실행해 보세요:
1. 오늘 퇴근 전, 현재 볼륨 경로를 모두 리스트업하세요.
2. 이번 주 안으로 간단한 백업 스크립트를 작성해 보세요.
3. 다음 주에는 테스트용 서버에서 복구 테스트를 한 번만이라도 진행해 보세요.

복구는 실제로 한 번 해봐야 믿을 수 있습니다. 오늘 복구 테스트를 예약하세요.

관련하여 더 깊이 있는 내용이 궁금하다면 도커 컴포즈 기본 개념 완벽 정리 — 개념부터 실무 활용까지 한눈에 보는 가이드를 참고해 보세요.