VPS वर disk health कशी तपासावी?

VPS वर disk health monitoring प्रत्यक्षात काय पाहू शकते

VPS वरील disk health monitoring समजून घेताना बहुतेक मार्गदर्शक टाळतात अशा एका तथ्यापासून सुरुवात करावी लागते: disk तुमच्या मालकीची नसते. तुमच्या guest ला virtual block device दिसते. Physical drive आणि त्यावर साठवलेले सर्व counters host च्या मालकीचे असतात. smartctl /dev/vda अयशस्वी होते कारण तुम्ही command चुकीची टाइप केली आहे असे नाही. त्या device मागे असलेली कोणतीही गोष्ट या प्रश्नाचे उत्तर देऊ शकत नाही म्हणून ते अयशस्वी होते.

SMART (self-monitoring, analysis and reporting technology) ही drive वरच साठवलेली counters ची table आहे: reallocated sectors, pending sectors, power-on hours आणि media errors. ही table वाचण्यासाठी ATA किंवा NVMe (non-volatile memory express) commands प्रत्यक्ष hardware पर्यंत पोहोचवणारा मार्ग आवश्यक असतो. Paravirtual disk असा मार्ग उपलब्ध करून देत नाही. त्यामुळे guest ला telemetry काढून टाकलेले storage मिळते.

Tenant hardware ऐवजी त्याचे परिणाम monitor करतो. Guest च्या आतून चार signals दिसतात: kernel log मधील I/O (input/output) errors, read-only म्हणून पुन्हा mount होणारी filesystem, हळूहळू वाढणारी latency आणि संपणारी space. या चारही बाबींवर आज alerts लावता येतात. वापरकर्ता तक्रार करण्यापूर्वी या चारही बाबी दिसतात. प्रथम त्यांची व्यवस्था करा. जबाबदारीचे विभाजन शेवटी येते, कारण त्यानुसार तुम्ही प्रयत्न कुठे करावेत हे बदलते.

तुमचा सर्व्हर प्रत्यक्षात काय उघड करतो हे सिद्ध करा

तुम्ही कोणत्या परिस्थितीत आहात असे गृहीत धरू नका. प्रथम तपासा आणि त्यानंतर जुळणारा विभाग वाचा.

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 हा paravirtual transport आहे. त्यामागे ATA किंवा SCSI command set नसतो. त्यामुळे SMART विनंती पाठवण्यासाठी कोणतेही channel उपलब्ध नसते. -d sat आणि -d scsi देखील त्याच कारणामुळे अयशस्वी होतात. समस्या flag मध्ये नसून transport मध्ये आहे.

emulated SATA किंवा SCSI डिस्क. डिव्हाइस /dev/sda आहे आणि smartctl त्याची ओळख पटवण्याइतपत पुढे जाते. Model line मध्ये QEMU HARDDISK दिसते. हा string स्वतःच उत्तर देतो: तुम्ही emulator ने तयार केलेले device वाचत आहात आणि त्यात वापरण्यायोग्य SMART capability उपलब्ध नसल्याचे ते दाखवते.

NVMe namespace. sudo nvme smart-log /dev/nvme0n1 पूर्ण log परत करते. याच ठिकाणी अनेकांची दिशाभूल होते. प्रथम sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)' वापरून controller identity तपासा. Network storage product चे नाव असलेला model number दिसत असल्यास controller software-based आहे. त्यामुळे percentage_used आणि media_errors तुमच्या डेटाखालील flash नव्हे, तर त्या emulation चे वर्णन करतात. तुमचे storage प्रत्यक्षात काय आहे हे जाणून घ्यायचे असल्यास plan description वर विश्वास ठेवण्याऐवजी Linux वर NVMe disk पडताळा.

LXC (Linux containers) किंवा OpenVZ सारखा container. तुमच्याकडे स्वतःचे block device नसते. lsblk host ची devices दाखवते किंवा काहीही दाखवत नाही. तसेच container कडे CAP_SYS_RAWIO नसल्यामुळे smartctl नाकारले जाते:

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

ते कार्य करते अशा परिस्थितीबाबत एक इशारा. VPS वर smartctl ने पूर्ण attribute table परत केल्यास, त्यावर कोणतीही कारवाई करण्यापूर्वी serial number वाचा. काही hosts passthrough device node उपलब्ध करून देतात. अशा वेळी हे counters त्या मशीनवरील सर्व tenants वापरत असलेल्या hardware शी संबंधित असतात. तेथील वाढता Reallocated_Sector_Ct हा support ticket चा विषय आहे. तो तुमच्या डेटाबाबतचे विधान नाही.

कर्नल लॉगमधील Signal 1: I/O errors

हा tenant कडे उपलब्ध असलेला सर्वाधिक उपयुक्त signal आहे. यासाठी agent ची आवश्यकता नाही.

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'

virtual disk कडून आलेली अयशस्वी request अशी दिसते:

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

block layer ने host कडे write करण्याची विनंती केली आणि host ने failure परत केला. VPS वर हे क्वचितच flash cell खराब झाल्यामुळे होते. सहसा host storage layer किंवा network attached storage कडे जाणारा network path कारणीभूत असतो. त्यामुळे ही provider side event असते. timestamp, device name आणि sector तुमच्या ticket मध्ये नोंदवा. Storage team त्यांच्या logs मधील नोंदी यांच्याशी जुळवू शकते.

लक्षात ठेवण्यासारखा ext4 sequence म्हणजे ही जोडी:

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

दुसरी line अधिक गंभीर आहे, कारण machine सुरूच राहते. ती ping ला उत्तर देते, SSH ला उत्तर देते आणि प्रत्येक write fail होतो. साधी HTTP check सुरू राहते, पण application प्रत्येक request वर error दाखवते.

XFS त्याऐवजी filesystem shutdown करते:

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

journal disk वर साठवला जात नसेल, तर journalctl -k फक्त current boot मधील नोंदी वाचते. अनेक images मध्ये RAM मध्ये राहणारा volatile journal असतो. persistence सुरू करा. अन्यथा troubleshooting करताना तुम्ही करणार असलेल्या reboot वेळीच evidence नाहीसे होईल.

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

तुमच्या पुढील reboot नंतर journalctl --list-boots ने एकापेक्षा अधिक boot सूचीबद्ध केले पाहिजेत. persistence सुरू असले तरी read-only झालेला filesystem त्यानंतर काय घडले ते record करू शकत नाही. त्यामुळे logs box बाहेर पाठवणे हा योग्य निर्णय आहे.

संकेत 2: read-only remount पकडणे

तो शोधण्याचा प्रयत्न करण्यापूर्वी अपयश स्पष्टपणे दिसेल अशी रचना करा.

findmnt -no SOURCE,FSTYPE,OPTIONS /

पर्यायांमध्ये errors=remount-ro शोधा. Ubuntu आणि Debian cloud images ते /etc/fstab मध्ये सेट करतात. त्यामुळे metadata error आल्यावर filesystem मधील नुकसान दुर्लक्षित करून पुढे जाण्याऐवजी filesystem read-only म्हणून remount होते. ते नसल्यास /etc/fstab मधील root entry मध्ये ते जोडा किंवा sudo tune2fs -e remount-ro /dev/vda1 वापरून superblock मध्ये सेट करा. शांतपणे होणाऱ्या corruption पेक्षा स्पष्टपणे थांबणे चांगले.

Mount flag पुरावा नाही. लिहून तपासणी करा:

touch /var/tmp/.disk-probe

Read-only root वर याचे नेमके output असेल:

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

/tmp ऐवजी /var/tmp वापरा. बहुतेक images मध्ये /tmp हा memory मध्ये ठेवलेला tmpfs असतो. त्यामुळे तेथे यशस्वी write झाल्याने तुमच्या disk बद्दल काहीही सिद्ध होत नाही.

Write test सोबत space check देखील जोडा आणि प्रत्येक तपासणी यशस्वी झाल्यावरच heartbeat पाठवा:

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 याचा अर्थ संपूर्ण chain यशस्वी झाली आहे. set -eu मुळे कोणतीही तपासणी अयशस्वी झाल्यास curl ओळ चालण्यापूर्वी process non-zero status ने exit होते. त्यामुळे heartbeat पाठवला जात नाही. हाच या उलट्या पद्धतीचा उद्देश आहे: काहीही पोहोचले नाही तर monitor लाल होतो. स्वतःची समस्या लिहू न शकणाऱ्या server च्या वर्णनावर विश्वास ठेवता येत नाही. Read-only filesystem वर read अजूनही कार्य करतात. त्यामुळे script स्वतः सुरू होते.

हे systemd timer मधून चालवा.

# /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 मध्ये unit दिसायला हवे आणि त्याची NEXT वेळ पाच मिनिटांपेक्षा कमी अंतरावर असावी. Run अयशस्वी झाल्यास shell च्या स्वतःच्या error text सह journalctl -u disk-probe.service मध्ये नोंद दिसते. त्यामुळे login न करता read-only filesystem आणि full filesystem यांमध्ये फरक करता येतो.

ही push URL Uptime Kuma push monitor ची आहे. Push प्रकारचा monitor तयार करा, त्याचा token script मध्ये कॉपी करा आणि monitor चा heartbeat interval timer interval पेक्षा थोडा मोठा ठेवा. त्यामुळे एखादा run धीमा झाला तरी 03:00 वाजता page येणार नाही. अजून status page नसल्यास, self-hosted Uptime Kuma instance हे तपासणी ठेवण्यासाठी सर्वात कमी खर्चाचे ठिकाण आहे.

दोन महत्त्वाच्या मर्यादा आहेत. Probe ने write स्वीकारली गेली हे निश्चित होते; मात्र bytes durable storage पर्यंत पोहोचले हे निश्चित होत नाही, कारण read back page cache मधून मिळू शकतो. तसेच हा probe ज्या machine वर लक्ष ठेवतो त्याच machine वर चालतो. त्यामुळे पूर्णपणे अडकलेला server diagnosis पाठवण्याऐवजी शांत होतो.

सिग्नल 3: latency आणि throughput मधील प्रवाह

sudo apt install -y sysstat
iostat -xdz 5 3

प्रथम r_await आणि w_await वाचा. Read किंवा write पूर्ण होण्यासाठी लागलेल्या सरासरी milliseconds या मूल्यांमध्ये queue मध्ये थांबवलेला वेळही समाविष्ट असतो. त्यानंतर aqu-sz वाचा. हे in-flight असलेल्या requests ची सरासरी संख्या आहे. Virtual disk वर %util दुर्लक्षित करा. याचा अर्थ फक्त queue रिकामी नव्हती, एवढाच होतो. अनेक requests समांतरपणे पूर्ण करणारे device त्याच्या मर्यादेपासून दूर असतानाही 100 percent च्या जवळ दिसू शकते. वापरकर्त्यांना प्रत्यक्ष जाणवणारी स्थिती await या मूल्यामधून समजते.

तुमच्या स्वतःच्या baseline च्या तुलनेत absolute values अधिक महत्त्वाच्या नसतात. त्यामुळे शांत वेळेतील एका तासाची नोंद करून ती जतन करा. Counters स्वतः गोळा करायचे असल्यास /proc/diskstats हा raw source वापरा.

नियोजित मोजमापासाठी:

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 block वाचा, विशेषतः 99th percentile. --direct=1 मुळे तुमचा page cache वगळला जातो. मात्र host चा cache वगळला जात नाही. त्यामुळे या निकालातून तुमच्या process पासून platform च्या storage पर्यंतचा संपूर्ण मार्ग दर्शविला जातो. Server idle असताना हे चालवा, कारण ते तुमच्या स्वतःच्या workload शी स्पर्धा करते.

Kernel log मध्ये errors नसताना await वाढत असल्यास drive बिघडलेली आहे असे सहसा मानू नका. हा host वरील contention असतो. Storage संदर्भात हे गोंगाट करणाऱ्या शेजाऱ्यामुळे होणाऱ्या CPU steal time सारखे आहे. हे दररोज त्याच वेळी परत येत असेल आणि तुमचे ticket कोणत्याही समस्येशिवाय बंद होत असेल, तर समान प्रकारे shared नसलेल्या I/O असलेला plan वापरणे हा उपाय आहे. Workload disk bound असल्यास regular VPS पेक्षा storage VPS या परिस्थितीसाठी योग्य ठरतो.

माउंट केलेल्या स्थितीत चालवता येणाऱ्या filesystem तपासण्या

ext4 superblock मध्ये error counter ठेवते. तुमचे logs उपलब्ध नसले तरी हा counter reboot नंतरही टिकतो.

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

निरोगी filesystem मध्ये Filesystem state: clean आणि FS Error count: 0 दिसतात. clean with errors आणि शून्यापेक्षा जास्त count यांचा अर्थ kernel ला कधीतरी metadata error आढळला आहे. तो error कोणाच्याही लक्षात आला नसला किंवा log rotate होऊन उपलब्ध नसला तरीही हे लागू होते. ही एक command साप्ताहिक तपासणीत असणे आवश्यक आहे.

माउंट केलेल्या root filesystem वर fsck चालवता येत नाही. तसेच live filesystem वर e2fsck -n चालवल्यास, तपासणीदरम्यान बदलत असलेल्या डेटामुळे निर्माण झालेल्या समस्या दिसू शकतात. प्रत्यक्ष तपासणी सक्तीने चालवण्यासाठी, provider च्या console मधून एका boot साठी kernel command line मध्ये fsck.mode=force fsck.repair=yes जोडा. त्यानंतर systemd-fsck root read-write म्हणून माउंट करण्यापूर्वी तपासणी चालवते.

XFS मध्ये online तपासणी उपलब्ध नाही. माउंट केलेल्या filesystem वर चालवले असता xfs_repair -n /dev/vda1 नकार देते. त्यामुळे ते rescue mode मध्ये चालवावे. मात्र XFS या मर्यादेची भरपाई स्पष्ट वर्तनाने करते: metadata error आढळल्यास पुढे काम सुरू ठेवण्याऐवजी ते filesystem बंद करते.

Btrfs मध्ये counters अंगभूत असून कायमस्वरूपी साठवले जातात.

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

शून्यापेक्षा जास्त write_io_errs किंवा corruption_errs ही वास्तविक घटना असते. हे counters reset करेपर्यंत reboot नंतरही त्यांची मूल्ये जतन करतात. scrub प्रत्येक block पुन्हा वाचते आणि त्याचा checksum पडताळते. virtual disk वर उपलब्ध असलेल्या media test शी ही तपासणी सर्वाधिक जवळची आहे. यासाठी 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 मोकळी जागा दाखवते. याचा अर्थ bytes नव्हे तर inodes संपले आहेत. df -i मध्ये IUse% 100 percent असल्याचे दिसते. cache directory किंवा mail spool मध्ये लाखो लहान files असल्यास असे होते. मोठ्या files हटवल्याने यावर उपाय होत नाही.

एखादी file delete केल्यानंतरही जागा मोकळी होत नसेल, तर ती file बहुधा एखाद्या चालू process ने उघडी ठेवलेली असते. sudo lsof +L1 अशा files दाखवते ज्यांचा link count zero झाला आहे. ती file धरून ठेवणारा process restart केल्यावर जागा मोकळी होते.

journal हा शांतपणे जागा वापरणारा सामान्य घटक आहे. त्याने व्यापलेली जागा journalctl --disk-usage दाखवते. /etc/systemd/journald.conf मध्ये SystemMaxUse=200M वापरून त्याची मर्यादा ठरवा आणि sudo systemctl restart systemd-journald नंतर sudo journalctl --vacuum-size=200M वापरून जागा तत्काळ मोकळी करा.

एक परिस्थिती bug सारखी दिसते, पण ती bug नसते. thin provisioned host storage वापरताना host चा pool भरू शकतो, जरी तुमच्या df मध्ये अजूनही अनेक gigabytes मोकळे दिसत असले तरी. त्यानंतर तुमचे writes अयशस्वी होतात आणि kernel log मध्ये I/O errors दिसतात. guest मध्ये मात्र कुठेही space warning दिसत नाही. filesystem पूर्ण भरलेले नसताना errors दिसत असल्यास, त्याच तासात ticket उघडणे योग्य ठरते.

Metrics agent मध्ये संकेत जोडणे

Push probe होय किंवा नाही एवढेच उत्तर देते. Trends साठी metrics agent आवश्यक असतो. Prometheus node_exporter अतिरिक्त configuration शिवाय वरील सर्व metrics आधीच export करतो. पुढील metric names वर आधारित नियम तयार करा:

• node_filesystem_readonly mount read-only झाल्यावर 1 होते. हे remount alarm साठी वापरा.
• node_filesystem_avail_bytes आणि node_filesystem_files_free bytes आणि inodes स्वतंत्रपणे दर्शवतात.
• node_disk_io_time_seconds_total आणि node_disk_read_time_seconds_total busy time आणि latency counters म्हणून देतात. त्यांचे graphs तयार करता येतात.

प्रत्यक्षात 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

दुसरा नियम सध्याचा trend चार दिवसांच्या आत शून्यापर्यंत पोहोचेल तेव्हा सक्रिय होतो. त्यामुळे filesystem 95 percent भरल्यावर, म्हणजे तुमच्याकडे काही मिनिटेच शिल्लक असताना, सूचना मिळण्याऐवजी अनेक दिवस आधी इशारा मिळतो.

कोण कशासाठी जबाबदार आहे

तुमचा provider भौतिक drives साठी जबाबदार असतो. तो SMART वाचतो, array चालवतो आणि reallocated sectors वाढत असलेला drive बदलतो. Array failure सहन करत असल्यामुळे तो सहसा तुम्हाला याची माहिती देत नाही. तुमच्या VPS अंतर्गत RAID 10 यासाठीच असतो: dead drive मुळे outage न होता rebuild सुरू होते. तुम्हाला यापैकी काहीही दिसत नाही. Virtual server भाड्याने घेण्याच्या abstraction चा मुख्य उद्देशही हाच असतो.

तुमच्या data ची जबाबदारी तुमची असते. Drive telemetry मुळे तुमच्या data चे संरक्षण झाले नसते. Tenant data प्रत्यक्षात नष्ट करणाऱ्या घटना म्हणजे चुकीचे rm, चुकीचा deploy, तुमच्या SSH key सह आलेला intruder आणि array सोबत platform ला प्रभावित करणारी incident. SMART attributes यापैकी कोणतीही घटना predict करू शकत नाहीत.

म्हणून tenant चे खरे संरक्षण म्हणजे server च्या बाहेर ठेवलेला backup आणि तुम्ही स्वतः करून पाहिलेला restore. Provider snapshots सोयीचे असतात. ते ज्या platform वरील गोष्टीचे संरक्षण करतात, त्याच platform वर असतात. म्हणूनच snapshots आणि backups ही वेगवेगळी संरक्षणे आहेत. Calendar मध्ये drill निश्चित करा: प्रत्येक quarter मध्ये नवीनतम backup fresh VPS मध्ये restore करा, application सुरू करा आणि यासाठी लागलेला वेळ लिहून ठेवा. तोच तुमचा वास्तविक recovery time असतो. पहिला drill नेहमी अपेक्षेपेक्षा जास्त वेळ घेतो.

तुमच्यासाठी SMART कधी लागू होते

smartctl शिकवणारे मार्गदर्शक योग्य आहेत आणि हार्डवेअर खरोखर तुमच्या मालकीचे होताच ते लागू होतात:

• Dedicated किंवा bare metal server, ज्यामध्ये sudo smartctl -a /dev/sda पूर्ण attribute table दाखवते आणि एखादा attribute बदलल्यावर smartd तुम्हाला ईमेल पाठवू शकते.
• Guest ला physical disk थेट उपलब्ध करून देणारे storage plans. Provider हे स्पष्टपणे नमूद करतात, कारण ते त्यांच्या सेवेचे विक्रीवैशिष्ट्य असते.
• तुमच्या मालकीचे हार्डवेअर, ते घरात असो किंवा तुम्ही भाड्याने घेतलेल्या rack space मध्ये असो.
• RAID controller मागील disk, जी sudo smartctl -a -d megaraid,0 /dev/sda द्वारे उपलब्ध होते, किंवा -d sat असलेले USB enclosure.

प्रत्यक्ष NVMe वर sudo smartctl -a -d nvme /dev/nvme0 आणि sudo nvme smart-log /dev/nvme0n1 drive मधूनच critical_warning आणि percentage_used दाखवतात. प्रत्यक्ष SATA वर बिघाडाचा अंदाज देणारे attributes म्हणजे Reallocated_Sector_Ct (5), Current_Pending_Sector (197), Offline_Uncorrectable (198) आणि Reported_Uncorrect (187). यापैकी कोणत्याही attribute चे मूल्य zero पेक्षा वाढल्यास replacement ची योजना करा. मोठ्या प्रमाणातील drive अभ्यासांमध्येही हीच छोटी यादी वारंवार दिसते; इतर बहुतेक attributes म्हणजे noise असतात.

हाताने तपासणी करण्याऐवजी daemon चालवा.

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

तुम्ही नुकतीच सुरू केलेली run यशस्वी झाल्याचे self-test log मध्ये Completed without error दिसले पाहिजे. Ubuntu आणि Debian मध्ये August 2026 पर्यंत अद्ययावत DEVICESCAN line असलेले /etc/smartd.conf उपलब्ध असते. त्यामुळे daemon त्याला दिसणाऱ्या प्रत्येक disk वर कार्य करते आणि बदल झाल्यावर root ला ईमेल पाठवते. Virtual disk वर यापैकी काहीही कार्य करत नाही. म्हणून या मार्गदर्शकाचा उर्वरित भाग आवश्यक आहे.

FAQ

smartctl माझ्या VPS वर का काम करत नाही?

कारण डिस्क आभासी आहे. virtio-blk वापरणाऱ्या KVM guest मध्ये smartctl -a /dev/vda हे /dev/vda: Unable to detect device type छापते, कारण paravirtual डिस्कमध्ये SMART विनंती पुढे पाठवण्यासाठी ATA किंवा SCSI command channel नसतो. Emulated डिस्कवर तुम्ही अशा device पर्यंत पोहोचता, ज्याचे model QEMU HARDDISK असे दर्शवते आणि त्यामागे वापरता येईल असा SMART data नसतो. Container मध्ये CAP_SYS_RAWIO नसल्यामुळे smartctl थेट नाकारले जाते. यापैकी कोणतीही बाब misconfiguration नाही आणि कोणताही -d flag ती दुरुस्त करू शकत नाही.

माझ्या VPS ची डिस्क निकामी होत आहे हे मला कसे कळेल?

Hardware पेक्षा त्याचे परिणाम monitor करा. sudo journalctl -k -p err -b मध्ये blk_update_request: I/O error lines आणि Remounting filesystem read-only तपासा. Logs मधून आधीच गमावलेले errors शोधण्यासाठी sudo dumpe2fs -h /dev/vda1 | grep -i 'error count' चालवा. गोष्टी व्यवस्थित असताना नोंदवलेल्या baseline शी iostat -xdz 5 मधील r_await ची तुलना करत राहा. VPS वरील I/O error चा अर्थ सहसा drive निकामी होत आहे असा नसून host storage समस्या असा असतो. त्यामुळे timestamp आणि sector जोडून support ticket उघडा.

VPS disk health साठी मी कोणत्या बाबींवर alert लावावे?

चार alerts पुरेसे आहेत. node_filesystem_readonly == 1 मुळे किंवा अयशस्वी write probe मुळे read-only mount होणे. Free space आणि free inodes शून्याकडे जाणे. मागील interval मध्ये आलेला कोणताही kernel I/O error. Server कडून येणारा heartbeat, ज्यामुळे box प्रतिसाद देणे थांबवल्यावर silence साठी page मिळेल. SMART वरून मिळवलेल्या कोणत्याही बाबींकडे दुर्लक्ष करा, कारण virtual disk वर ती values एकतर उपलब्ध नसतात किंवा hypervisor च्या emulation चे वर्णन करतात.

माझे filesystem read-only म्हणून पुन्हा mount का झाले?

errors=remount-ro सह mount केलेले ext4 metadata error आढळल्यावर हे जाणीवपूर्वक करते: नुकसान वाढवत पुढे लिहिण्याऐवजी ते writing थांबवते. Remount line च्या थोडे आधी kernel log मध्ये trigger आढळतो. underlying device ने I/O error परत दिल्यानंतर aborted journal बद्दलचा EXT4-fs error हा त्याचा नेहमीचा प्रकार असतो. Filesystem तपासल्याशिवाय read-write म्हणून remount केल्यास symptom लपतो आणि cause कायम राहतो. Log capture करा. त्यानंतर rescue mode मधून filesystem unmounted ठेवून e2fsck -fy /dev/vda1 वापरून तपासा.

Virtual server वर SMART data कधी वाचता येतो का?

काही विशिष्ट परिस्थितींमध्ये हो. Dedicated आणि bare metal servers वास्तविक attributes देतात. Physical disk guest कडे pass through करणारे storage plans आणि तुमच्या मालकीचे host देखील तसेच करतात. काही platforms guest कडे NVMe controller सादर करतात आणि nvme smart-log एक log परत करते. त्यामुळे प्रथम sudo nvme id-ctrl /dev/nvme0 चालवा: network storage service चे नाव असलेला model number म्हणजे ते counters software controller कडून आलेले आहेत. Shared machine वर passthrough node वास्तविक counters दाखवत असला, तरी ते इतर tenants सोबत shared असलेल्या hardware चे वर्णन करतात. त्यामुळे उपयुक्त एकमेव कृती म्हणजे support ticket उघडणे.