[IT-방법] 도커 컴포즈 백업 실전 가이드 – 데이터 손실 없는 안전한 운영 절차

데이터를 지키는 5단계 실전 백업 및 복구 프로세스예요

이제 본격적으로 실제 운영 환경에서 적용 가능한 단계별 실행 전략을 알아볼게요. 단순히 명령어를 입력하는 것을 넘어, 장애 상황을 가정한 시나리오를 머릿속에 그리며 따라와 주세요.

STEP 1. 백업 대상 데이터의 정밀 식별하기

가장 먼저 해야 할 일은 도커 컴포즈가 관리하는 데이터가 실제로 서버 어디에 저장되어 있는지 찾아내는 일이에요. docker inspect 명령어를 사용하면 컨테이너가 사용하는 볼륨의 정확한 호스트 경로를 확인할 수 있어요. docker inspect [컨테이너명]을 실행한 후 Mounts 섹션을 꼼꼼히 살펴보세요.

예를 들어, MySQL 컨테이너가 db_data라는 볼륨을 사용하고 있다면, 이 데이터는 보통 /var/lib/docker/volumes/ 하위의 특정 경로에 존재해요. 만약 docker-compose.yml에서 상대 경로를 이용해 바인드 마운트를 설정했다면, 프로젝트 폴더 내의 특정 디렉토리가 백업 대상이 되겠죠. 이 경로들을 리스트로 정리해 두는 것이 첫 번째 단계예요.

STEP 2. 안정적인 자동 백업 스크립트 작성하기

매번 수동으로 백업할 수는 없으니, 셸 스크립트를 이용해 자동화해야 해요. 이때 가장 주의할 점은 데이터베이스의 경우 파일 복사만으로는 부족하다는 점이에요. DB가 동작 중일 때 파일을 그냥 복사하면 데이터의 일부만 기록되는 부분 쓰기(Partial Write) 현상이 발생해 복구가 불가능할 수 있어요.

따라서 다음과 같은 흐름의 스크립트 구조를 권장해요.

1. DB 컨테이너 내부에서 mysqldump 같은 명령어를 실행해 덤프 파일을 생성해요.
2. 생성된 덤프 파일과 일반 파일 시스템(볼륨) 데이터를 tar 명령어로 압축해요.
3. 압축된 파일명에 현재 날짜와 시간을 포함시켜 중복을 방지해요 (예: backup_20231027_0300.tar.gz).
4. 오래된 백업 파일을 삭제하여 디스크 용량을 관리해요.

실제로 사용할 수 있는 간단한 로직 예시는 다음과 같아요. docker exec [DB컨테이너] mysqldump -u [사용자] -p[비밀번호] [DB명] > /path/to/dump.sql 명령어를 먼저 실행한 뒤, 전체 디렉토리를 압축하는 식이죠. 이렇게 하면 데이터의 무결성을 지키면서도 전체 환경을 통째로 저장할 수 있어요.

STEP 3. 크론탭(Crontab)을 이용한 정기 실행 설정

스크립트가 준비되었다면, 이제 정해진 시간에 자동으로 돌아가도록 스케줄러를 설정해야 해요. 리눅스 시스템의 crontab을 사용하는 것이 가장 표준적이고 안정적이에요. crontab -e 명령어를 통해 스케줄을 등록할 수 있어요.

만약 매일 새벽 3시에 백업 스크립트를 실행하고 싶다면 0 3 * * * /path/to/backup_script.sh라고 등록하면 돼요. 이때 스크립트 내의 모든 경로는 절대 경로로 작성해야 한다는 점을 잊지 마세요. 크론탭은 환경 변수가 일반 로그인 세션과 다르기 때문에 상대 경로를 쓰면 파일을 찾지 못해 백업에 실패할 확률이 매우 높아요.

STEP 4. 외부 저장소로의 2차 백업 전송

서버 한 대에만 백업 파일을 저장하는 것은 진정한 의미의 백업이 아니에요. 만약 서버의 하드디스크 자체가 고장 난다면 백업 파일도 함께 사라지기 때문이죠. 이것을 단일 장애점(Single Point of Failure)이라고 불러요.

가장 권장하는 방법은 백업이 완료된 즉시 파일을 외부 저장소로 전송하는 거예요. AWS S3와 같은 클라우드 스토리지나, 별도의 백업 서버(NFS, SCP 활용)로 파일을 쏘아 올려야 해요. rclone 같은 도구를 사용하면 S3나 구글 드라이브 같은 다양한 클라우드 저장소로 파일을 아주 쉽게, 그리고 안전하게 전송할 수 있어요. 로컬 디스크에는 최근 3일 치만 남기고, 외부에는 30일 치를 남기는 식의 정책을 세우면 용량과 안정성을 모두 잡을 수 있어요.

STEP 5. 실제 복구(Restore) 시나리오 실습

백업만큼 중요한 것이 복구예요. 복구는 단순히 파일을 원래 자리에 갖다 놓는 것 이상의 과정이 필요해요. 실제 장애 상황을 가정해 다음 순서로 테스트해 보세요.

먼저, 현재 동작 중인 컨테이너를 docker-compose down으로 완전히 중지시켜야 해요. 그 다음, 기존의 오염되었거나 유실된 데이터 디렉토리를 비우고, 백업해 두었던 압축 파일을 다시 해제하여 원래의 경로에 배치하세요. DB의 경우 docker-compose up -d로 컨테이너를 올린 후, docker exec -i [컨테이너] mysql -u [사용자] -p[비밀번호] [DB명] < [덤프파일.sql] 명령어를 통해 데이터를 주입해야 해요. 이 전체 과정이 매끄럽게 진행되는지, 데이터의 개수나 내용이 일치하는지 반드시 확인해야 합니다.

자주 하는 실수와 해결법 및 궁금한 점들

현장에서 운영하다 보면 예상치 못한 변수들 때문에 백업이 실패하는 경우가 정말 많아요. 가장 흔하게 발생하는 문제들을 정리해 보았으니, 비슷한 상황을 겪고 있다면 바로 적용해 보세요.

• ❌ 실수: DB가 실행 중인데 파일만 압축했어요.
  왜 발생하는가: 데이터가 디스크에 기록되는 도중에 압축이 진행되어 데이터 구조가 깨지기 때문이에요.
  ✅ 해결법: 반드시 mysqldump나 pg_dump 같은 엔진 전용 도구를 사용하여 덤프 파일을 먼저 만든 후 압축하세요.
• ❌ 실수: 백업 파일의 권한(Permission) 문제입니다.
  왜 발생하는가: 도커 컨테이너가 생성한 파일은 루트(root) 권한인 경우가 많아 일반 사용자로 스크립트를 돌리면 읽지 못해요.
  ✅ 해결법: 백업 스크립트 실행 시 sudo를 사용하거나, 백업 직후 파일의 소유권을 적절히 변경하는 과정을 추가하세요.
• ❌ 실수: 디스크 용량이 가득 차서 백업이 중단됐어요.
  왜 발생하는가: 백업 파일 자체가 용량을 차지하는데, 오래된 파일을 지우는 로직이 없기 때문이에요.
  ✅ 해결법: 스크립트 마지막에 find /backup/path -mtime +7 -delete 같은 명령어를 넣어 7일이 지난 백업은 자동 삭제되게 만드세요.
• ❌ 실수: 백업은 성공했는데 복구가 안 돼요.
  왜 발생하는가: 백업 시점의 설정 파일(.env 등) 버전과 복구 시점의 버전이 다르기 때문이에요.
  ✅ 해결법: 데이터뿐만 아니라 docker-compose.yml과 환경 변수 파일도 반드시 세트로 묶어서 백업하세요.

자주 묻는 질문

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

서비스의 데이터 변경 빈도에 따라 달라요. 결제나 사용자 활동이 활발한 서비스라면 1시간 단위, 단순 정보성 블로그라면 하루 한 번 정도로 충분해요. 중요한 것은 주기보다 "언제든 복구할 수 있는 상태인가"를 확인하는 거예요.

Q. 백업 파일 용량이 너무 커서 서버에 부담을 줘요.

압축률을 높이거나, 백업 시점에 서비스 부하가 적은 새벽 시간대를 활용하세요. 또한, 모든 데이터를 한 번에 백업하기보다 변경된 부분만 저장하는 증분 백업 방식을 고려해 보는 것도 좋은 방법이에요.

Q. 클라우드 스토리지(S3 등)로 보낼 때 비용이 걱정돼요.

데이터의 중요도를 나누어 보세요. 전체 백업은 일주일 단위로 클라우드에 올리고, 일일 백업은 로컬에 짧게 유지하는 식으로 계층화하면 비용을 크게 절감할 수 있어요.

Q. 백업이 잘 되었는지 어떻게 확신할 수 있나요?

가장 확실한 방법은 정기적으로 "복구 훈련"을 하는 것이에요. 한 달에 한 번이라도 실제 데이터를 새 컨테이너에 올려보는 과정을 거쳐야만 진짜 백업이라고 할 수 있어요.

안전한 운영을 위한 마지막 점검과 다음 단계예요

도커 컴포즈 환경에서의 백업은 단순히 파일을 복사하는 행위가 아니라, 서비스의 생존권을 확보하는 전략적인 활동이에요. 오늘 배운 내용을 바탕으로 지금 당장 여러분의 서버를 점검해 보세요. 완벽한 준비만이 예기치 못한 재난으로부터 여러분의 소중한 서비스를 지켜줄 수 있어요.

이제 이론은 충분해요. 실행이 답입니다. 복구는 실제로 한 번 해봐야 믿을 수 있습니다. 오늘 바로 테스트용 컨테이너를 하나 띄워서, 데이터를 일부러 삭제해 보고 백업본으로 되살리는 연습을 시작해 보세요. 그 작은 시도가 여러분의 밤잠을 편안하게 만들어 줄 거예요.

🚀 지금 바로 할 일:

• 오늘 중으로 docker inspect를 실행해 백업 대상 경로 리스트 만들기
• 이번 주 내로 자동 백업 셸 스크립트 초안 작성하기
• 다음 주에 실제 복구 테스트 시나리오 작성하기

도커 운영에 대해 더 깊이 있는 지식이 필요하다면, 도커 컴포즈 기본 개념 완벽 정리 — 개념부터 실무 활용까지 한눈에 보는 가이드 글을 함께 읽어보시는 것을 추천드려요.