Btrfs Proxmox NAS 구축 사례: 성능보다 복구와 스냅샷 운영

홈랩에서 Btrfs Proxmox NAS 조합을 검토할 때 제일 먼저 갈리는 지점은 하나입니다. “저장소를 VM 안으로 넣어 역할을 분리할까, 아니면 호스트에 바로 붙여 단순하게 갈까.” 저도 둘 다 꽤 오래 굴려봤는데, 테스트와 롤백이 잦은 환경이라면 Proxmox 가상 환경 안에 NAS VM을 두고 그 안에서 Btrfs를 운영하는 방식이 생각보다 꽤 실용적이더라고요. 특히 장애를 몇 번 겪고 나니, 이 구조의 진짜 장점은 스냅샷 자체보다 복구 단위를 세밀하게 나눌 수 있다는 점에 있었습니다.

물론 이 구성이 항상 정답은 아닙니다. VM 하나에 파일 공유, 미디어 보관, 백업 적재, VM 이미지 저장까지 다 몰아넣으면 Btrfs 장점보다 쓰기 패턴 충돌이 먼저 보이거든요. 반대로 NAS VM을 “공유 데이터와 백업의 운영 계층”으로 한정하고, 데이터베이스나 VM 디스크 이미지 같은 덮어쓰기 중심 워크로드를 분리하면 구조가 한결 안정적이었습니다. 이번 글은 제가 실제로 운영하면서 부딪힌 선택 기준, 실패 패턴, 명령어 수준의 운영 방법까지 한 번에 정리한 사례 기록입니다.

Proxmox 호스트, Btrfs NAS 게스트, 클라이언트 PC와 백업 대상이 연결된 전체 아키텍처 예시입니다.

왜 Btrfs Proxmox NAS 조합을 택했나

제가 이 조합을 유지한 이유는 “최고 성능” 때문이 아니라 복구 흐름이 예측 가능했기 때문입니다. 홈랩에서는 속도보다도, 뭔가 잘못됐을 때 어디까지 되돌릴 수 있는지가 더 중요할 때가 많더라고요. Proxmox 스냅샷은 VM 단위 복구에 빠르고, Btrfs 스냅샷은 공유 폴더나 백업 디렉터리처럼 데이터 단위 복구에 유리합니다. 둘이 비슷해 보여도 실제 쓰임새는 꽤 다릅니다.

• 역할 분리: 하이퍼바이저와 파일 서비스를 논리적으로 떼어내기 쉽습니다.
• 복구 단위 분리: VM 전체 롤백과 특정 공유 복원을 따로 판단할 수 있습니다.
• 서브볼륨 정책화: data, backup, media를 분리하면 보존 기간과 스냅샷 빈도를 다르게 가져가기 좋습니다.
• 운영 실험성: 공유 구조를 바꿔도 호스트 스토리지 레이아웃까지 함께 건드릴 일이 적습니다.

반대로 이 조합이 안 맞는 경우도 분명합니다. 대용량 순차 쓰기만 몰리는 저장소, 랜덤 덮어쓰기가 많은 DB 볼륨, VM 디스크 이미지를 NAS VM 내부 Btrfs에 다시 저장하는 중첩 구조는 추천하지 않습니다. 이런 환경에서는 유연성보다 CoW 부작용, 캐시 계층 중첩, 장애 분석 복잡도가 먼저 문제를 만듭니다.

Btrfs Proxmox NAS에서 좋은 점과 아쉬운 점

초보자 글에서는 Btrfs를 “스냅샷 되는 ext4 비슷한 파일시스템”처럼 설명하는 경우가 많은데, 실제 운영 감각으로 보면 그렇게 접근하면 거의 항상 꼬입니다. Btrfs는 파일시스템이면서 동시에 데이터 세트와 변경 이력을 같이 관리하는 계층에 가깝습니다. 그래서 공유 디렉터리를 정책 단위로 쪼개서 관리할 때는 정말 편한데, 덮어쓰기가 많은 단일 대용량 파일 위주 워크로드에는 장점이 약해집니다.

서브볼륨과 스냅샷은 폴더 분리가 아니라 운영 단위 분리입니다

data, backup, media를 나누는 이유는 보기 좋으라고가 아닙니다. 스냅샷 보존 기간, 복구 우선순위, 삭제 정책, 압축 적용 범위를 다르게 하기 위해서입니다. 예를 들어 backup은 매일 스냅샷을 남겨도 괜찮지만, 미디어 보관소인 media는 굳이 자주 남길 필요가 없을 때가 많습니다. 이 구분이 없으면 스냅샷 수만 늘고 복구 기준은 흐려집니다.

Copy-on-Write는 만능이 아니라, 쓰기 패턴에 따라 약점이 분명합니다

Btrfs의 CoW는 파일 변경 이력을 보존하고 스냅샷을 가볍게 만드는 핵심입니다. 다만 랜덤 덮어쓰기가 많은 파일에는 불리할 수 있습니다. 저는 아래처럼 나눠서 봅니다.

• 문서, 사진, 설정 백업, 프로젝트 아카이브: Btrfs와 잘 맞습니다.
• SQLite, VM 이미지, active DB dump 재작성 파일: 별도 볼륨으로 분리하거나 No_COW 적용을 미리 검토하는 편이 낫습니다.
• 다운로드 중인 토런트 작업 디렉터리: 조각화와 메타데이터 증가를 빨리 유발해 분리하는 쪽이 보통 낫습니다.

중요한 건 chattr +C를 만능 해법처럼 쓰지 않는 겁니다. 이 속성은 새 디렉터리나 빈 파일에 미리 적용해야 의미가 있고, 이미 기록된 데이터에는 결과를 장담하기 어렵습니다. 그래서 “문제 생기면 나중에 +C 붙이자” 식 접근은 대개 늦습니다.

제가 실제로 잡은 홈랩 NAS 구조

제가 선호한 구조는 단순합니다. Proxmox 호스트는 하이퍼바이저 역할만 맡고, NAS는 별도 리눅스 VM에서 처리합니다. 그리고 디스크는 가능하면 “큰 qcow2 파일 하나”보다 게스트가 블록 장치를 좀 더 직접적으로 인식하는 방식으로 붙입니다. 이유는 세 가지였습니다. 첫째, 패스스루나 HBA 경유라면 SMART와 I/O 에러 해석이 쉬워지는 경우가 많고, 둘째, 캐시 계층이 덜 꼬이며, 셋째, 장애가 났을 때 원인 추적 경로가 짧아집니다.

1. Proxmox 호스트에 NAS 전용 VM 생성
2. 디스크를 VirtIO SCSI 또는 개별 디스크 패스스루로 연결
3. 게스트 리눅스에서 Btrfs 파일시스템 생성
4. 서브볼륨 분리 후 UUID 기반 /etc/fstab 등록
5. Samba 또는 NFS 설정
6. scrub, balance, snapshot, 로그 점검 작업 예약

여기서 많이 하는 실수가 하나 있습니다. Proxmox 스냅샷과 Btrfs 스냅샷을 같은 목적으로 쓰는 것입니다. 둘 다 “되돌리기”라서 비슷해 보여도 운영 목적이 다릅니다. 그리고 VM 스냅샷의 정합성이 중요하다면 QEMU guest agent와 파일시스템 freeze 여부도 같이 확인하는 편이 안전합니다.

게스트 내부에서 /srv/nas 아래 data, backup, media 서브볼륨을 나눈 예시 구조입니다.

Btrfs Proxmox NAS 실전 구현 1: 파일시스템 생성과 마운트

예시는 Debian 또는 Ubuntu 계열 게스트 기준입니다. 디스크가 /dev/sdb로 보인다고 가정하지만, 실제 작업 전에는 반드시 장치명을 다시 확인해야 합니다. 이 단계는 감으로 하면 안 됩니다. 홈랩에서 제일 복구하기 어려운 사고가 “잘못된 디스크 포맷”이거든요.

apt update
apt install -y btrfs-progs samba sysstat smartmontools

lsblk -e7 -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,MODEL,SERIAL
blkid
wipefs -n /dev/sdb

mkfs.btrfs -L nasdata /dev/sdb

mkdir -p /mnt/btrfs-root
mount /dev/sdb /mnt/btrfs-root

btrfs subvolume create /mnt/btrfs-root/@data
btrfs subvolume create /mnt/btrfs-root/@backup
btrfs subvolume create /mnt/btrfs-root/@media
btrfs subvolume create /mnt/btrfs-root/@snapshots

umount /mnt/btrfs-root

mkdir -p /srv/nas/data /srv/nas/backup /srv/nas/media /srv/nas/.snapshots

UUID=$(blkid -s UUID -o value /dev/sdb)

mount -o noatime,compress=zstd:3,subvol=@data UUID=$UUID /srv/nas/data
mount -o noatime,compress=zstd:3,subvol=@backup UUID=$UUID /srv/nas/backup
mount -o noatime,compress=zstd:3,subvol=@media UUID=$UUID /srv/nas/media
mount -o noatime,compress=zstd:3,subvol=@snapshots UUID=$UUID /srv/nas/.snapshots

btrfs filesystem show
btrfs subvolume list -t /srv/nas/data

여기서 옵션 선택 이유를 짚어보면 이렇습니다.

• compress=zstd:3: 텍스트, 문서, 설정 파일 비중이 있는 NAS에서 무난했습니다. 이미 압축된 미디어 위주라면 효과는 제한적입니다.
• noatime: 접근 시간 갱신 쓰기를 줄여 자잘한 I/O를 줄입니다.
• 최근 커널과 btrfs-progs에서는 free-space-tree가 기본인 경우가 많아서 space_cache=v2를 굳이 적지 않아도 되는 환경이 많습니다.

제가 운영하면서 얻은 팁 하나는, 처음부터 스냅샷 저장 위치도 @snapshots처럼 별도 서브볼륨으로 분리해두는 겁니다. 스냅샷을 원본 서브볼륨 바로 아래에만 늘어놓으면 나중에 삭제 자동화할 때 경로 실수가 나기 쉽더라고요. 이거 진짜 한 번 꼬이면 꽤 귀찮습니다.

다음은 /etc/fstab 예시입니다.

UUID=11111111-2222-3333-4444-555555555555  /srv/nas/data       btrfs  noatime,compress=zstd:3,subvol=@data       0 0
UUID=11111111-2222-3333-4444-555555555555  /srv/nas/backup     btrfs  noatime,compress=zstd:3,subvol=@backup     0 0
UUID=11111111-2222-3333-4444-555555555555  /srv/nas/media      btrfs  noatime,compress=zstd:3,subvol=@media      0 0
UUID=11111111-2222-3333-4444-555555555555  /srv/nas/.snapshots btrfs  noatime,compress=zstd:3,subvol=@snapshots  0 0

실제 적용 전에는 숫자를 그대로 붙여넣지 말고 반드시 blkid로 확인하세요. 그리고 수정 후에는 아래처럼 검증하는 편이 안전합니다.

mount -a
findmnt -t btrfs
btrfs filesystem usage -T /srv/nas/data

Btrfs Proxmox NAS 실전 구현 2: Samba 공유와 스냅샷 운영

SMB 공유는 기능보다도 권한 해석이 일관적인지가 중요합니다. 홈랩에서는 성능보다 권한 꼬임 때문에 시간을 더 많이 쓰게 되더라고요. 아래 예시는 최소 구성인데, 저는 공유 목적별로 권한을 일부러 다르게 둡니다. 백업 공유는 쓰기 주체를 줄이고, 일반 데이터 공유는 팀이나 가족 계정에 맞춰 그룹 권한을 조금 더 넓게 둡니다.

[global]
   workgroup = WORKGROUP
   server string = Btrfs NAS VM
   security = user
   map to guest = Bad User
   load printers = no
   printing = bsd
   disable spoolss = yes
   ea support = yes
   vfs objects = acl_xattr
   map acl inherit = yes
   store dos attributes = yes

[data]
   path = /srv/nas/data
   browsable = yes
   read only = no
   valid users = nasuser
   force group = nas
   create mask = 0664
   directory mask = 0775

[backup]
   path = /srv/nas/backup
   browsable = yes
   read only = no
   valid users = nasbackup
   force group = nasbackup
   create mask = 0660
   directory mask = 0770

설정 후에는 서비스 재시작만 하지 말고, 문법과 실제 접근을 둘 다 확인해야 합니다. 이런 확인 절차를 한 번만 습관 들여도 시간을 꽤 아낄 수 있습니다.

testparm -s
systemctl restart smbd
systemctl enable smbd
smbclient -L localhost -U nasuser
smbclient //localhost/data -U nasuser -c 'ls'

스냅샷은 저는 공유 전체를 한 덩어리로 남기지 않고, 서브볼륨 단위로 따로 관리합니다. 그래야 복구할 때 선택이 단순합니다.

mkdir -p /srv/nas/.snapshots

btrfs subvolume snapshot -r /srv/nas/data /srv/nas/.snapshots/data-$(date +%F)
btrfs subvolume snapshot -r /srv/nas/backup /srv/nas/.snapshots/backup-$(date +%F)

btrfs subvolume list /srv/nas/.snapshots

# 읽기 전용 스냅샷에서 특정 시점 복구
btrfs subvolume snapshot /srv/nas/.snapshots/data-2026-08-24 /srv/nas/data-restore
rsync -aHAX --info=progress2 /srv/nas/data-restore/ /srv/nas/data/

복구할 때 바로 원본 위에 덮지 않고 data-restore로 한 번 펼쳐 확인하는 이유는, 실제 사고 상황에서는 “삭제 복구”보다 “원치 않는 오래된 상태로 되돌리는 실수”가 더 무섭기 때문입니다. 특히 여러 사용자가 동시에 접근하는 공유라면 더 그렇습니다.

testparm, btrfs subvolume snapshot, smbclient로 구성 검증하는 흐름을 보여주는 이미지 위치입니다.

⚠️ 제가 실제로 겪은 문제와 해결 과정

운영하면서 가장 헷갈렸던 건 용량 자체보다 공간이 어떻게 배치되어 있는지였습니다. Btrfs는 “남은 GB”만 봐서는 상태 판단이 잘 안 됩니다. 특히 작은 파일이 많고 스냅샷이 누적될수록, 데이터보다 메타데이터 청크 상태가 먼저 문제를 일으키는 경우가 있습니다.

실패 모드 1: 데이터는 남아 보이는데 쓰기가 실패하는 경우

제가 재현했던 상황은 이렇습니다. 작은 파일이 많은 프로젝트 백업 디렉터리를 여러 번 복사하고, 그 사이에 스냅샷을 반복 생성했습니다. 그다음 새 파일을 쓰려니 No space left on device가 나왔습니다. df로 보면 공간이 남아 있었는데도요. 근본 원인은 메타데이터 청크 사용률과 데이터 청크 분포가 비대칭적으로 꼬였기 때문이었습니다.

btrfs filesystem usage /srv/nas/data
btrfs filesystem df /srv/nas/data
btrfs balance start -dusage=75 -musage=75 /srv/nas/data

여기서 중요한 건 full balance를 습관적으로 돌리지 않는 겁니다. 운영 중 balance는 생각보다 오래 걸릴 수 있고, I/O 부하도 꽤 큽니다. 저는 보통 -dusage, -musage로 필요한 범위만 정리합니다. “왜 공간이 부족해졌나”를 보지 않고 무조건 balance부터 돌리면, 증상만 잠깐 눌러놓고 패턴은 그대로 남는 경우가 있더라고요.

실패 모드 2: 성능이 들쑥날쑥한데 원인이 안 보이는 경우

이건 Proxmox와 게스트 캐시가 겹칠 때 자주 헷갈립니다. 파일 복사 첫 번째는 빠르고 두 번째는 더 빠른데, 다른 디렉터리로 바꾸면 다시 느려지는 패턴이 대표적입니다. 이런 경우 단순 벤치마크 숫자보다 캐시가 아닌 워크로드를 섞어서 보는 것이 중요했습니다. 저는 같은 파일 하나만 반복 복사하는 테스트는 거의 신뢰하지 않습니다.

• 큰 파일 1개 복사
• 작은 파일 수천 개 복사
• 스냅샷 생성 직후 복사
• SMB 경유 복사와 게스트 내부 로컬 복사 비교

이 네 가지를 섞어보면 병목 위치가 꽤 잘 드러납니다. SMB만 느리면 네트워크 또는 Samba 설정, 내부 로컬도 느리면 파일시스템 또는 디스크 경로를 의심하는 식입니다.

실패 모드 3: 스냅샷은 많지 않은데 삭제 후에도 공간이 안 돌아오는 경우

이건 Btrfs를 처음 쓸 때 가장 당황하기 쉬운 패턴입니다. 스냅샷, 공유 파일, 중복 블록 참조가 얽혀 있으면 “삭제했는데 왜 안 줄지?”가 자연스럽게 나옵니다. 이때는 du보다 btrfs filesystem usage와 qgroup 사용 여부, 스냅샷 참조 상태를 봐야 합니다. 단순히 휴지통을 비웠다고 공간이 즉시 선형적으로 줄어드는 구조는 아니거든요.

scrub와 device stats는 루틴으로 보는 편이 낫습니다

btrfs scrub start -Bd /srv/nas/data
btrfs scrub status /srv/nas/data
btrfs device stats /srv/nas/data
smartctl -a /dev/sdb

• scrub status에서 uncorrectable errors가 보이면 파일시스템만 볼 문제가 아닙니다. 실제 디스크 상태, 케이블, HBA, USB-SATA 브리지까지 함께 봐야 합니다.
• btrfs device stats의 write_io_errs, read_io_errs, flush_io_errs, corruption_errs는 누적값입니다. 한 번의 숫자보다 증가 추세가 중요합니다.
• smartctl은 패스스루나 장치 노출 방식에 따라 게스트에서 바로 안 보일 수 있습니다. 이 경우 호스트 측 SMART 정보와 함께 보는 편이 정확합니다.

성능 해석은 벤치마크 숫자보다 병목 위치를 읽는 쪽이 낫습니다

iostat -x 1
vmstat 1
journalctl -u smbd -f
dmesg -Tw | egrep -i 'btrfs|blk|I/O|error|reset'

• iostat -x 1에서 특정 디스크의 await가 계속 높고 %util이 바닥이 아니라면 저장장치 또는 연결 계층 병목을 먼저 봅니다.
• vmstat 1에서 wa가 계속 높다면 CPU가 느린 게 아니라 I/O 대기일 가능성이 큽니다.
• journalctl -u smbd -f에서 세션 재연결이 반복되면 파일시스템보다 네트워크, 인증, 잠금 설정 문제일 수 있습니다.
• dmesg에 reset, timeout, I/O error가 섞이면 Btrfs 자체보다 하부 장치 문제를 먼저 해결해야 합니다.

디스크 노출 방식은 성능보다 장애 해석성에서 갈립니다

제 경험상 많은 글이 “패스스루가 빠르다” 수준에서 끝나는데, 실무적으로 더 중요한 건 문제가 났을 때 무엇이 잘못됐는지 빨리 읽히느냐입니다. 성능이 약간 아쉬운 구조보다, 에러 원인이 명확한 구조가 운영 비용을 줄입니다.

개인적으로 NAS를 오래 굴릴 생각이라면, 처음부터 “나중에 로그를 보고 원인을 읽기 쉬운가”를 기준으로 연결 방식을 고르시는 편이 좋습니다. 홈랩은 장애를 통해 배우는 환경인데, 원인 추적이 안 되면 배울 것도 줄어들더라고요.

운영 자동화: 귀찮은 작업만 자동화해도 체감이 큽니다

처음엔 수동으로 해도 되지만, scrub와 스냅샷은 결국 빼먹게 됩니다. 저는 최소한의 cron만 넣고 시작했습니다. systemd timer로 옮겨도 되지만, 홈랩에서는 유지 가능한 단순함도 꽤 중요하거든요.

crontab -e

# 매주 일요일 새벽 scrub
0 3 * * 0 /usr/bin/btrfs scrub start -Bd /srv/nas/data

# 매일 새벽 읽기 전용 스냅샷 생성
10 2 * * * /usr/bin/btrfs subvolume snapshot -r /srv/nas/data /srv/nas/.snapshots/data-$(date +\%F)

# 14일 지난 data 스냅샷 정리
30 2 * * * /usr/bin/find /srv/nas/.snapshots -mindepth 1 -maxdepth 1 -type d -name 'data-*' -mtime +14 -exec btrfs subvolume delete {} \;

여기서 제가 특히 강조하는 건 find 범위를 좁히는 겁니다. -mindepth 1, -maxdepth 1, 명확한 이름 패턴은 거의 필수에 가깝습니다. 경로가 느슨하면 삭제 자동화는 언젠가 사고를 냅니다.

조금 더 안전하게 가고 싶다면 로그를 남기세요. 이건 나중에 정말 차이가 납니다.

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

TARGET=/srv/nas/data
SNAPROOT=/srv/nas/.snapshots
STAMP=$(date +%F)

btrfs subvolume snapshot -r "$TARGET" "$SNAPROOT/data-$STAMP"
find "$SNAPROOT" -mindepth 1 -maxdepth 1 -type d -name 'data-*' -mtime +14 -print -exec btrfs subvolume delete {} \;

이 정도만 해도 “언제 무엇이 삭제됐는지”를 추적하기가 훨씬 수월합니다. 홈랩이라고 해서 로그를 안 남기면, 나중에 본인이 제일 답답해집니다.

Btrfs 상태 점검과 I/O 관찰을 한 화면에서 보는 운영용 대시보드 예시입니다.

언제 이 구성을 쓰고, 언제 피해야 하나

제가 실제로 운영한 기준으로 말씀드리면 선택은 꽤 명확합니다.

• 쓰는 게 맞는 경우: 파일 공유, 사진 보관, 설정 백업, 프로젝트 아카이브, 컨테이너 볼륨 백업처럼 시점 복구 가치가 큰 데이터
• 보류하는 게 맞는 경우: 고빈도 덮어쓰기 DB 파일, VM 디스크 이미지 저장소, 대용량 연속 쓰기만 몰리는 수집 저장소
• 호스트 직결이 나은 경우: 단일 서비스, 최소 계층, 빠른 장애 복구보다 구조 단순화가 더 중요한 환경
• ext4가 나은 경우: 파일시스템 기능보다 관리 익숙함과 예측 가능성이 우선인 경우

짧게 말하면 이렇습니다. 데이터를 시점 단위로 되돌릴 일이 잦으면 Btrfs NAS VM이 잘 맞고, 파일을 그냥 안정적으로 쌓아두기만 하면 ext4나 호스트 직결이 더 낫습니다.

검증 결과와 운영하면서 느낀 점

제가 이 구조를 계속 쓰게 된 결정적인 이유는 두 번의 복구 경험 때문이었습니다. 한 번은 사용자가 디렉터리를 통째로 날렸을 때였고, 다른 한 번은 백업 작업이 덮어쓰기로 꼬였을 때였습니다. 두 경우 모두 VM 전체를 되돌릴 필요 없이 해당 서브볼륨의 스냅샷만 복원해서 문제를 끊을 수 있었습니다. 이 차이가 꽤 큽니다. VM 스냅샷만 있었다면 애플리케이션 상태까지 같이 과거로 돌아가야 했을 가능성이 높습니다.

반면 불편한 지점도 분명했습니다. Btrfs는 “공간이 남았는지”보다 “공간이 어떻게 배치됐는지”를 봐야 하고, Proxmox 위에 올리면 디스크 계층을 하나 더 이해해야 합니다. 그래서 이 구성이 좋은 이유는 쉽기 때문이 아니라, 운영 목적이 분명할 때 얻는 이익이 번거로움을 넘어설 때가 많기 때문입니다.

이런 상태면 안정적으로 굴러가는 중입니다

• btrfs scrub status에 치명적 오류가 없습니다.
• btrfs device stats 카운터가 시간 경과에 따라 늘지 않습니다.
• 스냅샷 생성과 삭제 시간이 갑자기 길어지지 않습니다.
• SMB 접근 시 재연결, 멈춤, 잠금 충돌이 반복되지 않습니다.
• btrfs filesystem usage에서 메타데이터 사용률이 비정상적으로 치솟지 않습니다.

자주 묻는 질문과 선택 가이드

Q1. Proxmox Btrfs를 홈랩 NAS에 바로 추천하냐고요?

조건부로 추천드립니다. 역할 분리와 스냅샷 기반 복구가 목적이면 만족도가 꽤 높습니다. 대신 “그냥 간단한 공유 폴더 하나”가 목표라면 ext4 기반 NAS가 더 편합니다. 기능이 많다고 항상 좋은 선택은 아니더라고요.

Q2. Proxmox 스냅샷만 쓰면 안 되나요?

가능은 하지만, 데이터 복구 단위가 너무 큽니다. VM 전체를 되돌리는 건 빠르지만, 특정 공유 폴더 한 시점만 복원하기에는 거칠게 느껴질 때가 많습니다. 저는 시스템 변경 보호는 Proxmox 스냅샷, 데이터 사고 복구는 Btrfs 스냅샷으로 나눠 쓰는 쪽이 훨씬 깔끔했습니다.

Q3. 홈랩 NAS에서 꼭 기억할 한 줄은?

스냅샷은 백업이 아닙니다. 같은 파일시스템 안에 있으면 하부 디스크 문제가 생길 때 같이 잃을 수 있습니다. 운영 복구와 재해 복구는 꼭 분리해서 보셔야 합니다.

마무리: 제 추천은 꽤 분명합니다

Btrfs Proxmox NAS 조합은 “가상화 환경 안에서도 데이터 복구 단위를 세밀하게 관리하고 싶다”는 분에게 잘 맞습니다. 제가 직접 굴려본 기준으로는, 홈랩에서 자주 생기는 삭제 사고, 잘못된 덮어쓰기, 테스트 후 롤백 같은 상황에 특히 강했습니다. 대신 이 구조를 고르셨다면 메타데이터 usage 확인, 정기 scrub, device stats 추적은 선택이 아니라 운영 기본값으로 가져가야 합니다.

• 스냅샷 복구가 우선이다: Btrfs 기반 NAS VM이 맞습니다.
• 구성이 단순해야 한다: ext4 기반 단순 NAS부터 시작하는 편이 낫습니다.
• 디스크 장애 분석까지 직접 보고 싶다: 가상 디스크보다 패스스루 또는 장치 식별이 쉬운 구조가 유리합니다.
• DB, VM 이미지, 랜덤 덮어쓰기가 많다: 같은 Btrfs NAS 안에 넣지 말고 별도 볼륨이나 다른 저장소로 분리하세요.

제 판단을 한 문장으로 압축하면 이렇습니다. 복구 관점의 NAS를 만들 거라면 이 조합은 충분히 설득력이 있고, 단순 저장소가 목표라면 굳이 복잡도를 들일 이유는 많지 않습니다. 다음 단계로 넘어가신다면, 이 구조 위에 Restic 같은 외부 백업 경로를 붙여서 스냅샷과 재해 복구를 분리하는 쪽까지 함께 가져가시는 걸 권합니다. 관련 내부 글로는 Proxmox 백업 정책, Samba 권한 설계, Restic 오프사이트 백업 가이드를 이어서 묶어두면 SEO와 체류시간 측면에서도 도움이 됩니다.

어떤 환경에서 Btrfs NAS 가상화가 맞는지 빠르게 판단할 수 있는 요약 이미지입니다.