Docker 데이터 손실 방지 Safety Guard 스크립트 구현 가이드

## 왜 Safety Guard가 필요한가? Docker와 같은 컨테이너 환경을 운영하다 보면 예상치 못한 순간에 데이터가 사라지는 사고가 발생합니다. `docker compose down -v` 한 줄로 수개월치 데이터가 날아가거나, 실수로 잘못된 서버에서 restore 명령을 실행하는 일은 생각보다 자주 일어납니다. 특히 여러 명이 함께 인프라를 관리하는 팀 환경, 또는 자동화 봇이 운영에 개입하는 환경에서는 이런 실수 가능성이 더욱 높아집니다. 이 글에서는 이러한 사고를 예방하기 위한 **Safety Guard 스크립트 패턴**을 소개합니다. --- ## 핵심 안전장치 설계 패턴 ### 1. 볼륨 데이터 존재 여부 사전 검사 (pre_start_check) 컨테이너를 시작하기 전, 연결된 볼륨에 실제 데이터가 존재하는지 먼저 확인합니다. ```bash #!/bin/bash # pre_start_check.sh VOLUME_PATH="/var/lib/docker/volumes/myapp_data/_data" MIN_SIZE_KB=10 actual_size=$(du -sk "$VOLUME_PATH" 2>/dev/null | cut -f1) if [ "${actual_size:-0}" -lt "$MIN_SIZE_KB" ]; then echo "[WARNING] 볼륨 데이터가 너무 작습니다 (${actual_size}KB). 컨테이너 시작을 중단합니다." exit 1 fi echo "[OK] 볼륨 검사 통과. 컨테이너를 시작합니다." ``` 이 스크립트는 볼륨 크기가 10KB 미만이면 경고를 출력하고 실행을 중단합니다. 빈 볼륨으로 컨테이너가 올라오는 최악의 상황을 막는 1차 방어선입니다. --- ### 2. 위험 플래그 차단 래퍼 (safe_docker_compose) `docker compose` 명령어를 직접 실행하는 대신, 위험한 옵션을 감지하는 래퍼 스크립트를 사용합니다. ```bash #!/bin/bash # safe_docker_compose.sh TODAY=$(date +%Y%m%d) REQUIRED_CONFIRM="DELETE-VOLUMES-${TODAY}" # -v 또는 --volumes 플래그 감지 if echo "$@" | grep -qE '(\s-v|--volumes)'; then echo "[DANGER] 볼륨 삭제 플래그가 감지되었습니다." echo "계속하려면 다음을 정확히 입력하세요: $REQUIRED_CONFIRM" read -r user_input if [ "$user_input" != "$REQUIRED_CONFIRM" ]; then echo "[ABORTED] 확인 문자열이 일치하지 않습니다. 작업을 중단합니다." exit 1 fi fi docker compose "$@" ``` 날짜를 포함한 확인 문자열(`DELETE-VOLUMES-20260218`)을 요구함으로써, 복사-붙여넣기나 자동화 스크립트에 의한 실수 실행을 효과적으로 차단합니다. --- ### 3. 복원 전 자동 백업 (safe_restore) DB restore를 실행하기 전에 반드시 현재 상태를 백업한 뒤 진행합니다. ```bash #!/bin/bash # safe_restore.sh BACKUP_FILE=$1 TIMESTAMP=$(date +%Y%m%d_%H%M%S) PRE_RESTORE_BACKUP="/backups/pre_restore_${TIMESTAMP}.dump" if [ -z "$BACKUP_FILE" ]; then echo "사용법: ./safe_restore.sh " exit 1 fi echo "[STEP 1] 현재 DB 상태를 백업합니다: $PRE_RESTORE_BACKUP" pg_dump -Fc mydb > "$PRE_RESTORE_BACKUP" if [ $? -ne 0 ]; then echo "[ERROR] 사전 백업 실패. restore를 중단합니다." exit 1 fi echo "[STEP 2] Restore를 진행합니다: $BACKUP_FILE" pg_restore -d mydb "$BACKUP_FILE" echo "[DONE] Restore 완료." ``` --- ### 4. 추가 권장 점검 항목 안전장치를 더욱 견고하게 만들려면 다음 항목도 함께 체크하는 것이 좋습니다. - **디스크 사용률 경고**: 80% 이상이면 작업 전 알림 - **DB 연결 가능 여부 사전 확인**: PostgreSQL 접속이 정상인지 검증 후 진행 - **운영 문서(SAFETY_RULES)**: 사람과 자동화 봇 모두가 지켜야 할 규칙을 문서화 --- ## 운영 환경 적용 방법 이 패턴은 단일 서버뿐 아니라 **여러 VM/서버에 동일하게 배포**할 때 진가를 발휘합니다. 각 서버에 동일한 스크립트를 배포하고, CI/CD 파이프라인이나 자동화 봇도 `docker compose` 대신 `safe_docker_compose.sh`를 호출하도록 설정합니다. ```bash # 안전한 컨테이너 시작 ./pre_start_check.sh && ./safe_docker_compose.sh up -d # 안전한 DB 복원 ./safe_restore.sh backup_20260218.dump ``` --- ## 결론 인프라 사고의 상당수는 실수나 부주의에서 발생합니다. Safety Guard 패턴의 핵심은 **위험한 작업을 불가능하게 만드는 것이 아니라, 충분히 불편하게 만드는 것**입니다. 날짜 기반 확인 문자열, 사전 검사, 자동 백업이라는 세 가지 레이어를 통해 대부분의 실수성 데이터 손실을 예방할 수 있습니다. 다음 단계로는 이 스크립트들을 팀 공용 저장소에 관리하고, 신규 팀원 온보딩 시 필수 교육 항목으로 포함시키는 것을 권장합니다.

컨테이너 환경 데이터 손실 방지를 위한 Safety Guard 구현 가이드

관련 글

AI 개발 도구 생태계: MCP 서버와 에이전트 스킬 소스 관리 가이드

Wiki.js API 권한 설정과 계정 생성 자동화 구축하기

AI 에이전트 시스템을 위한 커널 아키텍처 설계 가이드

이 주제에 대해 더 알아보고 싶으신가요?