VM100·VM101 백업 쉽게 보기

한눈에 결론

VM100 자동 백업의 중심은 Local Copy 1이다.

매일 새벽 5시 31분에 Hyper Backup이 실행된다. 오늘도 정상 완료됐다.

오늘 결과: 성공 2026-06-24 05:31:54

VM101은 전체 백업이 아니라 부분 백업 위주다.

Syncthing 작업 폴더는 1년 버전관리가 켜져 있다. AutoTrans DB는 분기마다 백업된다.

Proxmox VM 백업 작업은 있지만, VM101은 최근 실패 중이라 조치가 필요하다.

05:31 Hyper Backup 실행 시간

05:50 Plex 스냅샷 실행 시간

112개 Plex 스냅샷 개수

1년 VM101 Syncthing 파일 변경 이력

Proxmox에도 VM 백업이 있다

Proxmox 호스트에는 vzdump 백업 작업이 설정되어 있다. 작업 이름은 vm100-101-to-ssd이고, 매일 04:30에 VM100과 VM101을 백업한다.

백업 작업	`/etc/pve/jobs.cfg`의 `vm100-101-to-ssd`
방식	`snapshot` 모드, `zstd` 압축, 최근 `5개` 보관
저장 위치	`vmbackup-ssd` = `/mnt/pve-vm-backup-ssd`
저장소 상태	약 `800G` 중 `676G` 사용, 남은 공간 약 `125G`, 사용률 `85%`

중요: VM101 백업 파일 하나가 보통 128G~141G 정도라, 현재 남은 공간 125G로는 새 백업을 끝까지 만들기 어렵다. 그래서 2026-06-16부터 VM101 백업이 계속 실패한 것으로 보인다.

Proxmox VM 백업 상태

대상	백업되는 것	최근 상태
VM100 `DSM`	Proxmox에 있는 작은 부팅 디스크 `ide0`만 백업된다. DSM에 직결된 6TB HDD들과 150G SSD는 `backup=0`이라 제외된다.	성공 최신 파일은 `2026-06-24 04:30`, 크기는 약 `1.9G`다.
VM101 `linuxs`	루트 디스크 `scsi0` `300G`만 백업된다. 14TB HDD, 700G NVMe cache, 150G cache 디스크는 `backup=0`이라 제외된다.	실패 중 최신 성공 파일은 `2026-06-15 04:30`이다. `2026-06-16`부터 `vma_queue_write: write error - Broken pipe`로 실패했다.

이 Proxmox 백업은 VM의 모든 패스스루 디스크를 담는 “완전 백업”이 아니다. VM 내부의 대용량 데이터는 각 VM 안의 백업 정책을 따로 봐야 한다.

백업 종류별 설명

1. Hyper Backup

DSM에서 제공하는 진짜 백업 기능이다. 파일을 다른 위치에 복사해서 나중에 복구할 수 있게 해준다.

현재 작업 이름은 Local Copy 1이고, 매일 05:31에 돈다.

2. Snapshot Replication

폴더의 특정 시점을 사진처럼 남기는 기능이다. 실수로 파일을 지웠을 때 예전 시점으로 돌아가 확인할 수 있다.

현재 Plex 폴더는 매일 05:50에 스냅샷이 찍힌다.

3. Cloud Sync

백업이라기보다는 동기화다. 한쪽에서 지워지면 다른 쪽도 지워질 수 있다.

그래서 Cloud Sync만 믿고 백업이라고 생각하면 위험하다.

4. USB Copy

USB 장치를 꽂았을 때 복사 작업을 할 수 있는 기능이다.

서비스는 켜져 있지만, DSM 예약작업에는 별도 자동 실행 스케줄이 보이지 않았다.

현재 켜진 것과 꺼진 것

Hyper Backup	켜짐 매일 05:31 백업 작업을 담당한다.
Snapshot Replication	켜짐 Plex 폴더 스냅샷을 담당한다.
Replication Service	켜짐 스냅샷 기능을 뒤에서 도와주는 서비스다.
Cloud Sync	켜짐 클라우드 동기화 서비스다. 백업과는 성격이 다르다.
USB Copy	켜짐 USB 복사용 서비스다.
Active Backup for Google Workspace	꺼짐 설치는 되어 있지만 지금은 작동하지 않는다.
Synology Drive Server	꺼짐 설치는 되어 있지만 지금은 작동하지 않는다.

예약 시간표

시간	작업	상태
`05:31`	Hyper Backup `Local Copy 1`	자동 실행 중
`05:50`	`Plex` 공유폴더 스냅샷	자동 실행 중
`06:00`	`docker` 공유폴더 스냅샷	자동 실행 꺼짐

docker 스냅샷 예약 항목은 남아 있지만 disabled 상태라 자동으로 새 스냅샷을 만들지 않는다.

남아 있는 스냅샷

폴더	남아 있는 개수	가장 오래된 것	가장 최신 것
`Plex`	112개	`2026-03-06 00:18:05`	`2026-06-24 05:50:01`
`docker`	96개	`2026-03-06 00:18:24`	`2026-06-08 06:00:01`

스냅샷은 DSM 안에서 /volume1/Plex/#snapshot, /volume1/docker/#snapshot 경로로 보인다.

오늘 백업 결과

시작	`2026-06-24 05:31:02`
종료	`2026-06-24 05:31:54`
결과	성공 `error_code=0`
경고	`node_modules/.bin` 아래 심볼릭 링크 파일들이 “불완전 백업”으로 기록됐다.

쉽게 말하면: 백업은 성공했지만, 개발용 node_modules 안의 바로가기 같은 파일들은 일부 완벽히 복사되지 않았다는 뜻이다. 보통 앱 소스는 package.json과 lockfile만 있으면 다시 설치할 수 있어서 치명적인 문제는 아닐 가능성이 크다.

헷갈리기 쉬운 점

백업은 예전 상태로 되돌릴 수 있게 따로 보관하는 것이다.
스냅샷은 같은 저장소 안에 “그 시점의 사진”을 남기는 것이다.
동기화는 두 위치를 같게 만드는 것이다. 삭제도 같이 따라갈 수 있다.

그래서 Cloud Sync는 편리하지만, 실수로 지운 파일을 살리는 백업으로 보면 안 된다.

확인된 특이사항

/volume1/@docker.hdd-backup-20260609에 Docker 백업 흔적이 많이 남아 있다. 정기 백업이라기보다는 2026-06-09 전후 마이그레이션/수동 백업 흔적으로 보인다.
/volume1/Plex/rn100/backups_오픈클로에는 roomescape_archive 백업 tar.gz 파일들이 있다. 최신 파일은 2026-05-27이라 지금 자동으로 계속 생성되는 작업은 아닌 것으로 보인다.
VM100의 DSM 디스크는 Proxmox 호스트에서 직접 건드리지 않는 것이 맞다. 이번 확인도 VM100 안에서만 읽기 전용으로 했다.

VM101 백업 한눈에 보기

VM101은 VM100처럼 DSM 백업 앱 하나로 정리되어 있지 않다. 폴더 동기화, 파일 버전 보관, 서비스별 DB 백업, 수동 rsync 백업이 섞여 있다.

켜짐 Syncthing 버전관리

분기 AutoTrans DB 백업

104G 14TB 안의 VM101 오픈클로 수동 백업

없음 확인된 전체 VM 정기 외부 백업

쉽게 말하면: VM101의 중요한 작업 폴더는 어느 정도 보호되고 있지만, VM101 전체를 매일 통째로 복구할 수 있는 자동 백업 체계는 아직 보이지 않는다.

VM101에서 자동으로 도는 것

작업	내용	상태
Syncthing 버전관리	`/home/ray/.openclaw/workspace/syncthing_오픈클로` 파일 변경 이력을 `.stversions`에 보관한다. 설정은 `staggered`, 최대 보관 기간은 1년이다. 현재 약 `3.0G`가 쌓여 있다.	켜짐
AutoTrans DB 백업	`/home/ray/ssd-sync/자막파일/autotrans.sqlite`를 `/home/ray/ssd-sync/자막파일/backups`에 백업한다. 다음 예정 시간은 `2026-07-01 03:43:12`이고, 최근 백업은 `autotrans.sqlite.20260620-122147.bak`이다.	분기 실행
dpkg DB 백업	리눅스 패키지 설치 목록을 `/var/backups`에 남긴다. `dpkg.status.0`, `apt.extended_states.0` 같은 파일이다. 사용자 파일 백업은 아니다.	매일 00:00

VM101에 남아 있는 수동 백업

위치	무엇을 담고 있나	판단
`/mnt/jellyfin14t/backups/vm101-openclaw-20260616-224157`	`/home/ray/.openclaw`를 rsync로 복사한 백업이다. 크기는 `104G`이고, 검증 dry-run 결과는 `0`이었다.	수동 백업 최신 링크는 `vm101-openclaw-latest`다.
`/home/ray/.openclaw/workspace/syncthing_오픈클로/90_백업_마이그레이션_오픈클로/server_migration_오픈클로`	`server_vm_migration_오픈클로_20260525_164437.tar.gz`와 sha256 파일이 있다. 크기는 약 `1.1G`다.	마이그레이션 백업
`/home/ray/.openclaw/workspace/syncthing_오픈클로/90_백업_마이그레이션_오픈클로/backups_오픈클로`	roomescape 계열 백업이 약 `2.7G` 있다. 최신 자동 백업 파일은 `2026-05-27`이고, 지금 계속 도는 타이머나 cron은 확인되지 않았다.	과거 백업
`/home/ray/.openclaw/workspace/media_streaming_오픈클로/jellyfin_오픈클로/backups`	Jellyfin DB와 설정 백업이 약 `266M` 있다. 확인된 파일은 `2026-06-03` 작업 흔적이다.	수동 백업
`/home/ray/.openclaw/workspace/media_streaming_오픈클로/komga_오픈클로/config_오픈클로/backups`	Komga DB 수리 전 백업이 약 `1.6M` 있다.	수동 백업
`/home/ray/.openclaw/workspace/automation_오픈클로/n8n_오픈클로/workflows_오픈클로/backups_오픈클로`	n8n 워크플로 JSON 변경 전 백업이 약 `980K` 있다. 최신 파일은 `2026-06-09`다.	수동 백업

VM101에서 백업이 아닌 것

npm-log-sync.timer는 NPM 로그를 주기적으로 가져오는 작업이다. 로그 보관에 가깝고, VM101 백업은 아니다.
matomo-log-import.timer, matomo-archive.timer는 방문 통계 처리 작업이다. 백업으로 보면 안 된다.
media-daily-library-scan.timer는 Jellyfin/Komga 미디어 스캔 시간 조절용이다. 파일을 보호하는 백업 작업은 아니다.
duplicity 프로그램은 설치되어 있지만, 연결된 정기 백업 타이머나 cron은 확인되지 않았다. restic, borg, rsnapshot, timeshift, rclone은 설치되어 있지 않았다.

다음에 결정할 것

docker 스냅샷을 계속 꺼둘지

Docker 데이터가 NVMe 쪽으로 옮겨진 뒤 의도적으로 끈 것인지 확인하면 된다.

Cloud Sync를 백업으로 착각하지 않기

중요한 자료는 Hyper Backup이나 스냅샷처럼 “되돌릴 수 있는 방식”으로 따로 보호하는 게 안전하다.

node_modules 경고 정리

개발 폴더까지 백업할 때 반복 경고가 싫다면 node_modules는 제외하고, 다시 설치 가능한 파일만 보존하는 방식도 가능하다.

VM101 전체 백업을 새로 만들지

지금 상태로는 VM101 전체 장애가 났을 때 “작업 폴더 일부 복구”는 가능하지만, VM 전체를 빠르게 되돌리는 구조는 약하다. 외부 백업을 도입한다면 VM101은 우선순위가 높다.

이 페이지 갱신 시각: 2026-06-24 KST. 서버 백업 설정은 바꾸지 않았고, 확인 결과만 정리했다.