가이드

작성자 Matt Connor 2026-08-12 · 업데이트됨 2026-08-13

VPS 디스크 상태 모니터링 및 SMART 확인 방법

Q: VPS에서 smartctl이 작동하지 않는 이유는 무엇입니까?

디스크가 가상이기 때문입니다. virtio-blk를 사용하는 KVM 게스트에서 smartctl -a /dev/vda를 실행하면 /dev/vda: Unable to detect device type이 출력됩니다. 반가상화 디스크는 SMART 요청을 전달할 ATA 또는 SCSI 명령 채널을 가지고 있지 않기 때문입니다. 에뮬레이션된 디스크의 경우 모델명이 QEMU HARDDISK로 표시되는 장치에 도달하게 되며, 그 뒤에는 사용할 수 있는 SMART 데이터가 없습니다. 컨테이너 내부에서는 CAP_SYS_RAWIO 권한이 부족하여 smartctl 실행이 즉시 거부됩니다. 이는 설정 오류가 아니며, 어떤 -d 플래그를 사용해도 해결할 수 없습니다.

Q: VPS 디스크의 장애 여부를 어떻게 알 수 있습니까?

하드웨어 상태보다는 시스템의 반응을 관찰하십시오. sudo journalctl -k -p err -b에서 blk_update_request: I/O error 줄과 Remounting filesystem read-only 항목을 확인하십시오. 로그에서 이미 누락된 오류를 찾으려면 sudo dumpe2fs -h /dev/vda1 | grep -i 'error count'을 실행하십시오. 정상 상태일 때 기록해 둔 기준값과 비교하여 iostat -xdz 5에서 r_await을 추적하십시오. VPS에서 발생하는 I/O 오류는 대개 드라이브 자체의 수명 문제보다는 호스트 스토리지의 문제일 가능성이 높으므로, 타임스탬프와 섹터 정보를 포함하여 지원 티켓을 제출해야 합니다.

Q: VPS 디스크 상태에 대해 어떤 알림을 설정해야 합니까?

네 가지 알림으로 충분합니다. node_filesystem_readonly == 1 또는 쓰기 테스트 실패로 인한 읽기 전용 마운트 발생, 여유 공간 및 여유 inode가 0에 가까워지는 경우, 최근 간격 내에 발생한 모든 커널 I/O error 오류, 그리고 서버가 응답을 멈췄을 때 알림을 받을 수 있는 하트비트 체크입니다. SMART 데이터는 가상 디스크에서 누락되거나 하이퍼바이저의 에뮬레이션 값을 보여줄 뿐이므로 알림 설정에서 제외하십시오.

Q: 파일 시스템이 왜 읽기 전용으로 다시 마운트되었습니까?

errors=remount-ro 옵션으로 마운트된 ext4는 메타데이터 오류가 발생하면 의도적으로 이 작업을 수행합니다. 손상을 방지하기 위해 쓰기 작업을 중단하는 것입니다. 트리거는 다시 마운트된 줄 바로 위의 커널 로그에 있으며, 일반적으로 하위 장치에서 I/O 오류가 반환된 후 저널이 중단되었다는 EXT4-fs error 메시지가 기록됩니다. 파일 시스템을 점검하지 않고 읽기-쓰기 모드로 다시 마운트하는 것은 증상만 숨길 뿐 원인을 해결하지 못합니다. 로그를 확보한 뒤, 복구 모드에서 파일 시스템을 언마운트하고 e2fsck -fy /dev/vda1를 실행하여 점검하십시오.

대부분의 VPS는 가상화 환경으로 인해 SMART 데이터 확인이 불가능합니다. 게스트 OS에서 실제 디스크 상태를 모니터링하는 방법과 I/O 오류 및 파일 시스템 읽기 전용 전환을 사전에 감지하여 장애에 대응하는 구체적인 가이드를 제공합니다.

VPS에서 디스크 상태 모니터링으로 실제로 확인할 수 있는 것

VPS의 디스크 상태 모니터링은 대부분의 가이드가 언급하지 않는 사실에서 시작합니다. 바로 디스크가 사용자의 소유가 아니라는 점입니다. 게스트 운영체제는 가상 블록 장치를 볼 뿐입니다. 물리 드라이브와 그 안에 저장된 모든 카운터는 호스트의 소유입니다. smartctl /dev/vda가 실패하는 이유는 명령어를 잘못 입력했기 때문이 아닙니다. 장치 뒤편의 그 무엇도 해당 질문에 답할 수 없기 때문입니다.

SMART(Self-Monitoring, Analysis and Reporting Technology)는 드라이브 자체에 보관되는 카운터 테이블로, 재할당된 섹터, 보류 중인 섹터, 전원 켜짐 시간, 미디어 오류 등을 포함합니다. 이 테이블을 읽으려면 ATA 또는 NVMe(Non-Volatile Memory Express) 명령이 실제 하드웨어에 도달할 경로가 필요합니다. 반가상화(paravirtual) 디스크는 이러한 경로를 제공하지 않으므로, 게스트는 원격 측정 데이터가 제거된 저장 장치를 사용하게 됩니다.

테넌트는 하드웨어가 아닌 그 영향을 모니터링합니다. 게스트 내부에서 확인할 수 있는 신호는 네 가지입니다. 커널 로그의 I/O(Input/Output) 오류, 읽기 전용으로 다시 마운트되는 파일 시스템, 점진적으로 증가하는 지연 시간, 그리고 공간 부족 현상입니다. 이 네 가지 모두에 대해 알림을 설정할 수 있으며, 사용자가 불만을 제기하기 전에 미리 감지할 수 있습니다. 우선 이 항목들부터 설정하십시오. 책임의 소재를 구분하는 것은 마지막에 해도 충분합니다. 어디에 노력을 기울여야 할지가 달라지기 때문입니다.

서버가 무엇을 노출하는지 확인하기

어떤 상황에 해당하는지 가정하지 마십시오. 먼저 확인한 뒤, 해당하는 섹션을 읽으십시오.

sudo apt update && sudo apt install -y smartmontools nvme-cli
lsblk -o NAME,TYPE,SIZE,MODEL,TRAN
sudo smartctl -a /dev/vda

virtio-blk, 일반적인 KVM (kernel-based virtual machine) 디스크입니다. 장치는 /dev/vda이며, smartctl은 아무것도 전송하기 전에 중단됩니다:

/dev/vda: Unable to detect device type
Please specify device type with the -d option.

virtio-blk는 그 뒤에 ATA나 SCSI 명령 세트가 없는 반가상화 전송 방식이므로, SMART 요청을 전달할 채널이 없습니다. -d sat와 -d scsi도 같은 이유로 실패하는데, 이는 플래그가 아닌 전송 방식 자체가 문제이기 때문입니다.

에뮬레이션된 SATA 또는 SCSI 디스크입니다. 장치는 /dev/sda이며, smartctl이 장치를 식별할 수 있을 만큼 충분히 동작합니다. 모델 라인에는 QEMU HARDDISK이 표시됩니다. 이 문자열 자체가 답을 알려줍니다. 즉, 에뮬레이터가 생성한 장치를 읽고 있는 것이며, 사용 가능한 SMART 기능은 보고되지 않습니다.

NVMe 네임스페이스입니다. sudo nvme smart-log /dev/nvme0n1은 전체 로그를 반환하며, 여기서 많은 사람이 혼동을 겪습니다. 먼저 sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)'로 컨트롤러 식별 정보를 확인하십시오. 네트워크 스토리지 제품명이 포함된 모델 번호는 컨트롤러가 소프트웨어임을 의미하므로, percentage_used과 media_errors은 데이터가 저장된 실제 플래시가 아닌 에뮬레이션 상태를 설명하는 것입니다. 스토리지의 실제 상태를 알고 싶다면, 계획서의 설명을 신뢰하는 대신 Linux에서 NVMe 디스크 확인하기를 수행하십시오.

LXC (Linux containers) 또는 OpenVZ와 같은 컨테이너입니다. 귀하는 독자적인 블록 장치를 가지고 있지 않습니다. lsblk는 호스트의 장치를 보여주거나 아무것도 표시하지 않으며, 컨테이너가 CAP_SYS_RAWIO을 보유하고 있지 않기 때문에 smartctl은 거부됩니다:

Smartctl open device: /dev/sda failed: Permission denied

작동하는 경우에 대한 주의 사항이 하나 있습니다. VPS에서 smartctl이 전체 속성 테이블을 반환한다면, 조치를 취하기 전에 일련번호를 먼저 읽으십시오. 일부 호스트는 패스스루 장치 노드를 노출하며, 해당 카운터는 해당 머신의 모든 테넌트가 공유하는 하드웨어의 값입니다. 그곳에서 Reallocated_Sector_Ct가 증가한다면 이는 지원 티켓을 발행해야 할 상황입니다. 귀하의 데이터에 대한 상태 보고가 아닙니다.

신호 1: 커널 로그의 I/O 오류

이는 테넌트가 가질 수 있는 가장 가치 있는 신호이며, 별도의 에이전트가 필요하지 않습니다.

sudo journalctl -k -p err -b
sudo journalctl -k --since "7 days ago" | grep -iE 'i/o error|remount|ext4-fs error|buffer i/o'

가상 디스크에서 발생한 요청 실패는 다음과 같이 나타납니다.

blk_update_request: I/O error, dev vda, sector 2101248 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0

블록 계층이 호스트에 쓰기를 요청했으나 호스트가 실패를 반환한 경우입니다. VPS 환경에서 이는 플래시 셀의 노후화인 경우는 드뭅니다. 대개 호스트 스토리지 계층이나 네트워크 연결 스토리지(NAS)로 향하는 네트워크 경로의 문제이므로, 이는 공급자 측에서 발생하는 이벤트입니다. 타임스탬프, 장치 이름, 섹터 정보를 티켓에 복사하십시오. 스토리지 팀이 자사 로그와 대조할 때 필요한 정보입니다.

ext4에서 가장 중요한 시퀀스는 다음 쌍입니다.

EXT4-fs error (device vda1): ext4_journal_check_start:83: comm cron: Detected aborted journal
EXT4-fs (vda1): Remounting filesystem read-only

두 번째 줄이 치명적입니다. 시스템은 계속 켜져 있기 때문입니다. ping과 SSH에는 응답하지만 모든 쓰기 작업은 실패합니다. 애플리케이션이 모든 요청에서 오류를 발생시키는 동안에도 단순 HTTP 체크는 계속 통과할 수 있습니다.

XFS는 대신 파일 시스템을 중단시킵니다.

XFS (vda1): metadata I/O error in "xfs_trans_read_buf_map+0x1c0/0x2e0" at daddr 0x2 len 1 error 5
XFS (vda1): I/O Error Detected. Shutting down filesystem

journalctl -k는 저널이 디스크에 저장되지 않는 한 현재 부팅 세션만 읽습니다. 많은 이미지 파일은 RAM에 상주하는 휘발성 저널을 사용합니다. 지속성을 활성화하십시오. 그렇지 않으면 문제 해결을 위해 재부팅하는 바로 그 순간에 증거가 사라집니다.

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald
journalctl --list-boots

다음 재부팅 후에는 journalctl --list-boots 명령으로 여러 부팅 세션의 로그를 확인할 수 있어야 합니다. 지속성을 활성화하더라도 읽기 전용으로 전환된 파일 시스템은 이후에 발생한 일을 기록할 수 없습니다. 이것이 바로 로그를 외부 서버로 전송해야 하는 타당한 이유입니다.

신호 2: 읽기 전용으로 재마운트되는 상황 포착

오류를 감지하기 전에 먼저 확실하게 드러나도록 만듭니다.

findmnt -no SOURCE,FSTYPE,OPTIONS /

옵션에서 errors=remount-ro을 찾습니다. Ubuntu 및 Debian 클라우드 이미지는 /etc/fstab에 이 옵션을 설정하므로, 메타데이터 오류가 발생하면 파일 시스템이 손상된 채로 계속 작동하는 대신 읽기 전용으로 전환됩니다. 이 옵션이 없다면 /etc/fstab의 루트 항목에 추가하거나, sudo tune2fs -e remount-ro /dev/vda1을 사용하여 슈퍼블록에 설정하십시오. 조용한 데이터 손상보다는 확실하게 멈추는 편이 낫습니다.

마운트 플래그만으로는 증거가 부족합니다. 쓰기 테스트를 수행하십시오.

touch /var/tmp/.disk-probe

읽기 전용 루트 파일 시스템에서는 정확히 다음과 같이 출력됩니다.

touch: cannot touch '/var/tmp/.disk-probe': Read-only file system

/tmp가 아닌 /var/tmp을 사용하십시오. 대부분의 이미지에서 /tmp은 메모리에 상주하는 tmpfs이므로, 그곳에 성공적으로 쓰기를 수행해도 디스크 상태에 대해서는 아무것도 증명할 수 없습니다.

쓰기 테스트와 용량 확인을 함께 묶고, 모든 검사를 통과했을 때만 하트비트를 전송하십시오.

sudo tee /usr/local/sbin/disk-probe >/dev/null <<'EOF'
#!/bin/sh
set -eu
probe=/var/tmp/.disk-probe
echo ok > "$probe"
test "$(cat "$probe")" = ok
rm -f "$probe"
used=$(df --output=pcent / | tail -n1 | tr -dc '0-9')
test "$used" -lt 90
inodes=$(df --output=ipcent / | tail -n1 | tr -dc '0-9')
test "$inodes" -lt 90
curl -fsS --max-time 10 "https://status.example.com/api/push/REPLACE_TOKEN?status=up&msg=OK" >/dev/null
EOF
sudo chmod 755 /usr/local/sbin/disk-probe
sudo /usr/local/sbin/disk-probe && echo probe-ok

마지막 줄의 probe-ok는 전체 체인이 정상 작동함을 의미합니다. set -eu는 검사가 실패할 경우 curl 줄이 실행되기 전에 0이 아닌 값으로 종료되게 하여, 하트비트가 전송되지 않도록 합니다. 이 반전이 핵심입니다. 하트비트가 도착하지 않으면 모니터링 시스템은 빨간색으로 표시됩니다. 쓰기가 불가능한 서버는 자신의 문제를 설명할 수 없으므로 신뢰할 수 없습니다. 읽기 전용 파일 시스템에서도 읽기 작업은 가능하므로 스크립트 자체는 정상적으로 시작됩니다.

systemd 타이머를 사용하여 스크립트를 실행하십시오.

# /etc/systemd/system/disk-probe.service
[Unit]
Description=Disk writability and space probe

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/disk-probe

# /etc/systemd/system/disk-probe.timer
[Unit]
Description=Run the disk probe every five minutes

[Timer]
OnBootSec=2min
OnUnitActiveSec=5min

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now disk-probe.timer
systemctl list-timers disk-probe.timer
journalctl -u disk-probe.service -n 20 --no-pager

systemctl list-timers을 실행하면 NEXT 시간이 5분 이내로 남은 유닛을 확인할 수 있습니다. 검사가 실패하면 journalctl -u disk-probe.service에 셸의 오류 텍스트가 나타나므로, 서버에 로그인하지 않고도 파일 시스템이 꽉 찼는지 아니면 읽기 전용으로 전환되었는지 구분할 수 있습니다.

해당 푸시 URL은 Uptime Kuma 푸시 모니터용입니다. Push 유형의 모니터를 생성하고 토큰을 스크립트에 복사하십시오. 모니터의 하트비트 간격을 타이머 간격보다 약간 길게 설정하면, 실행이 한 번 늦어졌다고 해서 새벽 3시에 호출을 받는 일을 방지할 수 있습니다. 아직 상태 페이지가 없다면 직접 호스팅하는 Uptime Kuma 인스턴스가 이 검사를 수행하기에 가장 저렴한 방법입니다.

두 가지 솔직한 한계가 있습니다. 이 프로브는 쓰기 작업이 수락되었음을 확인할 뿐, 데이터가 실제 저장 장치에 도달했음을 보장하지는 않습니다. 읽기 작업이 페이지 캐시에서 처리될 수 있기 때문입니다. 또한 모니터링 대상 서버에서 직접 실행되므로, 서버가 완전히 멈추면 진단 결과를 보고하는 대신 침묵하게 됩니다.

루트 파일 시스템이 이미 읽기 전용 상태일 때의 대처법

상태를 확인합니다. findmnt -no OPTIONS /의 출력은 ro로 시작합니다.
증거를 먼저 RAM에 저장합니다. journalctl -k -b > /dev/shm/kernel.log를 실행한 다음, 노트북에서 scp user@server:/dev/shm/kernel.log .을 사용하여 서버 밖으로 가져옵니다.
단순히 mount -o remount,rw /를 실행하고 계속 사용하지 마십시오. ext4가 저널을 중단했다면 재마운트가 즉시 다시 실패할 것이며, 성공하더라도 아무도 확인하지 않은 손상된 데이터 위에 쓰기를 수행하게 됩니다.
제공업체의 복구 모드로 재부팅하고 파일 시스템이 언마운트된 상태에서 검사하십시오. ext4는 e2fsck -fy /dev/vda1, XFS는 xfs_repair /dev/vda1을 사용합니다.
타임스탬프와 섹터 정보가 포함된 blk_update_request 줄을 제공업체에 전달하십시오.
백업에서 복원한 후 비교하십시오. 수리가 필요한 파일 시스템은 최근 쓰기 작업의 마지막 부분을 잃어버렸을 수 있습니다.

신호 3: 지연 시간 및 처리량 추세

sudo apt install -y sysstat
iostat -xdz 5 3

먼저 r_await과 w_await를 읽으십시오. 이는 큐에서 대기한 시간을 포함하여 읽기 또는 쓰기 작업에 소요된 평균 밀리초(ms)입니다. 다음으로 진행 중인 평균 요청 수인 aqu-sz을 확인하십시오. 가상 디스크에서 %util은 무시해도 좋습니다. 이는 단순히 큐가 비어 있지 않음을 의미할 뿐이며, 여러 요청을 병렬로 처리하는 장치는 한계치에 도달하지 않았더라도 100퍼센트에 가깝게 표시될 수 있기 때문입니다. 사용자가 체감하는 성능을 추적하는 지표는 await입니다.

절대적인 값보다는 자체적인 기준선이 중요하므로, 시스템이 한가한 시간대의 수치를 기록하여 보관하십시오. 직접 카운터를 수집하고 싶다면 /proc/diskstats이 원시 데이터 소스입니다.

의도적인 측정을 수행하려면 다음을 따르십시오:

sudo apt install -y fio
fio --name=readlat --filename=/var/tmp/fio.probe --size=512M --rw=randread --bs=4k --iodepth=1 --direct=1 --runtime=30 --time_based --group_reporting
rm -f /var/tmp/fio.probe

clat percentiles 블록, 특히 99번째 백분위수를 확인하십시오. --direct=1는 페이지 캐시를 건너뜁니다. 하지만 호스트의 캐시는 건너뛰지 않으므로, 결과값은 프로세스에서 플랫폼의 스토리지까지 이르는 전체 경로를 설명합니다. 이 작업은 자체 워크로드와 경쟁하므로 서버가 유휴 상태일 때 실행하십시오.

커널 로그에 오류가 없는데도 await이 상승한다면, 이는 보통 드라이브 고장이 아닙니다. 이는 호스트에서의 경합이며, 시끄러운 이웃으로 인한 CPU 스틸 타임의 스토리지 버전이라고 할 수 있습니다. 만약 매일 같은 시간에 수치가 상승하고 기술 지원 문의 결과가 정상으로 나온다면, I/O를 공유하지 않는 요금제로 변경하는 것이 해결책입니다. 디스크 I/O가 병목인 워크로드의 경우 일반 VPS보다 스토리지 VPS를 사용하는 것이 이에 해당합니다.

마운트 상태에서 실행 가능한 파일시스템 점검

ext4는 슈퍼블록 내에 오류 카운터를 유지하며, 로그가 사라진 재부팅 이후에도 이 값은 보존됩니다.

sudo dumpe2fs -h /dev/vda1 2>/dev/null | grep -iE 'filesystem state|error count|first error|last error'

정상적인 파일시스템은 Filesystem state: clean 및 FS Error count: 0을 출력합니다. clean with errors와 0이 아닌 카운트 값은 커널이 특정 시점에 메타데이터 오류를 감지했음을 의미하며, 이는 아무도 인지하지 못했거나 로그가 이미 덮어씌워진 경우에도 해당합니다. 해당 명령은 매주 수행하는 점검 항목에 포함해야 합니다.

마운트된 루트 파일시스템에 대해 fsck를 실행할 수는 없으며, 라이브 파일시스템에서 e2fsck -n을 실행하면 데이터가 실시간으로 변경되는 과정에서 발생하는 문제만 보고될 뿐입니다. 실제 점검을 강제하려면 제공자의 콘솔을 통해 부팅 시 커널 명령줄에 fsck.mode=force fsck.repair=yes을 추가하십시오. 그러면 systemd-fsck가 루트 파일시스템이 읽기-쓰기 모드로 마운트되기 전에 점검을 수행합니다.

XFS는 온라인 점검 기능을 제공하지 않습니다. xfs_repair -n /dev/vda1는 마운트된 파일시스템에 대해 실행할 수 없으므로, 구조 모드(rescue mode)에서 수행해야 합니다. 대신 XFS는 메타데이터 오류 발생 시 파일시스템을 즉시 중단시켜 문제를 명확히 알립니다.

Btrfs의 경우 카운터가 내장되어 있으며 영구적으로 유지됩니다.

sudo btrfs device stats /
sudo btrfs scrub start -B /

위의 write_io_errs 또는 corruption_errs 값이 0보다 크다면 실제 이벤트가 발생한 것이며, 카운터는 재설정하기 전까지 재부팅 후에도 값을 유지합니다. scrub는 모든 블록을 다시 읽고 체크섬을 검증하는데, 이는 가상 디스크에서 수행할 수 있는 미디어 테스트와 가장 유사한 작업입니다. I/O 부하가 크므로 사용량이 적은 시간대에 예약하십시오.

신호 5: df가 숨기는 부분을 포함한 여유 공간

디스크 결함과 마찬가지로 공간 부족은 서버를 중단시키며, 실제로는 훨씬 더 자주 발생합니다.

df -h /
df -i /
sudo du -xh --max-depth=1 / | sort -h | tail -n 20

No space left on device을 실행했을 때 df -h은 여유 공간이 있다고 표시되지만 실제로는 바이트가 아닌 inode가 고갈된 상황이며, df -i은 IUse%가 100퍼센트임을 보여줍니다. 캐시 디렉터리나 메일 스풀에 수백만 개의 작은 파일이 쌓이면 이런 현상이 발생하며, 큰 파일을 삭제해도 해결되지 않습니다.

파일을 삭제했는데도 공간이 확보되지 않는다면, 실행 중인 프로세스가 삭제된 파일을 여전히 열고 있을 가능성이 큽니다. sudo lsof +L1은 링크 카운트가 0에 도달한 파일 목록을 보여줍니다. 해당 파일을 잡고 있는 프로세스를 재시작하면 공간이 해제됩니다.

저널(journal)은 조용히 공간을 차지하는 주범입니다. journalctl --disk-usage은 현재 저널이 차지하는 용량을 보고합니다. /etc/systemd/journald.conf 파일에서 SystemMaxUse=200M 설정을 통해 용량을 제한한 뒤 sudo systemctl restart systemd-journald를 실행하고, sudo journalctl --vacuum-size=200M를 통해 즉시 공간을 회복하십시오.

버그처럼 보이지만 실제로는 그렇지 않은 경우도 있습니다. 씬 프로비저닝(thin provisioned)된 호스트 스토리지에서는 게스트의 df은 여유 공간이 있다고 표시되더라도 호스트의 풀이 가득 찰 수 있습니다. 이 경우 커널 로그에 I/O 오류가 기록되면서 쓰기 작업이 실패하지만, 게스트 내부에서는 공간 부족 경고가 나타나지 않습니다. 파일 시스템이 가득 차지 않았음에도 오류가 발생한다면 즉시 티켓을 발행해야 하는 상황입니다.

메트릭 에이전트에 신호 연결하기

푸시 프로브는 예 또는 아니오로 응답합니다. 추세 분석에는 메트릭 에이전트가 필요하며, Prometheus node_exporter는 추가 설정 없이 위에서 언급한 모든 항목을 이미 내보내고 있습니다. 기반으로 삼을 메트릭 이름은 다음과 같습니다.

node_filesystem_readonly은 마운트가 읽기 전용으로 전환되면 1이 되며, 이것이 리마운트 알람의 기준입니다.
node_filesystem_avail_bytes과 node_filesystem_files_free는 각각 바이트와 아이노드 사용량을 다룹니다.
node_disk_io_time_seconds_total과 node_disk_read_time_seconds_total은 그래프로 그릴 수 있는 카운터 형식으로 사용 시간과 지연 시간을 제공합니다.

실제로 호출(page)이 발생하는 상황을 포착하는 규칙 두 가지는 다음과 같습니다.

- alert: FilesystemReadOnly
  expr: node_filesystem_readonly{fstype!~"tmpfs|overlay"} == 1
  for: 2m
- alert: FilesystemFillingUp
  expr: predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[6h], 4*24*3600) < 0
  for: 30m

두 번째 규칙은 현재 추세상 4일 이내에 용량이 0에 도달할 것으로 예상될 때 작동합니다. 따라서 95%가 찼을 때 몇 분 만에 대응해야 하는 상황 대신, 며칠 전에 미리 경고를 받을 수 있습니다.

책임 소재

물리적 드라이브는 서비스 제공업체가 관리합니다. 제공업체는 SMART 데이터를 읽고, 어레이를 운영하며, 재할당 섹터가 증가하는 드라이브를 교체합니다. 어레이가 장애를 흡수하므로 보통 이 과정은 사용자에게 알리지 않고 진행됩니다. 이것이 바로 VPS에서의 RAID 10이 존재하는 이유입니다. 드라이브가 고장 나더라도 서비스 중단 없이 재구축(rebuild)이 이루어집니다. 사용자는 이 과정을 볼 수 없으며, 이러한 추상화 계층에 비용을 지불하는 것이 가상 서버를 임대하는 주된 목적입니다.

데이터에 대한 책임은 사용자에게 있으며, 드라이브 원격 측정 데이터는 데이터를 보호해주지 않습니다. 실제로 테넌트의 데이터를 파괴하는 사건은 실수로 실행한 rm, 잘못된 배포, SSH 키를 탈취한 침입자, 그리고 어레이 전체를 무력화하는 플랫폼 장애입니다. SMART 속성으로는 이러한 사건을 예측할 수 없습니다.

따라서 테넌트의 진정한 보호 수단은 서버 외부의 백업과 직접 수행해 본 복구 절차입니다. 제공업체의 스냅샷은 편리하지만 보호 대상과 동일한 플랫폼에 저장됩니다. 이것이 스냅샷과 백업이 서로 다른 보호 수단인 이유입니다. 캘린더에 훈련 일정을 등록하십시오. 분기마다 한 번씩 최신 백업을 새로운 VPS에 복구하고, 애플리케이션을 실행한 뒤 소요 시간을 기록하십시오. 그 시간이 바로 실제 복구 시간(RTO)입니다. 첫 번째 훈련은 항상 예상보다 오래 걸립니다.

SMART를 적용해야 하는 경우

smartctl를 다루는 가이드는 정확하며, 하드웨어를 실제로 소유하는 즉시 적용됩니다.

전용 서버나 베어메탈 서버: sudo smartctl -a /dev/sda가 전체 속성 테이블을 반환하며, smartd를 통해 속성 변경 시 메일을 받을 수 있습니다.
물리 디스크를 게스트에 직접 전달하는 스토리지 플랜: 이는 판매 포인트이므로 제공업체에서 명시적으로 문서화합니다.
자택이나 임대한 랙 공간에 있는 본인 소유의 하드웨어.
sudo smartctl -a -d megaraid,0 /dev/sda으로 접근 가능한 RAID 컨트롤러 뒤의 디스크나, -d sat을 사용하는 USB 인클로저.

실제 NVMe 환경에서는 sudo smartctl -a -d nvme /dev/nvme0 및 sudo nvme smart-log /dev/nvme0n1가 드라이브 자체에서 critical_warning 및 percentage_used을 보고합니다. 실제 SATA 환경에서 장애를 예측하는 속성은 Reallocated_Sector_Ct (5), Current_Pending_Sector (197), Offline_Uncorrectable (198), Reported_Uncorrect (187)입니다. 이 중 어느 하나라도 0에서 벗어나면 교체를 계획해야 합니다. 대규모 드라이브 연구 결과도 동일한 짧은 목록을 가리키며, 다른 대부분의 속성은 불필요한 정보입니다.

수동으로 확인하기보다 데몬을 실행하십시오.

sudo systemctl enable --now smartd
sudo smartctl -t short /dev/sda
sudo smartctl -l selftest /dev/sda

자가 진단 로그에는 방금 시작한 실행에 대해 Completed without error이 표시되어야 합니다. Ubuntu와 Debian은 2026년 8월 기준으로 DEVICESCAN 라인이 포함된 /etc/smartd.conf을 제공하므로, 데몬이 인식 가능한 모든 디스크를 감지하고 변경 사항 발생 시 root 계정으로 메일을 보냅니다. 가상 디스크에서는 이 기능이 작동하지 않으며, 이 가이드의 나머지 부분이 존재하는 이유가 바로 그것입니다.

FAQ

VPS에서 smartctl이 작동하지 않는 이유는 무엇입니까?

디스크가 가상이기 때문입니다. virtio-blk를 사용하는 KVM 게스트에서 smartctl -a /dev/vda를 실행하면 /dev/vda: Unable to detect device type이 출력됩니다. 반가상화 디스크는 SMART 요청을 전달할 ATA 또는 SCSI 명령 채널을 가지고 있지 않기 때문입니다. 에뮬레이션된 디스크의 경우 모델명이 QEMU HARDDISK로 표시되는 장치에 도달하게 되며, 그 뒤에는 사용할 수 있는 SMART 데이터가 없습니다. 컨테이너 내부에서는 CAP_SYS_RAWIO 권한이 부족하여 smartctl 실행이 즉시 거부됩니다. 이는 설정 오류가 아니며, 어떤 -d 플래그를 사용해도 해결할 수 없습니다.

VPS 디스크의 장애 여부를 어떻게 알 수 있습니까?

하드웨어 상태보다는 시스템의 반응을 관찰하십시오. sudo journalctl -k -p err -b에서 blk_update_request: I/O error 줄과 Remounting filesystem read-only 항목을 확인하십시오. 로그에서 이미 누락된 오류를 찾으려면 sudo dumpe2fs -h /dev/vda1 | grep -i 'error count'을 실행하십시오. 정상 상태일 때 기록해 둔 기준값과 비교하여 iostat -xdz 5에서 r_await을 추적하십시오. VPS에서 발생하는 I/O 오류는 대개 드라이브 자체의 수명 문제보다는 호스트 스토리지의 문제일 가능성이 높으므로, 타임스탬프와 섹터 정보를 포함하여 지원 티켓을 제출해야 합니다.

VPS 디스크 상태에 대해 어떤 알림을 설정해야 합니까?

네 가지 알림으로 충분합니다. node_filesystem_readonly == 1 또는 쓰기 테스트 실패로 인한 읽기 전용 마운트 발생, 여유 공간 및 여유 inode가 0에 가까워지는 경우, 최근 간격 내에 발생한 모든 커널 I/O error 오류, 그리고 서버가 응답을 멈췄을 때 알림을 받을 수 있는 하트비트 체크입니다. SMART 데이터는 가상 디스크에서 누락되거나 하이퍼바이저의 에뮬레이션 값을 보여줄 뿐이므로 알림 설정에서 제외하십시오.

파일 시스템이 왜 읽기 전용으로 다시 마운트되었습니까?

errors=remount-ro 옵션으로 마운트된 ext4는 메타데이터 오류가 발생하면 의도적으로 이 작업을 수행합니다. 손상을 방지하기 위해 쓰기 작업을 중단하는 것입니다. 트리거는 다시 마운트된 줄 바로 위의 커널 로그에 있으며, 일반적으로 하위 장치에서 I/O 오류가 반환된 후 저널이 중단되었다는 EXT4-fs error 메시지가 기록됩니다. 파일 시스템을 점검하지 않고 읽기-쓰기 모드로 다시 마운트하는 것은 증상만 숨길 뿐 원인을 해결하지 못합니다. 로그를 확보한 뒤, 복구 모드에서 파일 시스템을 언마운트하고 e2fsck -fy /dev/vda1를 실행하여 점검하십시오.

가상 서버에서 SMART 데이터를 읽을 방법은 없습니까?

특정 경우에는 가능합니다. 전용 서버나 베어메탈 서버는 실제 속성값을 제공합니다. 물리 디스크를 게스트에 직접 전달(passthrough)하는 스토리지 플랜이나 본인이 직접 소유한 호스트도 마찬가지입니다. 일부 플랫폼은 게스트에 NVMe 컨트롤러를 제공하며 nvme smart-log가 로그를 반환하기도 합니다. 먼저 sudo nvme id-ctrl /dev/nvme0을 실행해 보십시오. 모델명에 네트워크 스토리지 서비스가 포함되어 있다면 해당 카운터는 소프트웨어 컨트롤러에서 생성된 것입니다. 공유 머신에서 패스스루 노드가 실제 카운터를 노출하더라도 이는 다른 사용자와 공유하는 하드웨어의 정보이므로, 유일한 해결책은 지원 티켓을 제출하는 것뿐입니다.

#monitoring#smart#nvme #storage #vps