[Nas] rclone을 활용한 NAS-클라우드 백업, 치명적인 설정 실수와 복구 사례 연구

목차

• 1. 왜 rclone NAS 백업에서 사고가 자주 나는가
• 2. rclone 설정 전에 꼭 알아야 할 핵심 개념
• 2-1. Source(소스, 원본)와 Destination(대상지)의 방향
• 2-2. 동기화와 보관은 같은 말이 아닙니다
• 3. 실전 구성: 안전한 rclone NAS 백업 기본 뼈대
• 3-1. 운영용으로 조금 더 안전하게 만들기
• 4. 제가 실제로 겪은 치명적인 설정 실수
• 4-1. 사고 직후 가장 먼저 한 일
• 5. 복구 과정: 데이터 복구는 어떻게 접근했나
• 6. 트러블슈팅: 다시는 같은 사고를 내지 않기 위한 rclone 설정
• 7. 검증과 결과: 백업은 성공 로그보다 복구 테스트가 더 중요합니다
• 8. 자주 묻는 질문과 정리
• 8-1. copy만 써도 되나요?
• 8-2. 클라우드 동기화와 백업은 같은 말인가요?
• 8-3. 어떤 점이 가장 중요했나요?
• 9. 마무리: rclone NAS 백업은 도구보다 운영 습관이 더 중요합니다

[백업] rclone NAS 백업, 치명적인 설정 실수와 복구 사례

NAS를 오래 굴리다 보면 결국 한 번은 rclone NAS 백업을 진지하게 보게 됩니다. 저도 홈랩에서 사진, 문서, 설정 파일을 NAS에 몰아두고 쓰다가 어느 날 디스크 알림을 보고 식은땀이 나더라고요. 그래서 클라우드로 2차 백업을 붙였는데, 문제는 백업 도구보다 설정 방향이 더 무섭다는 점이었습니다. 특히 rclone은 강력한 만큼 실수했을 때 결과도 큽니다. 오늘은 제가 실제로 겪었던 클라우드 동기화 삽질과, 그 뒤에 어떻게 데이터 복구를 했는지 사례 중심으로 정리해보겠습니다.

혹시 '백업 한 줄 알았는데 동기화가 삭제를 전파했다' 같은 경험 있으신가요? 이 글은 그런 분들을 위해 쓰는 글입니다. 처음엔 저도 이게 뭔가 싶었는데, 구조를 이해하고 나니까 왜 사고가 났는지 보이더라고요.

NAS 원본 데이터, rclone 작업 경로, 클라우드 백업 저장소의 관계를 보여주는 개요 이미지입니다.

1. 왜 rclone NAS 백업에서 사고가 자주 나는가

rclone은 여러 스토리지 간 파일을 복사하고 동기화하는 CLI(Command Line Interface, 명령줄 인터페이스) 도구입니다. 쉽게 말해 NAS와 클라우드 사이에 짐을 옮기는 숙련된 기사님 같은 역할이죠. 문제는 기사님이 너무 성실해서, 제가 잘못 시키면 잘못된 작업도 아주 정확하게 해낸다는 겁니다 ㅎㅎ

여기서 중요한 포인트는 두 가지입니다.

• copy는 보통 원본을 대상에 복사합니다. 대상에 없는 파일을 채우는 쪽에 가깝습니다.
• sync는 원본 상태를 대상에 맞춥니다. 즉, 원본에서 사라진 파일은 대상에서도 제거될 수 있습니다.

백업 실패 사례 대부분은 성능 문제가 아니라, copy와 sync의 의미를 다르게 이해한 상태에서 운영에 넣는 것에서 시작하더라고요.

2. rclone 설정 전에 꼭 알아야 할 핵심 개념

2-1. Source(소스, 원본)와 Destination(대상지)의 방향

rclone 명령은 항상 앞이 원본, 뒤가 대상입니다. 말로 들으면 쉬운데 실제로 새벽에 급하게 치다 보면 여기서 사고가 납니다. 저도 처음엔 경로만 맞으면 되겠지 싶었는데, 딱 여기서 한 번 크게 미끄러졌습니다.

2-2. 동기화와 보관은 같은 말이 아닙니다

항목	copy	sync
주요 목적	복사, 누락분 채우기	원본 상태와 동일화
삭제 전파 위험	상대적으로 낮음	높음
초기 백업 용도	적합	주의 필요
운영 난이도	낮음	높음

그래서 저는 요즘 초기 적재(initial seed, 첫 데이터 적재)에는 copy, 검증이 끝난 뒤 제한적으로만 sync를 씁니다.

3. 실전 구성: 안전한 rclone NAS 백업 기본 뼈대

제가 홈랩에서 많이 쓰는 방식은 단순합니다. NAS의 특정 공유 폴더를 클라우드 리모트(remote, 원격 저장소)에 백업하고, 삭제 파일은 바로 날리지 않고 별도 보관 폴더로 밀어넣는 구조입니다. 이게 조금 번거로워 보여도, 사고 한 번 막아주면 본전 뽑고도 남습니다.

1. NAS에서 백업 대상 폴더를 분리합니다. 예: `/volume1/data`
2. rclone 리모트를 생성합니다. 예: `cloudbackup:`
3. 처음에는 반드시 `lsf`, `size`, `sync --dry-run`으로 확인합니다.
4. 운영 전에는 `--backup-dir` 같은 안전장치를 붙입니다.

아래는 실제로 제가 비슷한 방식으로 정리해두는 명령 예시입니다.

rclone lsf cloudbackup:
rclone size /volume1/data
rclone size cloudbackup:nas-backup

rclone sync /volume1/data cloudbackup:nas-backup \
  --dry-run \
  --progress \
  --checkers=8 \
  --transfers=4

--dry-run은 진짜 중요합니다. 실행은 안 하고, 무슨 일이 벌어질지만 보여주거든요. 귀찮아도 이 단계는 건너뛰지 마세요.

3-1. 운영용으로 조금 더 안전하게 만들기

rclone sync /volume1/data cloudbackup:nas-backup \
  --progress \
  --log-file=/var/log/rclone-nas-backup.log \
  --log-level=INFO \
  --backup-dir=cloudbackup:nas-deleted/$(date +%F) \
  --check-first

이 설정의 핵심은 삭제되거나 교체되는 파일을 바로 증발시키지 않고, backup-dir(백업 보관 디렉터리)로 보내는 것입니다. 완전한 스냅샷(snapshot, 시점 보관)은 아니지만, 실수 복구용 안전망으로 꽤 유용합니다.

초기 copy, 검증, 운영 sync, backup-dir 적용까지 이어지는 안전한 설정 흐름을 설명하는 이미지입니다.

4. 제가 실제로 겪은 치명적인 설정 실수

이제 본론입니다. 어느 날 백업 정책을 손보다가 원래는 아래처럼 실행해야 했습니다.

rclone sync /volume1/data cloudbackup:nas-backup

그런데 실제로는 반대로 쳤습니다.

rclone sync cloudbackup:nas-backup /volume1/data

짧은 명령 한 줄인데 파괴력은 엄청났습니다. 클라우드 쪽이 일부만 올라가 있던 상태였거든요. 결과적으로 NAS 쪽이 클라우드 상태에 맞춰지면서 파일이 사라지기 시작했습니다. 처음엔 로그가 빨리 지나가서 몰랐는데, 폴더 개수가 줄어드는 걸 보고 그때 '아, 잘못됐다' 싶더라고요. 진짜 등골이 서늘했습니다.

이런 백업 실패 사례가 무서운 이유는, 사용자는 '백업 중'이라고 생각하지만 실제로는 '정리 작업'이 진행될 수 있다는 점입니다. 특히 자동화 스케줄러(cron, 작업 예약)에 등록해두면 반복 피해까지 생길 수 있습니다.

4-1. 사고 직후 가장 먼저 한 일

1. 실행 중인 rclone 작업을 즉시 중단했습니다.
2. 자동 실행 스케줄을 비활성화했습니다.
3. NAS 원본 경로에 추가 쓰기를 멈췄습니다.
4. rclone 로그와 최근 삭제 파일 목록을 확보했습니다.

여기서 중요한 건 당황해서 다시 sync를 돌리지 않는 것입니다. 덮어쓰기 한 번 더 들어가면 복구 범위가 더 줄어들 수 있거든요.

5. 복구 과정: 데이터 복구는 어떻게 접근했나

복구는 '뭘 믿을 수 있느냐'부터 따져야 합니다. 저는 아래 순서로 확인했습니다.

1. 클라우드 저장소에 삭제 보관함이나 버전 관리 기능이 있는지 확인
2. 이전 백업 로그와 파일 목록 비교
3. 남아 있는 클라우드 데이터부터 읽기 전용으로 점검
4. 복구 대상만 별도 경로에 copy

예를 들어 클라우드 쪽에 아직 파일이 살아 있다면, 바로 원위치로 덮어쓰지 말고 임시 복구 폴더로 먼저 가져오는 게 안전합니다.

mkdir -p /volume1/recovery-restore

rclone copy cloudbackup:nas-backup /volume1/recovery-restore \
  --progress \
  --ignore-existing \
  --log-file=/var/log/rclone-recovery.log \
  --log-level=INFO

그다음 NAS 원본과 임시 복구본을 비교했습니다.

rclone check /volume1/recovery-restore /volume1/data \
  --one-way \
  --combined=/tmp/rclone-compare.txt

이 단계가 좋았던 이유는, 복구를 바로 반영하지 않고 차이를 먼저 볼 수 있었기 때문입니다. 실제로 써보니까 조급함만 버려도 성공 확률이 올라가더라고요.

만약 평소에 아래 같은 형태로 운영했다면 훨씬 쉬웠을 겁니다.

rclone sync /volume1/data cloudbackup:nas-backup \
  --backup-dir=cloudbackup:nas-deleted/2026-06-29

그러면 삭제되거나 바뀐 파일이 따로 남아 있어서, 필요한 것만 다시 복사하면 됩니다. 결국 복구 난이도는 사고 순간이 아니라 사고 전에 어떤 안전장치를 걸어뒀는가에서 갈리더라고요.

6. 트러블슈팅: 다시는 같은 사고를 내지 않기 위한 rclone 설정

• ⚠️ 운영 전 명령을 스크립트로 고정하고, 수동 타이핑을 줄입니다.
• ⚠️ 첫 실행은 반드시 `--dry-run`과 `rclone lsf`로 방향을 확인합니다.
• ⚠️ `sync`가 꼭 필요하지 않으면 `copy`부터 검토합니다.
• ⚠️ 삭제 대응이 필요하면 `--backup-dir` 또는 저장소의 버전 관리 기능을 함께 씁니다.
• 💡 로그 파일은 꼭 남기세요. 복구 때 생각보다 큰 힌트가 됩니다.

제가 지금은 아예 아래처럼 래퍼 스크립트(wrapper script, 실행 감싸기 스크립트)를 써서 실수를 줄입니다.

#!/usr/bin/env bash
set -euo pipefail

SRC='/volume1/data'
DST='cloudbackup:nas-backup'
STAMP=$(date +%F)

rclone sync "$SRC" "$DST" \
  --dry-run \
  --progress \
  --backup-dir="cloudbackup:nas-deleted/$STAMP"

처음엔 이 스크립트가 너무 보수적인가 싶었는데, 몇 번 운영해보니 이런 게 결국 사람을 살립니다.

7. 검증과 결과: 백업은 성공 로그보다 복구 테스트가 더 중요합니다

백업이 잘 됐는지는 파일 몇 개 올라간 걸로 판단하면 안 됩니다. 저는 최소한 아래 세 가지를 확인합니다.

1. 원본과 대상의 파일 수, 용량 추세가 크게 어긋나지 않는지
2. 샘플 파일을 실제로 복구했을 때 열리는지
3. 삭제 시나리오에서 backup-dir 또는 버전 관리가 동작하는지

rclone size /volume1/data
rclone size cloudbackup:nas-backup
rclone lsf cloudbackup:nas-deleted/$(date +%F) | head

이 과정을 거치고 나서야 비로소 '백업이 있다'고 말할 수 있더라고요. 단순 복사는 끝났을지 몰라도, 데이터 복구가 검증되지 않으면 진짜 백업이라고 보기 어렵습니다.

백업 로그, 파일 수 비교, 샘플 복구 성공 여부를 한눈에 확인하는 검증 화면 이미지입니다.

8. 자주 묻는 질문과 정리

8-1. copy만 써도 되나요?

많은 경우 됩니다. 특히 초기 구축이나 보수적 운영에서는 오히려 더 안전합니다. sync는 강력하지만 삭제 전파 위험을 이해한 뒤 써야 합니다.

8-2. 클라우드 동기화와 백업은 같은 말인가요?

아닙니다. 클라우드 동기화는 상태를 맞추는 데 가깝고, 백업은 복원 가능성을 보장하는 데 더 가깝습니다. 이름은 비슷한데 목표가 다릅니다.

8-3. 어떤 점이 가장 중요했나요?

저는 세 가지였습니다. 첫째, 방향 확인. 둘째, 삭제 보관. 셋째, 복구 테스트. 이 세 개만 챙겨도 rclone 설정 사고 확률이 꽤 줄어듭니다.

운영 전 점검해야 할 dry-run, backup-dir, 로그, 복구 테스트 항목을 요약한 체크리스트 이미지입니다.

9. 마무리: rclone NAS 백업은 도구보다 운영 습관이 더 중요합니다

rclone NAS 백업 자체는 정말 훌륭합니다. 저도 지금은 아주 만족하면서 쓰고 있습니다. 다만 이 도구는 친절한 GUI(Graphical User Interface, 그래픽 인터페이스)보다 명확한 명령에 충실한 타입이라, 운영자가 방향을 잘못 잡으면 그대로 따라갑니다. 저도 처음엔 헷갈렸고, 삽질 좀 했습니다 ㅎㅎ 그런데 그 덕분에 지금은 백업 설계를 할 때 무조건 복구 시나리오부터 생각하게 됐습니다.

정리하면 이렇습니다. rclone NAS 백업을 할 때는 처음부터 sync를 믿고 달리지 말고, 작은 범위에서 dry-run으로 검증하고, 삭제 보관 장치를 켜고, 반드시 복구 테스트까지 해보세요. 이거 진짜 편하더라고요. 다음 글에서는 `rclone mount`와 미디어 아카이브 운영 팁도 다뤄볼 예정입니다. 이전 글에서 다룬 스냅샷 백업 전략과 함께 보시면 더 도움이 될 겁니다. 🎉

📚 함께 읽으면 좋은 글

• TrueNAS ZFS 풀 확장: 성능 저하 없이 용량 늘리는 방법 분석
• Immich NAS 성능 벤치마크와 최적화
• Cloudflare NAS 원격 접속: Tunnel 연결 오류 디버깅 완벽 가이드
• TrueNAS 파일 시스템 성능 비교: ZFS, Btrfs, ext4 실측 벤치마크
• Proxmox OMV 연동: NAS 구축을 위한 최적의 조합 분석