Intel N100 홈서버 백업 자동화 : Compose·Volume·운영 데이터 보존 흐름 정리

 

 

※ 이 글은 운영자가 직접 홈서버를 운영하면서 얻은 경험과, Docker·rsync·cron 관련 공개 자료를 참고해 작성한 것입니다. 문장을 다듬거나 구성할 때는 일부 AI 도구를 활용했지만, 최종 내용은 운영자가 직접 꼼꼼히 확인했습니다.

Intel N100 홈서버 백업 자동화 : Compose·Volume·운영 데이터 보존의 흐름 정리

도입

월요일에는 Intel N100 홈서버에서 Docker Compose 운영 구조를 다시 정리했습니다. 서비스가 늘어나기 시작하면 compose.yml, .env, volume, 로그, 데이터 디렉터리가 서로 얽히기 때문에, 운영 구조를 먼저 정리하는 것이 중요했습니다.

화요일에는 다음 단계로 ‘무엇을 어떻게 보존할지’ 고민하게 됐습니다. 홈서버를 백업한다는 건 그저 파일을 한 번 복사하는 일과는 달랐어요. 컨테이너 이미지는 언제든 다시 다운로드할 수 있지만, 서비스 설정이나 실제 운영 데이터는 한 번 날아가면 쉽게 되살릴 수 없으니까요.

이번 글에서는 Docker Compose 기반 Intel N100 홈서버에서 compose.yml, .env, Docker volume, bind mount 데이터, 백업 스크립트, cron 자동화 흐름을 어떻게 정리했는지 기록합니다. 핵심은 “백업 파일이 존재하는가”보다 “실제로 복구할 수 있는가”였습니다.

Intel N100 홈서버에서 Compose 파일, .env, Docker volume, 운영 데이터를 기준으로 백업 자동화 흐름을 정리한 구조입니다.

※ 다이어그램은 운영 환경 설계를 바탕으로 AI 도구를 활용해 제작했으며, 최종 구성과 내용은 운영자가 직접 검수했습니다.
출처: 디지털 장난감

본문

컨테이너보다 운영 데이터가 더 중요했다

Docker 환경에선 컨테이너를 손쉽게 삭제하고 다시 만들 수 있습니다. 이미지는 필요하면 다시 받을 수 있고, Compose 파일만 남아 있다면 예전과 똑같은 구조로 서비스를 또 띄울 수 있죠. 그런데 실제 서비스에서 사용하는 데이터까지 지워진면 상황이 완전히 달라집니다. 

n8n의 워크플로우나 Reverse Proxy 설정, Portainer의 데이터, 각 서비스의 환경 변수, 미디어 서버의 메타데이터처럼 운영하면서 쌓인 데이터는 단순히 이미지를 다시 설치하는 것만으로는 복구할 수 없습니다. 그래서 백업할 때는 컨테이너 자체보다는, 데이터가 어디에 저장되어 있는지를 먼저 확인하는 것이 중요했습니다.

• compose.yml : 서비스 구성과 실행 구조
• .env : 포트, 경로, 시간대, 계정 관련 값
• Docker volume : 컨테이너 내부 서비스 데이터
• bind mount : 호스트 경로에 직접 저장된 데이터
• backup script : 반복 가능한 백업 절차

백업 대상은 Compose 구조에서 출발했다

월요일에 정리한 서비스 그룹 구조를 기준으로 백업 대상을 나누면 관리가 쉬웠습니다. 예를 들어 /opt/docker/proxy, /opt/docker/automation, /opt/docker/media처럼 디렉터리를 나눠두면, 어느 서비스의 설정과 데이터가 어디에 있는지 추적하기가 수월합니다.

/opt/docker/
├─ proxy/
│  ├─ compose.yml
│  ├─ .env
│  └─ data/
├─ automation/
│  ├─ compose.yml
│  ├─ .env
│  └─ data/
└─ media/
   ├─ compose.yml
   ├─ .env
   └─ config/

이 구조는 하나의 예시일 뿐이며, 실제 경로는 운영자의 기준에 따라 달라질 수 있습니다. 여기서 중요한 점은, 서비스 설정 파일과 실제 데이터의 경로가 서로 분리되어 혼란스럽지 않게 잘 정리되어 있어야 한다는 것입니다.

Docker volume 은 반드시 확인하고 넘어가야 했다

docker compose 파일에서 volume을 정의하면 데이터가 컨테이너가 삭제돼도 외부에 남아 보존됩니다. 하지만 이 volume이 실제로 어디에 저장되어 있고, 어떤 서비스가 이를 쓰고 있는지 정확히 파악하지 못하면, 중요한 데이터를 백업할 때 누락될 수 있습니다. 이런 이유로 volume 위치와 사용처를 꼼꼼히 관리해야 문제가 생기지 않습니다. 

# Docker volume 목록 확인
docker volume ls

# 특정 volume 상세 정보 확인
docker volume inspect 볼륨이름

# Docker 전체 사용량 확인
docker system df

docker volume inspect를 사용하면 해당 volume의 실제 마운트 위치와 관련 정보를 확인할 수 있습니다. 운영 환경에서는 Docker가 관리하는 내부 경로를 직접 손대기보다는, Compose를 활용하고 백업 정책을 세워서 안전하게 관리하는 것이 더 좋았습니다.

특히 docker volume prune이나 docker system prune --volumes 같은 명령은 사용하지 않는 volume을 정리할 수 있지만, 운영 데이터가 포함되어 있지 않은지 반드시 확인한 뒤 사용해야 합니다.

rsync는 단순 복사보다 운영 기록에 가까웠다

백업하는 방법에는 여러 가지가 있지만, 홈서버 운영에서는 rsync가 이해하기 쉬운 출발점이었습니다. rsync는 파일과 디렉터리를 동기화해주는 도구입니다. 여러 번 실행해도 변경된 부분만 골라서 처리해주기 때문에, 로컬 디렉터리나 외부 저장소를 백업할 때 꽤 편리하게 활용할 수 있었습니다.

# 예시: Docker 운영 디렉터리를 백업 경로로 복사
rsync -av /opt/docker/ /backup/docker/

여기서 -a 옵션은 archive 모드로 권한, 심볼릭 링크 등 여러 속성을 보존하는 데 사용되며, -v 옵션은 진행 내용을 자세히 보여줍니다. 실제로 운영할 때는 삭제 동기화가 꼭 필요한지, 제외해야 할 디렉터리가 있는지, 그리고 외부 디스크가 제대로 마운트되어 있는지도 함께 점검해야 합니다.

# 예시: 로그나 캐시성 디렉터리 제외
rsync -av --exclude='cache/' --exclude='tmp/' /opt/docker/ /backup/docker/

이 예시는 전체적인 구조를 이해하기 쉽게 설명한 것입니다. 실제로 제외해야 할 대상은 서비스 구조에 따라 달라질 수 있습니다. 특히 데이터베이스 파일이나 서비스가 실행 중인 상태의 데이터는 단순히 파일을 복사한다고 해서 항상 일관성이 보장되는 것은 아닙니다.

cron 자동화는 편리하지만 로그 확인이 필요했다

백업 명령을 매번 직접 실행하는 건 오래 하기 힘든 일입니다. 그래서 정해진 시간마다 자동으로 실행하려면 cron을 활용하면 좋습니다. cron은 리눅스에서 원하는 시간에 명령어나 스크립트를 알아서 실행해주는 오래된 도구입니다.

# 사용자 crontab 편집
crontab -e

# 등록된 cron 작업 확인
crontab -l

예를 들어 매일 새벽 3시에 백업 스크립트를 실행하려면 다음과 같은 형식을 사용할 수 있습니다.

0 3 * * * /usr/local/bin/docker-backup.sh >> /var/log/docker-backup.log 2>&1

cron에 등록만 되어 있다고 해서 백업이 제대로 끝났다고 단정할 수는 없습니다. 실제로는 로그 파일을 살펴보고, 백업 파일의 크기와 생성 시간을 직접 확인해야 합니다. 자동화는 말 그대로 작업을 대신해주는 도구일 뿐, 결과가 제대로 나왔는지까지 보장해주지는 않습니다.

백업 파일 존재와 복구 가능성은 다른 문제였다

이번 화요일 운영 기록을 돌아보며 가장 크게 와닿았던 점은, 백업 파일이 있다고 해서 항상 복구가 가능한 건 아니라는 사실이었습니다.

• compose.yml은 있지만 .env가 빠진 경우
• .env는 있지만 실제 volume 데이터가 빠진 경우
• 데이터는 있지만 복구 순서를 기록하지 않은 경우
• cron은 실행됐지만 백업 로그를 확인하지 않은 경우
• 외부 저장소가 마운트되지 않은 상태에서 백업이 실행된 경우

그래서 지금 상황에서는 ‘백업 자동화’보다 먼저 ‘복구 가능한 최소 구조’를 마련하는 것이 더 낫다고 판단했어요. 다시 말해, 어떤 데이터를 백업할지와 복구할 때의 순서를 같이 기록해두는 게 필요했습니다.

복구 순서도 운영 문서에 포함해야 했다

실제로 복구를 해야 할 때는 단순히 파일만 모아두는 것으로는 충분하지 않았습니다. 새 장비나 새로운 VM에서 서비스를 다시 시작하려면 어떤 순서로 작업을 진행해야 하는지 미리 정리해 두는 것이 중요합니다.

# 예시 복구 흐름
1. Docker와 Docker Compose 설치
2. /opt/docker 디렉터리 복원
3. compose.yml과 .env 확인
4. volume 또는 bind mount 데이터 복원
5. docker compose up -d 실행
6. docker compose ps와 logs로 상태 확인

실제 환경에 따라 이 순서는 달라질 수 있습니다. 그래도 적어도 Compose 파일과 환경 변수, 데이터 디렉터리, 실행 확인 절차까지 모두 갖춰야만 비로소 “백업했다”는 말이 운영 현장에서 제대로 된 의미를 갖게 됩니다.

운영 로그

아래 표는 3주차 화요일 기준으로 Intel N100 홈서버의 백업 자동화 점검 항목을 정리한 내용입니다. 실제 백업 위치나 방법은 사용하는 장비 구성이나 외부 저장소, 서비스 종류에 따라 얼마든지 달라질 수 있습니다.

점검 항목	확인 방법	운영 판단
Compose 파일	find /opt/docker -name "compose.yml"	서비스 구조 복구의 출발점
.env 파일	서비스 디렉터리별 확인	민감 정보 포함 여부와 백업 필요성 함께 점검
Volume 목록	docker volume ls	서비스 데이터 누락 방지
Docker 사용량	docker system df	백업 대상 용량 규모 확인
백업 실행	rsync -av	반복 가능한 복사 흐름 구성
자동 실행	crontab -l	예약 작업 등록 여부 확인
백업 로그	tail -n 100 /var/log/docker-backup.log	실행 성공 여부 확인

에디터의 해석 노트 (Editor's Lab Note)

• Docker 홈서버에서는 컨테이너 이미지보다 Compose 파일, .env, volume 데이터가 더 중요한 운영 자산이었습니다.
• rsync와 cron은 백업 자동화의 출발점이 될 수 있지만, 복구 가능성을 보장하지는 않았습니다.
• 백업 자동화보다 먼저 백업 대상과 복구 순서를 문서화하는 것이 더 안전했습니다.
• 현재 Intel N100 구성에서는 무리한 고급 백업 시스템보다 반복 가능한 최소 백업 루틴을 만드는 편이 현실적이었습니다.

참고 링크 (References)

1. Docker volumes documentation
2. docker volume ls reference
3. docker volume inspect reference
4. rsync documentation
5. crontab manual

트러블슈팅

문제: 백업 파일은 있지만 실제 복구에 필요한 구성 요소가 빠질 수 있음

홈서버 백업을 처음 할 때는 필요한 디렉터리만 복사하면 될 거라고 생각했어요. 그런데 Docker Compose 환경에서는 단순히 파일만 챙기면 부족하더라고요. 서비스 설정이나 환경 변수뿐만 아니라, 볼륨과 바인드 마운트로 저장되는 데이터까지 함께 백업해야 나중에 제대로 복구할 수 있습니다.

확인: Compose 파일, .env, volume, 데이터 디렉터리, 백업 로그를 함께 점검

# 서비스 구조 확인
find /opt/docker -name "compose.yml"

# volume 목록 확인
docker volume ls

# Docker 사용량 확인
docker system df

# 백업 로그 확인
tail -n 100 /var/log/docker-backup.log

# 예약 작업 확인
crontab -l

원인: 백업 대상을 파일 단위로만 보고, 실제 복구 순서와 데이터 위치를 함께 기록하지 않음

해결: compose.yml, .env, volume, bind mount 경로, 백업 스크립트, 복구 순서를 하나의 운영 문서로 관리

현재 구성에서는 백업 자동화 자체보다 복구 가능성을 기준으로 구조를 정리하는 편이 더 합리적이었습니다.

마무리

Intel N100 홈서버에서 Docker Compose로 서비스를 운영하다 보면, 백업이 선택이 아니라 필수라는 걸 실감하게 됩니다. 컨테이너는 언제든 다시 만들 수 있지만, 운영 중에 쌓인 데이터나 설정 파일은 한 번 잃으면 복구하기가 쉽지 않습니다. 그래서 백업은 자연스럽게 운영의 중요한 한 축이 됩니다.

이번 화요일 이야기의 핵심은 간단합니다. 백업 파일이 있다고 해서 바로 복구할 수 있는 건 아닙니다. 실제 운영 환경에서 제대로 된 백업이 되려면 Compose 파일, 환경 변수, 볼륨, 데이터 디렉터리, 그리고 복구 순서까지 모두 갖추고 있어야 합니다.

수요일에는 이 흐름을 계속 이어가려고 합니다. Docker 로그 회전 방법과, 서비스가 오래 운영될 때 디스크 사용량을 어떻게 관리하면 좋을지 정리해서 공유드릴게요.