[트러블슈팅] Kopia + rclone(Teldrive) 백업 저장소 손상 복구기

🎬 서론: 왜 이런 구성이었나

중요 폴더 몇 개를 압축 백업하고 싶었지만, Syncovery는 설정이 너무 복잡했다. 그래서 선택한 것이 Kopia — 중복 제거와 압축, 암호화를 지원하는 오픈소스 백업 도구. 저장소는 이미 사용 중이던 Teldrive(Telegram 기반 클라우드)와 PikPak을 rclone으로 마운트해서 쓰기로 했다(지난 일은 「Teldrive, PikPak 사용자를 위한 무료 스냅숏 백업 도구)」 참고 .

[로컬 PC]

   ↓ Kopia (스냅샷 생성)

[Kopia Repository] → Teldrive (주 저장소)

   ↓ sync-to

[PikPak] (보조 저장소)

목표는 명확했다.

- 매일 자동으로 스냅샷 생성
- 유지보수 후 절전모드 진입
- 가능하면 두 클라우드에 이중 백업

⚡ 1막: 문제의 시작

어느 날, KopiaUI에서 저장소 연결이 갑자기 안 됐다. 오류 메시지는 이랬다.

error loading index blob xn32_ea4a23af91f94e92...c1:

getContent: unable to complete GetBlob(...) despite 10 retries:

error populating output: unexpected EOF

저장소가 아예 열리지 않았다. KopiaUI는 계속 재시도를 반복했고, 결국 rclone 프로세스까지 죽어버렸다.

처음엔 이렇게 생각했다.

"색인 파일 하나만 손상된 거니까, 그거 삭제하면 되겠지."

하지만 그 색인 파일은 삭제해도 다시 나타났다. 캐시를 비우고 다시 연결해도 같은 오류가 반복됐다.

🔍 2막: 삽질의 연속

시도 1: 캐시 삭제

kopia cache clear

→ 실패. 저장소를 열어야 캐시 위치를 아는데, 저장소가 안 열리니 닭과 달걀 문제.

시도 2: 새 캐시 디렉토리로 연결

kopia repository connect rclone --remote-path=teldrive:/KopiaBackup --cache-directory=M:\KopiaCache2

→ 역시 실패! 캐시 폴더가 원인은 아니었다.

시도 3: 색인 파일 격리

문제의 파일들을 rclone으로 조회해봤지만, 원격(Teldrive)에는 존재하지 않았다. 로컬 캐시에만 남은 유령 파일이었다.

시도 4: index recover

kopia index recover --parallel=10 --commit

→ 실패. 저장소를 열 수 없으니 복구도 불가.

시도 5: 로그 분석

Kopia의 상세 로그를 뜯어보니 결정적인 단서가 나왔다.

[STORAGE] GetBlob "blobID":"xn33_b736d00b...","error":"error flushing dir cache: RC error:

Post \"https://127.0.0.1:xxxxx/vfs/forget\": error loading index blob xn32_ea4a..."

여기서 깨달았다. vfs/forget RC 호출 자체가 실패하고 있었다. 즉, rclone이 원격 저장소에서 데이터를 가져오지 못하고 있다는 뜻.

🎯 3막: 진짜 원인 발견

Teldrive의 백엔드가 Telegram 채널이라는 사실을 다시 떠올렸다. Teldrive는 각 파일을 Telegram 메시지로 저장한다. 그래서 Telegram 채널의 상태를 직접 점검해봤다.

그 결과:

Channels Processed:       9

Total Files Checked:      497563

Total Parts (DB):         665312

Total Messages (TG):      665566

Missing Files:            80       ← 파일은 사라졌는데 DB에는 남음

Orphan Messages:          254      ← 메시지는 있는데 DB 참조가 없음

Cleaned Files:            80

Cleaned Orphans:          254

원인이 명확해졌다.

- Missing Files 80개: DB에는 파일이 있다고 기록되어 있는데 실제 Telegram 메시지가 사라진 상태
- Orphan Messages 254개: Telegram에는 메시지가 남아 있는데 DB에서 참조하지 않는 상태

Kopia가 이 손상된 파일들 중 하나를 blob으로 읽으려 하니, Telegram에서는 메시지를 찾지만 실제 데이터가 없어서 unexpected EOF가 발생한 것이다.

이건 로컬 캐시 문제가 아니라, 원격 저장소 자체의 데이터 불일치였다.

✅ 4막: 해결

Teldrive의 점검 도구로 손상된 파일과 orphan 메시지를 정리했다.

All channels processed successfully

Cleaned Files: 80

Cleaned Orphans: 254

그리고 Kopia 저장소에 다시 연결했다.

kopia repository connect rclone --remote-path=teldrive:/KopiaBackup --cache-directory=M:\KopiaCache2

Connected to repository.

성공. 저장소 상태도 완벽하게 정상이었다.

kopia repository status

Read-only:           false

Unique ID:           c8ac08b5e••••••••••••••••••••38447e0c

Encryption:          AES256-GCM-HMAC-SHA256

Content compression: true

Current Epoch:       34

💡 5막: 이 사건에서 얻은 교훈

1. rclone 백엔드는 "실험적"이라는 경고를 진지하게 받아들여야 한다

Kopia는 rclone 백엔드를 사용할 때마다 이 경고를 띄운다.

"The rclone storage provider is not actively tested, it may cause data loss, use at your own risk"

이번 사건은 그 경고가 현실이 된 순간이었다. rclone 백엔드는 편리하지만, 원격 저장소의 무결성 문제에 그대로 노출된다.

2. "캐시 문제"와 "원격 데이터 문제"를 구분해야 한다

- 캐시 문제: 로컬 캐시를 비우거나 새 경로로 바꾸면 해결됨
- 원격 데이터 문제: 원격 저장소의 상태를 직접 점검해야 함

이번엔 후자였는데, 초반에 전자로 오판해서 시간을 낭비했다.

3. 클라우드 스토리지의 "숨은 레이어"를 이해해야 한다

Teldrive는 사용자에게는 단순한 클라우드 드라이브처럼 보이지만, 내부는 Telegram 채널 + DB 인덱스라는 복잡한 구조다. 이 레이어 사이에 불일치가 생기면 파일이 유실된 것처럼 보인다.

4. 주기적 검증이 필수다

# Kopia 스냅샷 무결성 검증

kopia snapshot verify --verify-files-percent=5 --parallel=4

# Teldrive 채널 상태 점검 (월 1회 권장)

이런 검증을 정기적으로 돌리면 문제를 조기에 발견할 수 있다.

5. 절전모드 진입 전 rclone 플러시 대기가 필요하다

이번 사건의 근본적인 발단은 사실 배치 파일이었다. 절전모드로 진입할 때 rclone VFS 캐시가 완전히 업로드되지 않은 상태로 PC가 꺼지면서, 반쪽짜리 파일이 원격에 남았다. 이게 반복되면서 Teldrive의 파일-메시지 불일치가 누적된 것이다.

배치 파일에 다음 로직을 추가해야 한다.

REM 절전 전 rclone 업로드 완료 대기

rclone rc vfs/forget

:WAIT_RCLONE

for /f "delims=" %%A in ('rclone rc core/stats 2^>NUL ^| findstr /C:"transferring"') do set "PENDING=%%A"

echo %PENDING% | findstr /C:"name" > NUL

if not errorlevel 1 (

    timeout /T 15 /NOBREAK > NUL

    goto WAIT_RCLONE

)timeout /T 30 /NOBREAK > NUL

rundll32.exe powrprof.dll,SetSuspendState 0,1,0

📌 정리: 재발 방지 체크리스트

항목	조치
절전모드 진입	rclone VFS 플러시 완료 후 진입
정기 검증	kopia snapshot verify 주 1회
원격 점검	Teldrive 채널 상태 월 1회 점검
이중 백업	sync-to로 PikPak 같은 다른 클라우드에도 복제
로그 보관	Kopia 로그와 배치 로그 주기적 확인
백업 메타데이터	kopia snapshot list --json 정기 백업

🎬 이번 사건의 교훈

이번 사건의 교훈을 한 줄로 요약하면 이렇다.

"편리함 뒤에는 항상 숨은 복잡성이 있다. 그리고 그 복잡성은 반드시 한 번은 문제를 일으킨다."

rclone + Kopia 조합은 강력하지만, "실험적"이라는 경고를 무시하면 언젠가 대가를 치른다. 이번엔 다행히 복구할 자료가 없어서 가볍게 넘어갔지만, 만약 중요한 자료였다면 어땠을까.

앞으로는:

1. 주 저장소는 로컬 또는 공식 지원 백엔드로

2. rclone은 보조 백업용으로만

3. 정기 검증을 생활화

이 세 가지를 지키면 이런 사건은 다시 일어나지 않을 것이다.

📝 에필로그

거의 하루 동안 이 문제를 붙잡고 씨름했다. 이쯤 되면 웬만한 사람은 “이 정도 했으면 포기하고 저장소를 새로 만들자”는 생각이 들 법도 하다. 나 역시 그 지경까지 갔다. 더군다나 딥시크도 불러보고, 영리하기로 소문난 클로드까지 불러봤지만, 둘 다 이 문제 앞에서는 꽤나 난감해했다.

각종 로그를 뒤지고, 캐시도 바꿔보고, 복구 명령도 시도하고, 끝내는 저장소를 초기화하는 방안까지 이야기가 흘러갔다. 그런데 바로 그 직전, “설마 이것 때문에?” 하는 마음으로 실행한 것이 바로 이 명령이었다.

teldrive check --clean-uploads

그리고 거짓말처럼 저장소가 다시 연결됐다.

결국 이번 사건의 해결책을 찾아낸 것은 딥시크도, 클로드도, 최신 AI의 놀라운 추론 능력도 아니었다. 마지막 순간까지 미련을 버리지 못한 사람이 던진 한 줄의 명령어였다.

뭐, 여기서 “역시 사람의 직관은 AI보다 위대하다!”라고 거창하게 선언하고 싶지만, 사실은 나도 그 명령어를 실행하기 전까지는 무슨 일이 벌어질지 전혀 몰랐다. 그러니까 직관이라기보다는 집착에 가까웠다고 하는 편이 정확하겠다. 😅

어쩌면 이번 사건에서 얻은 가장 큰 교훈은 백업 기술도, Teldrive도, rclone도, Kopia도 아닐지 모른다.

AI가 아무리 똑똑해도, 마지막에 “혹시 이것도 한번 해볼까?”라고 생각하는 집요한 사람 하나쯤은 필요하다.

그리고 덕분에 이번 사건은 저장소를 새로 만드는 것으로 끝나지 않고, 꽤 훌륭한 “AI들이 하루 종일 못 찾은 문제를 사람이 우연히 해결한 사건”으로 마무리되었다.