파일을 지웠는데 볼륨 사용량이 그대로일 때, 범인은 대개 ONTAP 스냅샷 용량입니다. 400MB짜리 파일을 지웠고 ls 에도 없는데, df 는 여전히 404MB를 쓰고 있다고 나옵니다. 볼륨을 늘려야 하나 싶어지는 순간인데, 대부분 스냅샷이 그 블록을 잡고 있어서입니다.
이 글은 그 상황을 일부러 만들어서 숫자로 확인한 기록입니다. 스냅샷이 언제 공간을 먹기 시작하는지, 왜 5% 예약이 790%가 되는지, 복원 방법 세 가지가 공간을 얼마나 다르게 쓰는지까지 실측했습니다.
이 글의 실습 환경
이 글은 ONTAP Simulator 9.17.1 기반 가상 랩에서 직접 명령을 실행하고 그 출력을 근거로 작성했습니다. 실제 장비(FAS/AFF)와는 지원 기능·성능·하드웨어 동작에서 차이가 있으며, ONTAP 버전에 따라 명령과 출력이 달라집니다.
| 구성 | 값 |
|---|---|
| 스토리지 | ONTAP Simulator 9.17.1, 2노드 클러스터 |
| 볼륨 | nfs_vol1 1GB, snapshot reserve 5%, 정책 default |
| 클라이언트 | Ubuntu Server 24.04, NFSv3로 /mnt/ontap-nfs 에 마운트 |
1. 상황 재현 — 지웠는데 그대로다
빈 볼륨에 400MB를 쓰고, 스냅샷을 찍고, 파일을 지웠습니다.
# 1) 400MB 쓰기
$ sudo dd if=/dev/urandom of=/mnt/ontap-nfs/bigfile.dat bs=1M count=400
$ df -h /mnt/ontap-nfs
Filesystem Size Used Avail Use% Mounted on
192.168.126.20:/nfs_vol1 973M 404M 570M 42% /mnt/ontap-nfs
# 2) 스냅샷
cluster1::> snapshot create -vserver NFS_SVM -volume nfs_vol1 -snapshot before_delete
# 3) 파일 삭제
$ sudo rm -f /mnt/ontap-nfs/bigfile.dat
$ ls /mnt/ontap-nfs/
write-test.txt
$ df -h /mnt/ontap-nfs
Filesystem Size Used Avail Use% Mounted on
192.168.126.20:/nfs_vol1 973M 404M 569M 42% /mnt/ontap-nfs파일은 없는데
Used는 404M 그대로입니다. 1MB도 안 줄었습니다. 이 상태에서 “NFS 캐시겠지” 하고umount/mount를 반복해도 숫자는 안 바뀝니다. 클라이언트 문제가 아니기 때문입니다.
2. ⭐ ONTAP 스냅샷 용량은 만들 때 0B, 지울 때 커진다
스냅샷을 만든 직후에 크기를 보면 이렇습니다.
cluster1::> snapshot show -vserver NFS_SVM -volume nfs_vol1 -snapshot before_delete -fields create-time,size
vserver volume snapshot create-time size
------- -------- ------------- ------------------------ ----
NFS_SVM nfs_vol1 before_delete Fri Aug 28 06:58:49 2026 0B400MB짜리 파일이 들어 있는 볼륨의 스냅샷인데 0B입니다. 스냅샷은 데이터를 복사하지 않습니다. “이 시점의 블록들을 해제하지 마라”고 표시만 해두고, 액티브 파일시스템과 같은 블록을 함께 가리킵니다.
그런데 파일을 지우고 나면 이렇게 바뀝니다.
cluster1::> snapshot show -vserver NFS_SVM -volume nfs_vol1
---Blocks---
Vserver Volume Snapshot Size Total% Used%
-------- -------- ---------------------------- -------- ------ -----
NFS_SVM nfs_vol1
hourly.2026-08-28_0605 204KB 0% 1%
before_delete 371.9MB 36% 92%0B였던 스냅샷이 371.9MB가 됐습니다. 액티브 파일시스템이 그 블록에서 손을 뗐으니, 이제 그 블록을 붙잡고 있는 건 스냅샷 하나뿐입니다. 스냅샷 크기는 “이 스냅샷만 가지고 있는 블록의 양” 입니다.
그래서 스냅샷 크기는 만든 직후가 아니라 시간이 지나면서 커집니다. 원본이 바뀌거나 지워질수록 커집니다. “스냅샷 찍어도 용량 안 먹네” 하고 정책을 늘려놨다가 나중에 볼륨이 차는 일이 여기서 생깁니다.
3. ⭐ 5% 예약인데 790%를 쓰고 있다
볼륨에는 스냅샷용으로 따로 떼어둔 공간(snapshot reserve)이 있습니다. 기본 5%입니다. 1GB 볼륨이면 약 51MB죠. 그런데 스냅샷이 371.9MB를 쓰고 있으면 어떻게 될까요.
cluster1::> volume show -vserver NFS_SVM -volume nfs_vol1 -instance
Space Reserved for Snapshot Copies: 5%
Snapshot Reserve Used: 790%
Available Snapshot Reserve Size: 0B
Volume Size Used by Snapshot Copies: 404.3MB
Snapshot Reserve Used: 790%— 예약 공간을 8배 가까이 초과했습니다. 넘친 만큼은 액티브 파일시스템이 쓸 공간에서 빠집니다. 사용자가 쓸 수 있는 자리를 스냅샷이 먹고 들어온 겁니다.
여기서 오해하기 쉬운 게 있습니다. reserve는 상한선이 아니라 최소 보장치입니다. 5%로 잡아두면 스냅샷이 5%까지만 쓴다는 뜻이 아니라, 최소 5%는 확보해준다는 뜻입니다. 넘치면 그냥 넘칩니다.
4. 복원 방법 세 가지 — 공간을 전혀 다르게 쓴다
지운 파일을 되살리는 방법은 세 가지입니다. 결과는 같아 보이지만 공간과 부작용이 다릅니다. 같은 200MB 파일로 각각 측정했습니다.
① .snapshot 에서 직접 복사
NFS 클라이언트에서 마운트 지점 아래 .snapshot 디렉터리로 들어가면 됩니다.
$ ls -a /mnt/ontap-nfs
. .. .snapshot write-test.txt
$ ls /mnt/ontap-nfs/.snapshot/
before_delete daily.2026-08-27_0910 hourly.2026-08-28_0105 ...
$ ls -lh /mnt/ontap-nfs/.snapshot/before_delete/
-rw-r--r-- 1 root root 400M Aug 27 21:58 bigfile.dat스냅샷 안은 읽기 전용입니다. 여기서 지우거나 고칠 수는 없고, 꺼내오는 것만 됩니다.
$ sudo touch /mnt/ontap-nfs/.snapshot/before_delete/x
touch: cannot touch '...': Read-only file system그런데 복사해 오면 공간을 그만큼 더 씁니다. 당연한 얘기 같지만, 이미 볼륨이 꽉 차서 문제가 된 상황에서는 이 방법이 상황을 더 악화시킵니다.
# 삭제 후
vserver volume used percent-used size-used-by-snapshots
------- -------- ------- ------------ ----------------------
NFS_SVM nfs_vol1 355.1MB 36% 370.5MB
$ sudo cp /mnt/ontap-nfs/.snapshot/cp_test/doc.dat /mnt/ontap-nfs/doc.dat
# cp 복원 후
NFS_SVM nfs_vol1 555.2MB 57% 400.8MB
# ^^^^^^^ +200.1MB — 파일 크기만큼 정확히 늘었다② 단일 파일 SnapRestore — 파일 하나만, 공간 없이
ONTAP에는 파일 하나만 되돌리는 명령이 따로 있습니다. 이걸 모르고 cp 로만 해결하는 경우가 많습니다.
cluster1::> volume snapshot restore-file -vserver NFS_SVM -volume nfs_vol1 -snapshot sfsr_test -path /doc.dat# 삭제 후
NFS_SVM nfs_vol1 211.6MB 22% 182.0MB
# restore-file 후 (안정화된 값)
NFS_SVM nfs_vol1 201.5MB 20% 12.85MB
# ^^^^^^^ 늘지 않았다. 블록을 공유하기 때문200MB 파일을 되살렸는데 볼륨 사용량이 늘지 않았습니다. 데이터를 복사하는 게 아니라 블록 포인터를 다시 연결하기 때문입니다. 스냅샷이 잡고 있던 블록이 액티브로 돌아오면서 size-used-by-snapshots 가 182MB → 12.85MB로 오히려 줄었습니다.
그리고 중요한 것 — 스냅샷은 그대로 남습니다.
③ 볼륨 SnapRestore — 빠르지만 되돌릴 수 없다
cluster1::> volume snapshot restore -vserver NFS_SVM -volume nfs_vol1 -snapshot before_delete볼륨 전체가 그 시점으로 돌아갑니다. 400MB 파일이 되살아났고, 그 뒤에 만들었던 restored.dat 는 사라졌습니다. 사용량도 755.8MB → 403.7MB 로 줄었습니다. 데이터를 옮기지 않으므로 사실상 즉시 끝납니다.
대신 대가가 있습니다.
# 복원 전 스냅샷 목록
... hourly.2026-08-28_0605
before_delete <-- 여기로 복원
after_copy <-- 이 시점보다 나중
# 복원 후
... hourly.2026-08-28_0605
before_delete
# after_copy 가 사라졌다복원 지점보다 나중에 만들어진 스냅샷은 전부 삭제됩니다. NetApp 문서도 “선택한 스냅샷보다 새로운 볼륨의 모든 데이터가 삭제된다”고 명시합니다. [문서확인] 되돌릴 방법이 없으므로, 볼륨 SnapRestore 전에는 지금 시점의 스냅샷을 하나 더 찍어두는 습관이 안전합니다.
SnapMirror를 쓰고 있다면 더 조심해야 합니다. 문서는 SnapMirror가 기준으로 삼는 스냅샷보다 이전으로 되돌리면 이후 전송이 실패하며, 복원 직후 모든 미러를 수동으로 다시 복제하라고 안내합니다. [문서확인]
세 방법 비교
| 방법 | 범위 | 추가 공간 | 기존 스냅샷 | 속도 |
|---|---|---|---|---|
.snapshot 에서 cp | 파일 1개 | 파일 크기만큼 (+200MB) | 유지 | 복사 시간만큼 |
snapshot restore-file | 파일 1개 | 거의 없음 | 유지 | 즉시 |
snapshot restore | 볼륨 전체 | 없음 (줄어듦) | 이후 것 전부 삭제 | 즉시 |
파일 몇 개만 살리면 되는 상황에서 볼륨 전체를 되돌리는 것은 과합니다. 반대로 랜섬웨어처럼 볼륨 전체가 오염됐다면 파일 단위 복원은 끝이 없습니다. 범위를 먼저 정하고 도구를 고르는 순서가 맞습니다.
5. ⭐ 공간 반환은 즉시가 아니다
파일도 지우고 스냅샷도 지웠는데 숫자가 안 바뀌어서 한참 들여다본 구간이 있습니다.
# 파일 삭제 + 스냅샷 삭제 직후
vserver volume available used percent-used size-used-by-snapshots
------- -------- --------- ------- ------------ ----------------------
NFS_SVM nfs_vol1 568.2MB 404.6MB 41% 2.68MB
# ^^^^^^^ 스냅샷은 2.68MB뿐인데 볼륨은 404MB?
# 클라이언트에서 실제 내용을 보면 비어 있다
$ sudo du -sh /mnt/ontap-nfs/
40K /mnt/ontap-nfs/스냅샷도 아니고 파일도 아닌데 404MB를 쓰고 있다고 나옵니다. 90초쯤 기다리자 반영됐습니다.
# 약 90초 후
NFS_SVM nfs_vol1 963.2MB 9.64MB 0% 2.72MB
$ df -h /mnt/ontap-nfs
192.168.126.20:/nfs_vol1 973M 9.7M 964M 1% /mnt/ontap-nfsONTAP은 블록 해제를 백그라운드로 처리합니다. 그래서 “지웠는데 안 줄어든다”에는 원인이 두 가지입니다 — (1) 스냅샷이 잡고 있거나, (2) 아직 반영이 안 됐거나. 스냅샷을 확인했는데 비어 있다면, 1~2분 기다렸다가 다시 보세요.
6. 실무에서 진짜 흔한 범인 — 자동 스냅샷
테스트를 다 끝내고 내가 만든 스냅샷을 전부 지운 뒤에도 볼륨이 15%를 쓰고 있었습니다. 범인은 이거였습니다.
cluster1::> snapshot show -vserver NFS_SVM -volume nfs_vol1
---Blocks---
Vserver Volume Snapshot Size Total% Used%
-------- -------- ---------------------------- -------- ------ -----
NFS_SVM nfs_vol1
daily.2026-08-27_0910 180KB 0% 15%
hourly.2026-08-28_0605 2.88MB 0% 75%
hourly.2026-08-28_0705 201.2MB 20% 100%hourly.2026-08-28_0705 가 201.2MB를 붙잡고 있습니다. 내가 만든 스냅샷이 아니라 정책이 자동으로 찍은 것입니다. 테스트 파일을 지우는 그 시간대에 hourly가 돌면서 그 상태를 그대로 담아버린 거죠.
cluster1::> snapshot policy show -policy default
Policy Name Schedules Enabled Comment
------------------------ --------- ------- -------------------------------
default 3 true Default policy with hourly, daily & weekly schedules.
Schedule Count Prefix SnapMirror Label
-------------- ----- ------------- ----------------
hourly 6 hourly -
daily 2 daily daily
weekly 2 weekly weekly기본 정책은 hourly 6개, daily 2개, weekly 2개를 보관합니다. hourly는 6개니까 6시간이 지나면 자동으로 밀려나면서 공간이 풀립니다. 실제로 이 실습 중에 hourly.2026-08-28_0105 가 목록에서 사라졌습니다.
그러니까 당장 공간이 급하지 않으면 그냥 기다려도 됩니다. 급하다면 해당 스냅샷을 직접 지우면 되고요. 어느 스냅샷이 얼마를 잡고 있는지는 위 snapshot show 한 줄로 바로 보입니다.
7. 반대 함정 — 정책이 none 이면 스냅샷이 아예 없다
공간 얘기만 하다 보면 잊기 쉬운데, 반대 방향 사고도 있습니다. 같은 랩의 iSCSI 볼륨을 보면 이렇습니다.
cluster1::> volume show -fields volume,snapshot-policy
vserver volume snapshot-policy
--------- ------------ ---------------
NFS_SVM nfs_vol1 default
CIFS_SVM window_vol1 default
ISCSI_SVM iscsi_vol1 none <--
cluster1::> snapshot show -vserver ISCSI_SVM -volume iscsi_vol1
There are no entries matching your query.이 볼륨은 만들 때 -snapshot-policy none 을 줬습니다. 스냅샷이 단 하나도 없습니다. 공간은 깔끔하지만 되돌릴 수 있는 시점이 없습니다.
테스트용으로 만든 볼륨에 정책을 꺼두고, 그게 그대로 운영으로 넘어가는 일이 생각보다 흔합니다. 볼륨을 인계받으면 snapshot-policy 부터 확인하는 편이 좋습니다.
정리 — ONTAP 스냅샷 용량 점검 순서
| 순서 | 확인 | 명령 |
|---|---|---|
| 1 | 어떤 스냅샷이 얼마를 잡고 있나 | snapshot show -vserver X -volume Y |
| 2 | 예약을 넘겼나 (넘치면 액티브 잠식) | volume show -instance → Snapshot Reserve Used |
| 3 | 스냅샷이 비어 있는데도 안 줄면 | 1~2분 기다렸다 다시 본다 |
| 4 | 자동 스냅샷이면 언제 밀려나나 | snapshot policy show -policy default |
| 5 | 파일을 되살려야 하면 | snapshot restore-file (cp 아님) |
핵심은 하나입니다. 스냅샷은 복사본이 아니라 블록을 붙잡아 두는 표시라는 것. 이 하나만 잡고 있으면 위 현상들이 전부 같은 얘기로 보입니다 — 만들 때 0B인 것도, 지울 때 커지는 것도, 5%가 790%가 되는 것도, restore-file 이 공간을 안 먹는 것도 전부 같은 이유입니다.
같은 볼륨을 다루는 다른 글도 함께 보시면 도움이 됩니다 — NFS 마운트가 access denied로 거부될 때는 export policy가 원인이었고, iSCSI LUN을 Windows에 연결하는 글에서는 볼륨 사용량과 LUN 사용량이 다른 이유를 다뤘습니다. 이 글의 스냅샷 얘기와 묶어서 보면 ONTAP의 “사용량”이 왜 여러 개인지가 정리됩니다.
참고 문서 — volume snapshot restore (ONTAP CLI) · Restore a single file from an ONTAP snapshot · Restore the contents of a volume from an ONTAP snapshot
