시놀로지 NAS 스냅샷 디렉토리 용량 누수와 Btrfs 최적화

시놀로지 NAS를 운영하다 보면 예기치 않게 디스크 용량이 부족해지는 경험을 할 수 있습니다. 특히 Btrfs 파일 시스템을 사용하는 볼륨에서 이러한 현상이 두드러지게 나타나는데, 이는 대부분 스냅샷 관리의 비효율성 또는 숨겨진 스냅샷 디렉토리로 인한 용량 누수 때문입니다. 2026년 현재, 시놀로지 DSM 7.x 환경에서 Btrfs의 고급 스냅샷 기능은 데이터 보호에 필수적이지만, 제대로 관리하지 않으면 심각한 디스크 공간 문제를 야기할 수 있습니다. 이 글에서는 스냅샷 디렉토리로 인한 용량 누수 문제를 진단하고, 효과적인 해결 방안 및 Btrfs 최적화 기법을 심층적으로 다룹니다.

스냅샷 용량 누수 진단 및 숨겨진 디렉토리 분석

시놀로지 NAS에서 Btrfs 볼륨의 용량 부족은 종종 예상치 못한 곳에서 발생합니다. df -h 명령으로 확인했을 때, 특정 공유 폴더의 실제 사용량보다 볼륨 전체 사용량이 훨씬 높게 나오는 경우가 대표적입니다. 이는 Btrfs의 스냅샷 기능이 백그라운드에서 동작하며 생성하는 숨겨진 스냅샷 디렉토리, 즉 @snapshot 폴더에 의해 발생합니다. 이 폴더는 일반적인 파일 탐색기로는 접근할 수 없으며, SSH를 통해 NAS에 접속해야만 그 존재를 확인할 수 있습니다.

실제로 SSH로 접속하여 /volume1과 같은 볼륨 경로에서 du -sh * 명령을 실행하면, @snapshot 디렉토리가 상당한 용량을 차지하고 있음을 발견할 수 있습니다.

:::step[단계별 해결 절차]

1. SSH 활성화 및 접속: DSM 제어판 > 터미널 및 SNMP > SSH 서비스 활성화. PuTTY 또는 터미널을 이용해 ssh admin@your_nas_ip로 접속합니다.
2. 루트 권한 획득: sudo -i 명령으로 루트 권한을 획득합니다. (admin 비밀번호 입력)
3. 볼륨 경로 이동: cd /volume1 (볼륨 이름에 따라 변경될 수 있음)
4. 숨겨진 디렉토리 용량 확인: du -sh .snapshots 명령으로 스냅샷 디렉토리의 현재 용량을 확인합니다.

# SSH 접속 후 루트 권한 획득
ssh admin@your_nas_ip
sudo -i

# 볼륨 경로로 이동 (예: volume1)
cd /volume1

# .snapshots 디렉토리 용량 확인
du -sh .snapshots

# .snapshots 디렉토리가 1.5TB를 차지하고 있음을 확인
1.5T    .snapshots

이 결과는 du 명령이 Btrfs의 서브볼륨 구조를 제대로 해석하지 못해 잘못된 용량을 표시하는 것이 아니라, 실제로 스냅샷이 차지하고 있는 데이터 블록의 합산 용량을 나타냅니다.

Btrfs 스냅샷 정책 및 보존 설정 최적화

용량 누수의 가장 큰 원인은 부적절한 스냅샷 정책 및 보존 설정입니다. 시놀로지 NAS는 기본적으로 'Snapshot Replication' 패키지를 통해 스냅샷을 관리하며, 이 설정은 데이터의 중요도와 복구 빈도에 따라 신중하게 구성해야 합니다. 너무 많은 스냅샷을 너무 오래 보존하면 필연적으로 디스크 공간이 고갈됩니다.

시놀로지 DSM의 'Snapshot Replication' 애플리케이션에서 각 공유 폴더별로 스냅샷 보존 정책을 설정할 수 있습니다.

일반적인 권장 사항은 다음과 같습니다:

• 빈번한 변경이 있는 폴더: 시간별 스냅샷을 며칠(예: 7일) 보존하고, 일별 스냅샷을 몇 주(예: 4주), 주별 스냅샷을 몇 달(예: 3개월) 보존하는 혼합 정책을 사용합니다.
• 아카이브 또는 정적 데이터: 일별 스냅샷을 며칠만 보존하거나, 아예 스냅샷을 비활성화하는 것을 고려합니다.

DSM에서 스냅샷 정책 수정:

1. Snapshot Replication 실행: DSM 메인 메뉴에서 'Snapshot Replication'을 엽니다.
2. 공유 폴더 선택: 좌측 패널에서 '스냅샷' > '공유 폴더'를 선택하고, 정책을 변경할 공유 폴더를 선택합니다.
3. 설정 편집: '설정' 버튼을 클릭하여 스냅샷 스케줄 및 보존 정책을 편집합니다.
4. 보존 정책 조정: '보존 정책' 탭에서 '고급 보존 정책'을 활성화하고, '최신 스냅샷 보존', '매일 스냅샷 보존', '매주 스냅샷 보존' 등의 옵션을 합리적인 수준으로 조정합니다. 예를 들어, 최신 7개 스냅샷, 매일 스냅샷 4주, 매주 스냅샷 3개월 등으로 설정할 수 있습니다.

Btrfs 파일 시스템 메타데이터 오버헤드 최적화

Btrfs는 고급 기능만큼이나 메타데이터 관리의 복잡성을 가집니다. 특히 많은 수의 스냅샷, 작은 파일들, 또는 빈번한 파일 변경은 Btrfs 메타데이터의 오버헤드를 증가시켜 실제 데이터 외에 메타데이터가 차지하는 공간이 비정상적으로 커질 수 있습니다. 이는 btrfs filesystem df 명령으로 확인할 수 있습니다.

# Btrfs 파일 시스템 사용량 상세 정보 확인
btrfs filesystem df /volume1

# System Data가 꽤 높은 비율을 차지하고 있음을 확인
Data, single:     1.50TiB
System, DUP:      1.00GiB # 메타데이터
Metadata, DUP:    50.00GiB # 메타데이터
GlobalReserve, single: 512.00MiB

여기서 System과 Metadata가 메타데이터 관련 공간입니다. 이 공간이 비정상적으로 높다면, Btrfs 파일 시스템의 balance 작업을 통해 메타데이터를 최적화할 수 있습니다. balance는 파일 시스템의 데이터와 메타데이터를 재분배하여 공간 효율성을 높이는 작업입니다.

balance 작업은 특정 메타데이터 청크(chunk)만 대상으로 지정하여 효율성을 높일 수 있습니다.

# Btrfs 메타데이터 밸런싱 시작 (DUP 청크만 대상으로)
# -dusage=50: 데이터 청크 사용률이 50% 미만인 청크만 대상으로
# -musage=50: 메타데이터 청크 사용률이 50% 미만인 청크만 대상으로
# -susage=50: 시스템 청크 사용률이 50% 미만인 청크만 대상으로
# 이 예시에서는 메타데이터(m)의 DUP 청크만 대상으로
btrfs balance start -m -dusage=50 /volume1

Done, had to relocate 10 chunks

balance 작업은 메타데이터의 단편화를 줄이고, 불필요하게 할당된 공간을 회수하는 데 도움을 줍니다. 작업이 완료된 후 다시 btrfs filesystem df를 실행하여 메타데이터 사용량이 줄었는지 확인합니다.

오래된 스냅샷 수동 삭제 및 강제 제거

스냅샷 정책을 조정한 후에도 이미 생성된 오래된 스냅샷들이 여전히 디스크 공간을 차지하고 있을 수 있습니다. 이 경우, DSM의 'Snapshot Replication' 애플리케이션에서 수동으로 스냅샷을 삭제하여 즉시 공간을 확보할 수 있습니다.

1. Snapshot Replication 실행: DSM 메인 메뉴에서 'Snapshot Replication'을 엽니다.
2. 공유 폴더 선택: 좌측 패널에서 '스냅샷' > '공유 폴더'를 선택하고, 스냅샷을 삭제할 공유 폴더를 선택합니다.
3. 스냅샷 선택 및 삭제: 삭제할 스냅샷을 하나 이상 선택한 후 '제거' 버튼을 클릭합니다. 여러 스냅샷을 한 번에 선택하여 삭제할 수도 있습니다.

만약 DSM GUI에서 스냅샷 삭제가 제대로 되지 않거나, 특정 스냅샷이 삭제되지 않는 문제가 발생할 경우, SSH를 통해 강제로 스냅샷을 제거할 수 있습니다. 이 방법은 매우 강력하므로 신중하게 사용해야 합니다.

# SSH 접속 후 루트 권한 획득
ssh admin@your_nas_ip
sudo -i

# 스냅샷 목록 확인 (Btrfs 서브볼륨 목록)
btrfs subvolume list /volume1

ID 257 gen 12345 top level 5 path @docker
ID 258 gen 12346 top level 5 path @appstore
ID 259 gen 12347 top level 257 path @snapshot/MyShare_2026-01-01_00-00-00
ID 260 gen 12348 top level 257 path @snapshot/MyShare_2026-01-02_00-00-00

위 목록에서 path @snapshot/MyShare_YYYY-MM-DD_HH-MM-SS 형태로 된 것이 스냅샷입니다. 삭제하고자 하는 스냅샷의 path를 확인합니다.

# 특정 스냅샷 강제 삭제 (예시: MyShare_2026-01-01_00-00-00 스냅샷)
btrfs subvolume delete /volume1/@snapshot/MyShare_2026-01-01_00-00-00

Btrfs Scrub 및 Defragmentation 활용

Btrfs 파일 시스템은 데이터 무결성을 보장하기 위해 scrub 기능을 제공합니다. scrub은 파일 시스템 전체를 스캔하여 데이터 및 메타데이터의 오류를 검사하고, RAID 구성의 경우 손상된 블록을 복구하는 작업을 수행합니다. 주기적인 scrub은 파일 시스템의 건강을 유지하고 잠재적인 데이터 손실을 방지하는 데 필수적입니다.

또한, Btrfs는 CoW(Copy-on-Write) 특성상 파일이 자주 변경되면 단편화가 발생할 수 있습니다. 단편화는 파일 읽기/쓰기 성능에 영향을 미치며, 특히 가상 머신 이미지 파일이나 대용량 데이터베이스 파일처럼 특정 파일이 자주 변경되는 경우 더욱 심해질 수 있습니다. defragmentation은 이러한 파일들의 단편화를 줄여 성능을 향상시킬 수 있습니다.

# Btrfs 스크럽 시작
btrfs scrub start /volume1

# 스크럽 진행 상황 확인
btrfs scrub status /volume1

스크럽은 시스템 리소스를 사용하므로, NAS 사용량이 적은 시간에 예약 작업을 통해 주기적으로 실행하는 것이 좋습니다. DSM의 '저장소 관리자' > '저장소 풀' > '데이터 스크러빙' 설정에서 예약할 수 있습니다.

파일 단편화가 심한 특정 파일을 대상으로 defragmentation을 실행할 수 있습니다.

# 특정 파일 또는 디렉토리 조각 모음
btrfs filesystem defragment -r /volume1/MyShare/LargeFile.mkv
btrfs filesystem defragment -r /volume1/MyShare/FrequentChangedDir/

-r 옵션은 재귀적으로 하위 디렉토리까지 조각 모음을 수행합니다. defragmentation은 모든 파일에 대해 무작정 실행하기보다는, 성능 저하가 의심되는 특정 대용량 파일이나 자주 변경되는 디렉토리에 대해 선별적으로 적용하는 것이 효율적입니다.

Docker 컨테이너 볼륨 관리 및 용량 확보

시놀로지 NAS에서 Docker 컨테이너를 운영하는 경우, 컨테이너의 로그, 이미지, 볼륨 데이터가 Btrfs 볼륨의 용량을 빠르게 잠식할 수 있습니다. 특히 사용하지 않는 Docker 이미지나 컨테이너가 축적되면 상당한 공간 낭비로 이어집니다.

Docker 시스템 정리 명령어:

# 사용하지 않는 모든 Docker 객체 정리 (중지된 컨테이너, 사용하지 않는 이미지, 네트워크, 빌드 캐시)
docker system prune -a

# 특정 볼륨만 정리 (사용하지 않는 볼륨만)
docker volume prune

# 특정 이미지만 정리 (사용하지 않는 이미지만)
docker image prune

# docker system prune -a 실행 결과 예시
WARNING! This will remove:
  - all stopped containers
  - all networks not used by at least one container
  - all images without at least one container associated to them
  - all build cache

Are you sure you want to continue? [y/N] y
Total reclaimed space: 5.2GB

docker system prune -a는 매우 강력한 명령이므로, 실행 전 현재 실행 중인 서비스에 영향을 주지 않는지 반드시 확인해야 합니다. 특히 프로덕션 환경에서는 신중하게 접근해야 합니다.

또한, 컨테이너 로그 파일이 과도하게 커지는 것을 방지하기 위해 docker-compose.yaml 파일이나 docker run 명령에 로그 로테이션 설정을 적용하는 것이 좋습니다.

# docker-compose.yaml 예시: 로그 로테이션 설정
version: '3.8'
services:
  my-service:
    image: my-image:latest
    container_name: my-service
    logging:
      driver: "json-file"
      options:
        max-size: "10m" # 각 로그 파일 최대 크기 10MB
        max-file: "3"  # 로그 파일 최대 3개 보존

이 설정을 적용하면 컨테이너 로그가 10MB를 초과하면 새로운 로그 파일이 생성되고, 최대 3개의 로그 파일만 보존되어 디스크 공간 낭비를 줄일 수 있습니다.

FAQ: 시놀로지 NAS Btrfs 용량 관리

Q. df -h와 DSM 저장소 관리자의 용량이 다르게 표시됩니다. 무엇이 정확한가요?

A. df -h는 리눅스 커널의 관점에서 파일 시스템 전체의 사용량을 보여주지만, Btrfs의 스냅샷은 CoW(Copy-on-Write) 특성상 데이터 블록을 공유하므로 실제 데이터가 삭제되어도 스냅샷이 해당 블록을 참조하고 있으면 공간이 회수되지 않습니다. DSM 저장소 관리자는 스냅샷이 차지하는 공간까지 포함하여 실제 볼륨 사용량을 보여주므로, DSM의 수치가 더 정확한 '사용 가능한 공간'을 반영합니다. btrfs filesystem df는 데이터, 메타데이터, 시스템 청크별 상세 사용량을 보여주어 더 깊은 이해를 돕습니다.

Q. 스냅샷을 모두 삭제했는데도 용량이 즉시 회수되지 않습니다. 왜 그런가요?

A. Btrfs는 스냅샷 삭제 후에도 내부적으로 가비지 컬렉션(GC) 및 블록 재할당 과정이 필요할 수 있습니다. 특히 대량의 스냅샷을 한 번에 삭제했거나, 파일 시스템에 많은 변경 사항이 있었던 경우, 공간 회수에는 시간이 걸릴 수 있습니다. 이 경우 btrfs balance 작업을 실행하여 파일 시스템을 최적화하면 공간 회수를 가속화할 수 있습니다. 또한, /volume1/.snapshots 디렉토리에 접근하여 숨겨진 스냅샷이 남아있는지 다시 한번 확인해보세요.

Q. Btrfs balance 작업 중 NAS가 멈춘 것 같습니다. 어떻게 해야 하나요?

A. balance 작업은 대용량 볼륨에서 매우 오랜 시간이 걸릴 수 있으며, 진행 상황을 실시간으로 확인하기 어렵습니다. btrfs balance status /volume1 명령을 통해 현재 진행 상황을 확인할 수 있습니다. 만약 정말로 멈춘 것 같다면, 강제로 작업을 중단(btrfs balance cancel /volume1)한 후, NAS를 재시작하고 다시 시도하는 것을 고려해야 합니다. 하지만 작업 중단 시 파일 시스템 일관성에 문제가 발생할 가능성도 있으므로 최후의 수단으로 사용해야 합니다.

Q. Docker 컨테이너를 삭제했는데도 용량이 줄지 않습니다.

A. Docker 컨테이너를 삭제해도 해당 컨테이너가 사용하던 볼륨(특히 docker volume create로 생성된 명명된 볼륨)은 자동으로 삭제되지 않습니다. docker volume ls 명령으로 볼륨 목록을 확인하고, 더 이상 사용하지 않는 볼륨은 docker volume rm <volume_name> 명령으로 수동으로 삭제해야 합니다. 또는 docker volume prune 명령으로 사용하지 않는 모든 볼륨을 한 번에 정리할 수 있습니다.

참고 자료

• Synology Knowledge Base: Btrfs 스냅샷 작동 방식
• Btrfs Wiki: Balance
• Docker Documentation: Clean up unused Docker objects