VPS पर डिस्क हेल्थ मॉनिटरिंग कैसे करें

VPS पर डिस्क हेल्थ मॉनिटरिंग वास्तव में क्या देख सकती है

VPS पर डिस्क हेल्थ मॉनिटरिंग एक ऐसे तथ्य से शुरू होती है जिसे अधिकांश गाइड नजरअंदाज कर देते हैं: डिस्क आपकी नहीं है। आपका guest एक virtual block device देखता है। भौतिक ड्राइव, और उस पर संग्रहीत प्रत्येक काउंटर, host का होता है। smartctl /dev/vda इसलिए विफल नहीं होता क्योंकि आपने कमांड गलत टाइप की है। यह इसलिए विफल होता है क्योंकि उस डिवाइस के पीछे कोई भी उस प्रश्न का उत्तर नहीं दे सकता।

SMART (self-monitoring, analysis and reporting technology) ड्राइव पर ही रखे गए काउंटरों की एक तालिका है: reallocated sectors, pending sectors, power-on hours, media errors। उस तालिका को पढ़ने के लिए ATA या NVMe (non-volatile memory express) कमांड्स को वास्तविक हार्डवेयर तक पहुँचने के लिए एक path की आवश्यकता होती है। एक paravirtual disk इसे प्रदान नहीं करती है, इसलिए guest को ऐसी स्टोरेज मिलती है जिससे टेलीमेट्री हटा दी गई है।

एक tenant हार्डवेयर को नहीं, बल्कि उसके प्रभावों को मॉनिटर करता है। guest के अंदर से चार संकेत दिखाई देते हैं: kernel log में I/O (input/output) errors, एक filesystem जो read-only मोड में remount हो जाती है, latency जो धीरे-धीरे बढ़ती है, और space जो खत्म हो जाता है। इन चारों के लिए आज ही अलर्ट सेट किए जा सकते हैं, और ये चारों संकेत उपयोगकर्ता की शिकायत से पहले ही दिखाई दे जाते हैं। सबसे पहले इन्हें सेट करें। जिम्मेदारी का विभाजन अंत में आता है, क्योंकि यह तय करता है कि आपको अपना प्रयास कहाँ केंद्रित करना चाहिए।

यह सिद्ध करें कि आपका अपना सर्वर क्या expose करता है

यह मानकर न चलें कि आप किस स्थिति में हैं। पहले देखें, फिर उस अनुभाग को पढ़ें जो आपकी स्थिति से मेल खाता है।

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 कमांड सेट नहीं होता, इसलिए SMART अनुरोध भेजने के लिए कोई चैनल नहीं है। -d sat और -d scsi भी उसी तरह विफल होते हैं, क्योंकि समस्या transport में है, न कि flag में।

एक emulated SATA या SCSI डिस्क। डिवाइस /dev/sda है और smartctl इसे पहचानने के लिए पर्याप्त जानकारी प्राप्त कर लेता है। मॉडल लाइन QEMU HARDDISK पढ़ती है। वह स्ट्रिंग स्वयं ही उत्तर दे देती है: आप एक ऐसे डिवाइस को पढ़ रहे हैं जिसे emulator ने बनाया है, और यह कोई उपयोगी SMART क्षमता रिपोर्ट नहीं करता है।

एक NVMe namespace। sudo nvme smart-log /dev/nvme0n1 एक पूर्ण लॉग लौटाता है, जहाँ लोग भ्रमित हो जाते हैं। पहले sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)' के साथ controller identity की जाँच करें। यदि मॉडल नंबर किसी network storage उत्पाद का नाम बताता है, तो इसका अर्थ है कि controller software है, इसलिए percentage_used और media_errors आपके डेटा के नीचे मौजूद flash के बजाय उस emulation का वर्णन करते हैं। यदि आप यह जानना चाहते हैं कि आपका storage वास्तव में क्या है, तो plan विवरण पर भरोसा करने के बजाय Linux पर NVMe डिस्क को सत्यापित करें।

एक container, जैसे LXC (Linux containers) या OpenVZ। आपके पास अपना कोई block device नहीं है। lsblk या तो host के डिवाइस दिखाता है या कुछ भी नहीं, और smartctl को अस्वीकार कर दिया जाता है क्योंकि container के पास CAP_SYS_RAWIO नहीं होता है:

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

उस स्थिति के बारे में एक चेतावनी जहाँ यह काम करता है। यदि VPS पर smartctl एक पूर्ण attribute table लौटाता है, तो उस पर कोई कार्रवाई करने से पहले serial number पढ़ें। कुछ hosts एक passthrough device node expose करते हैं, और वे counters उस hardware से संबंधित होते हैं जिसे उस मशीन पर हर tenant साझा करता है। वहाँ बढ़ता हुआ Reallocated_Sector_Ct एक support ticket का विषय है। यह आपके डेटा के बारे में कोई जानकारी नहीं देता है।

संकेत 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

ब्लॉक लेयर ने होस्ट से राइट (write) करने का अनुरोध किया और होस्ट ने विफलता का संदेश लौटाया। VPS पर यह शायद ही कभी खराब हो रही फ्लैश सेल होती है। यह आमतौर पर होस्ट स्टोरेज लेयर या नेटवर्क अटैच्ड स्टोरेज का नेटवर्क पाथ होता है, इसलिए यह प्रदाता (provider) की ओर से होने वाली घटना है। टाइमस्टैम्प, डिवाइस का नाम और सेक्टर को अपनी टिकट में कॉपी करें, क्योंकि स्टोरेज टीम इन्हीं के आधार पर अपने लॉग्स से मिलान कर सकती है।

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 फाइलसिस्टम को बंद (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

journalctl -k केवल वर्तमान बूट को पढ़ता है जब तक कि जर्नल डिस्क पर स्टोर न हो, और कई इमेजेस में एक वोलेटाइल जर्नल होता है जो RAM में रहता है। इसे परसिस्टेंट (persistence) बनाएं, अन्यथा समस्या निवारण के दौरान आपके द्वारा किए जाने वाले रीबूट पर ही साक्ष्य गायब हो जाएंगे।

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 को एक से अधिक बूट की सूची दिखानी चाहिए। परसिस्टेंट मोड चालू होने के बाद भी, जो फाइलसिस्टम रीड-ओनली (read-only) हो गया है, वह यह रिकॉर्ड नहीं कर सकता कि आगे क्या हुआ, जो कि लॉग्स को बॉक्स से बाहर भेजने का सबसे ठोस तर्क है।

Signal 2: read-only remount को पकड़ना

विफलता का पता लगाने से पहले उसे स्पष्ट रूप से सामने लाएं।

findmnt -no SOURCE,FSTYPE,OPTIONS /

Options में errors=remount-ro को देखें। Ubuntu और Debian के cloud images इसे /etc/fstab में सेट करते हैं, ताकि metadata error होने पर filesystem damage के बावजूद आगे बढ़ने के बजाय read-only हो जाए। यदि यह मौजूद नहीं है, तो इसे /etc/fstab में root entry में जोड़ें, या sudo tune2fs -e remount-ro /dev/vda1 के साथ superblock में सेट करें। चुपचाप corruption होने से बेहतर है कि सिस्टम स्पष्ट रूप से रुक जाए।

Mount flag प्रमाण नहीं है। लिखने का प्रयास करके जाँच करें:

touch /var/tmp/.disk-probe

Read-only root पर यह बिल्कुल यही प्रिंट करेगा:

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 पंक्ति के चलने से पहले non-zero exit देता है, इसलिए कोई heartbeat नहीं भेजी जाती। यह inversion ही मुख्य उद्देश्य है: monitor लाल हो जाता है क्योंकि कुछ भी प्राप्त नहीं हुआ, और जो सर्वर लिख नहीं सकता, उस पर अपनी समस्या बताने के लिए भरोसा नहीं किया जा सकता। Read-only filesystem पर reads अभी भी काम करते हैं, इसलिए 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 journalctl -u disk-probe.service में shell के अपने error text के साथ दिखाई देता है, इसलिए आप login किए बिना ही read-only filesystem और full filesystem के बीच अंतर बता सकते हैं।

वह push URL एक Uptime Kuma push monitor है। Push प्रकार का एक monitor बनाएं, उसका token script में copy करें, और monitor का heartbeat interval timer interval से थोड़ा अधिक रखें ताकि एक धीमी run आपको 03:00 बजे परेशान न करे। यदि आपके पास अभी तक status page नहीं है, तो एक self-hosted Uptime Kuma instance इस जाँच को रखने के लिए सबसे सस्ता स्थान है।

दो ईमानदार सीमाएं। यह probe पुष्टि करता है कि write स्वीकार किया गया था, न कि bytes durable storage तक पहुँचे, क्योंकि read back page cache से दिया जा सकता है। और यह उसी machine पर चलता है जिसकी यह निगरानी करता है, इसलिए पूरी तरह से wedged सर्वर निदान रिपोर्ट करने के बजाय चुप हो जाता है।

संकेत 3: लेटेंसी और थ्रूपुट के रुझान

sudo apt install -y sysstat
iostat -xdz 5 3

सबसे पहले r_await और w_await पढ़ें। ये एक रीड या राइट ऑपरेशन में लगने वाले औसत मिलीसेकंड हैं, जिसमें कतार (queue) में बिताया गया समय भी शामिल है। इसके बाद aqu-sz देखें, जो इन-फ्लाइट अनुरोधों की औसत संख्या है। वर्चुअल डिस्क पर %util को अनदेखा करें: इसका केवल यह अर्थ है कि कतार खाली नहीं थी, और जो डिवाइस समानांतर में कई अनुरोधों को पूरा करता है, वह अपनी सीमा के करीब न होने पर भी 100 प्रतिशत के आसपास रह सकता है। await वह संख्या है जो यह ट्रैक करती है कि उपयोगकर्ता क्या अनुभव कर रहे हैं।

निरपेक्ष मान (absolute values) आपके अपने बेसलाइन से कम महत्वपूर्ण हैं, इसलिए एक शांत घंटे का डेटा रिकॉर्ड करें और उसे सुरक्षित रखें। यदि आप स्वयं काउंटर एकत्र करना चाहते हैं, तो /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 आपके पेज कैश को छोड़ देता है। यह होस्ट के कैश को नहीं छोड़ता है, इसलिए परिणाम आपके प्रोसेस से लेकर प्लेटफॉर्म के स्टोरेज तक के पूरे पथ का वर्णन करता है। इसे तब चलाएं जब सर्वर आइडल (idle) हो, क्योंकि यह आपके अपने वर्कलोड के साथ प्रतिस्पर्धा करता है।

कर्नेल लॉग में बिना किसी त्रुटि के बढ़ता हुआ await आमतौर पर खराब होती ड्राइव नहीं है। यह होस्ट पर कंटेंशन (contention) है, जो noisy neighbour से CPU steal time का स्टोरेज संस्करण है। यदि यह हर दिन एक ही समय पर वापस आता है और आपकी टिकट का परिणाम सामान्य आता है, तो इसका समाधान एक ऐसा प्लान है जिसका I/O उसी तरह साझा नहीं किया जाता है, जो कि डिस्क-बाउंड वर्कलोड होने पर regular VPS के बजाय storage VPS के मामले में होता है।

Signal 4: filesystem checks जिन्हें आप mounted होने पर चला सकते हैं

ext4 अपने superblock में एक error counter रखता है, और यह reboot के बाद भी सुरक्षित रहता है, भले ही आपके logs न रहें।

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 का सामना करना पड़ा, भले ही किसी ने ध्यान न दिया हो और log हट चुके हों। यह एक command साप्ताहिक जाँच में शामिल होनी चाहिए।

आप mounted root filesystem पर fsck नहीं चला सकते, और live filesystem पर e2fsck -n केवल उन समस्याओं की रिपोर्ट करता है जो उसके नीचे बदलते डेटा के कारण होती हैं। वास्तविक जाँच करने के लिए, अपने provider के console से एक बार boot करने के लिए kernel command line में fsck.mode=force fsck.repair=yes जोड़ें। इसके बाद systemd-fsck root के read-write mount होने से पहले जाँच चलाता है।

XFS में कोई online check नहीं होता है। xfs_repair -n /dev/vda1 mounted filesystem पर चलने से मना कर देता है, इसलिए इसे rescue mode में चलाना चाहिए। XFS इसकी भरपाई अपनी स्पष्टता से करता है: यह metadata error होने पर filesystem को जारी रखने के बजाय बंद (shut down) कर देता है।

Btrfs पर counters पहले से मौजूद और persistent होते हैं।

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

write_io_errs या corruption_errs का शून्य से अधिक होना एक वास्तविक घटना है, और ये counters reboot के बाद भी अपनी values तब तक बनाए रखते हैं जब तक आप उन्हें reset न करें। scrub हर block को फिर से पढ़ता है और उसके checksum को verify करता है, जो virtual disk पर उपलब्ध media test के सबसे करीब है। यह I/O पर भारी पड़ता है, इसलिए इसे शांत घंटों के लिए schedule करें।

Signal 5: खाली स्थान, जिसमें वे हिस्से भी शामिल हैं जिन्हें df छिपा देता है

डिस्क खराब होने की तरह ही, स्पेस खत्म होने से भी सर्वर काम करना बंद कर देता है, और यह समस्या डिस्क खराब होने की तुलना में कहीं अधिक बार होती है।

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

No space left on device का उपयोग करते समय यदि df -h खाली स्थान दिखाता है, तो इसका मतलब है कि आपके बाइट्स के बजाय inodes खत्म हो गए हैं, और df -i में IUse% 100 प्रतिशत दिखाई देता है। कैश डायरेक्टरी या मेल स्पूल में लाखों छोटी फाइलें इसका कारण बनती हैं, और बड़ी फाइलों को डिलीट करने से कोई मदद नहीं मिलती।

डिलीट करने के बाद जो स्पेस वापस नहीं आता, वह आमतौर पर ऐसी डिलीट की गई फाइल होती है जिसे किसी चल रही प्रोसेस ने अभी भी ओपन रखा होता है। sudo lsof +L1 उन फाइलों को सूचीबद्ध करता है जिनकी लिंक काउंट शून्य हो गई है। उस प्रोसेस को रीस्टार्ट करने से जो फाइल को होल्ड किए हुए है, स्पेस रिलीज हो जाता है।

जर्नल अक्सर चुपचाप स्पेस का उपयोग करता है। journalctl --disk-usage रिपोर्ट करता है कि यह कितना स्पेस ले रहा है। इसे /etc/systemd/journald.conf में SystemMaxUse=200M के साथ सीमित करें, उसके बाद sudo systemctl restart systemd-journald चलाएं, और sudo journalctl --vacuum-size=200M के साथ अभी स्पेस को पुनः प्राप्त करें।

एक स्थिति ऐसी होती है जो बग जैसी लगती है लेकिन वह बग नहीं है। थिन प्रोविजन्ड (thin provisioned) होस्ट स्टोरेज पर, होस्ट का पूल भर सकता है जबकि आपका df अभी भी खाली गीगाबाइट दिखा रहा होता है। ऐसी स्थिति में आपके राइट ऑपरेशंस कर्नल लॉग में I/O एरर के साथ विफल हो जाते हैं और गेस्ट के अंदर कहीं भी स्पेस की चेतावनी नहीं मिलती। यदि फाइलसिस्टम भरा हुआ न हो और फिर भी एरर आए, तो यह एक ऐसी समस्या है जिसके लिए उसी घंटे टिकट रेज करना चाहिए।

Metrics agent में सिग्नल्स को जोड़ना

एक push probe केवल हाँ या ना में उत्तर देता है। रुझानों (trends) के विश्लेषण के लिए एक metrics agent की आवश्यकता होती है, और Prometheus node_exporter बिना किसी अतिरिक्त कॉन्फ़िगरेशन के ऊपर दी गई सभी जानकारी पहले से ही एक्सपोर्ट करता है। जिन metric names का उपयोग करना है:

• node_filesystem_readonly का मान 1 हो जाता है जब कोई mount read-only हो जाता है, जो कि आपके remount अलार्म का आधार है।
• 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 के रूप में देते हैं, जिन्हें आप ग्राफ कर सकते हैं।

दो नियम उन स्थितियों को पकड़ते हैं जो वास्तव में पेजिंग (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

दूसरा नियम तब सक्रिय होता है जब वर्तमान रुझान चार दिनों के भीतर शून्य तक पहुँच जाता है। इससे आपको 95 प्रतिशत भर जाने पर मिलने वाली मिनटों की चेतावनी के बजाय, कई दिन पहले ही अलर्ट मिल जाता है।

किसकी क्या जिम्मेदारी है

आपका प्रदाता फिजिकल ड्राइव्स का मालिक होता है। वे SMART डेटा पढ़ते हैं, ऐरे (array) चलाते हैं, और बढ़ते हुए reallocated sectors वाली ड्राइव को बदल देते हैं। वे आमतौर पर आपको इसकी सूचना नहीं देते, क्योंकि ऐरे उस विफलता को संभाल लेता है। यही कारण है कि RAID 10 under your VPS का उपयोग किया जाता है: एक खराब ड्राइव का मतलब सिस्टम बंद होने के बजाय केवल रीबिल्ड (rebuild) प्रक्रिया है। आप इनमें से कुछ भी नहीं देख सकते, और इसी एब्स्ट्रैक्शन (abstraction) के लिए भुगतान करना वर्चुअल सर्वर किराए पर लेने का मुख्य उद्देश्य है।

आप अपने डेटा के मालिक हैं, और ड्राइव टेलीमेट्री वैसे भी इसकी सुरक्षा नहीं करेगी। जो घटनाएं वास्तव में टेनेंट (tenant) के डेटा को नष्ट करती हैं, वे हैं: गलती से की गई rm, खराब डिप्लॉयमेंट, आपके SSH key के साथ कोई घुसपैठिया, और कोई ऐसा प्लेटफॉर्म इंसिडेंट जो पूरे ऐरे को ही ले डूबे। SMART एट्रिब्यूट्स इनमें से किसी का भी पूर्वानुमान नहीं लगा सकते।

इसलिए, एक टेनेंट की वास्तविक सुरक्षा वह बैकअप है जो सर्वर से बाहर रहता है और जिसे आपने स्वयं रिस्टोर करके देखा है। प्रदाता के स्नैपशॉट सुविधाजनक होते हैं, लेकिन वे उसी प्लेटफॉर्म पर स्थित होते हैं जिसकी वे सुरक्षा कर रहे हैं, इसीलिए snapshots and backups are different protections। अपने कैलेंडर में एक ड्रिल सेट करें: हर तिमाही में, नवीनतम बैकअप को एक नए VPS में रिस्टोर करें, एप्लिकेशन शुरू करें, और नोट करें कि इसमें कितना समय लगा। वह संख्या ही आपका वास्तविक रिकवरी समय है। पहली ड्रिल हमेशा किसी के भी अनुमान से धीमी होती है।

SMART आपके लिए कब लागू होता है

जो गाइड्स smartctl सिखाती हैं, वे सही हैं और वे उस क्षण लागू होती हैं जब हार्डवेयर वास्तव में आपका होता है:

• एक dedicated या bare metal सर्वर, जहाँ sudo smartctl -a /dev/sda पूरी attribute table दिखाता है और smartd किसी attribute के बदलने पर आपको मेल भेज सकता है।
• स्टोरेज प्लान जो एक physical disk को guest तक pass करते हैं। प्रदाता इसे स्पष्ट रूप से document करते हैं, क्योंकि यह एक selling point है।
• वह हार्डवेयर जो आपका अपना है, घर पर या किराए पर ली गई रैक स्पेस में।
• RAID controller के पीछे की डिस्क, जो 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 सीधे ड्राइव से critical_warning और percentage_used की रिपोर्ट करते हैं। असली SATA पर, विफलता की भविष्यवाणी करने वाले attributes Reallocated_Sector_Ct (5), Current_Pending_Sector (197), Offline_Uncorrectable (198) और Reported_Uncorrect (187) हैं। इनमें से किसी के भी शून्य से ऊपर जाने का मतलब है कि replacement की योजना बनाएँ। बड़े पैमाने पर किए गए ड्राइव अध्ययन बार-बार उसी छोटी सूची पर आते हैं, और बाकी अधिकांश attributes केवल शोर (noise) हैं।

मैन्युअल रूप से जाँच करने के बजाय daemon को चलाएँ।

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

Self-test log में आपके द्वारा अभी शुरू किए गए रन के लिए Completed without error दिखना चाहिए। Ubuntu और Debian में /etc/smartd.conf के साथ एक DEVICESCAN लाइन होती है, जो अगस्त 2026 तक अद्यतित है, इसलिए daemon हर उस डिस्क को चुन लेता है जिसे वह देख सकता है और बदलाव होने पर root को मेल भेज देता है। इनमें से कुछ भी virtual disk पर काम नहीं करता है, और यही कारण है कि इस गाइड का बाकी हिस्सा मौजूद है।

FAQ

मेरे VPS पर smartctl काम क्यों नहीं करता है?

क्योंकि डिस्क वर्चुअल है। virtio-blk का उपयोग करने वाले KVM guest पर, smartctl -a /dev/vda कमांड /dev/vda: Unable to detect device type प्रिंट करता है, क्योंकि एक paravirtual डिस्क में SMART अनुरोध भेजने के लिए कोई ATA या SCSI कमांड चैनल नहीं होता है। एक एमुलेटेड डिस्क पर आप ऐसे डिवाइस तक पहुँचते हैं जिसका मॉडल QEMU HARDDISK दिखाता है, जिसके पीछे कोई उपयोगी SMART डेटा नहीं होता है। कंटेनर के अंदर, CAP_SYS_RAWIO की कमी के कारण smartctl को सीधे मना कर दिया जाता है। इनमें से कोई भी गलत कॉन्फ़िगरेशन नहीं है, और कोई भी -d फ्लैग इसे ठीक नहीं कर सकता है।

मुझे कैसे पता चलेगा कि मेरी VPS डिस्क खराब हो रही है?

हार्डवेयर के बजाय प्रभावों पर ध्यान दें। blk_update_request: I/O error लाइनों और Remounting filesystem read-only के लिए sudo journalctl -k -p err -b की जाँच करें। उन त्रुटियों को खोजने के लिए sudo dumpe2fs -h /dev/vda1 | grep -i 'error count' चलाएँ जिन्हें लॉग्स ने पहले ही खो दिया है। जब सिस्टम सही स्थिति में था, तब रिकॉर्ड किए गए बेसलाइन के मुकाबले iostat -xdz 5 से r_await को ट्रैक करें। VPS पर I/O त्रुटि का मतलब आमतौर पर खराब होती ड्राइव के बजाय होस्ट स्टोरेज की समस्या होती है, इसलिए इसे टाइमस्टैम्प और सेक्टर के साथ सपोर्ट टिकट में दर्ज किया जाना चाहिए।

मुझे VPS डिस्क हेल्थ के लिए किन चीजों पर अलर्ट सेट करना चाहिए?

चार अलर्ट इसे कवर करते हैं। node_filesystem_readonly == 1 से रीड-ओनली माउंट, या कोई राइट प्रोब जो विफल हो जाता है। खाली जगह और खाली inodes का शून्य की ओर बढ़ना। पिछले अंतराल में कोई भी कर्नेल I/O error। सर्वर से एक हार्टबीट, ताकि जब बॉक्स जवाब देना बंद कर दे तो आपको अलर्ट मिल सके। SMART से प्राप्त किसी भी चीज़ को छोड़ दें, क्योंकि वर्चुअल डिस्क पर वे मान या तो गायब होते हैं या हाइपरवाइजर के एमुलेशन का वर्णन करते हैं।

मेरा फाइलसिस्टम रीड-ओनली क्यों रीमाउंट हो गया?

errors=remount-ro के साथ माउंट किया गया ext4 मेटाडेटा त्रुटि आने पर जानबूझकर ऐसा करता है: यह नुकसान को और बढ़ाने के बजाय लिखना बंद कर देता है। इसका कारण रीमाउंट लाइन के ठीक ऊपर कर्नेल लॉग में होता है, आमतौर पर अंतर्निहित डिवाइस द्वारा I/O त्रुटि लौटाने के बाद जर्नल के निरस्त होने के बारे में एक EXT4-fs error। फाइलसिस्टम की जाँच किए बिना रीड-राइट रीमाउंट करना केवल लक्षण को छिपाता है और कारण बना रहता है। लॉग कैप्चर करें, फिर रेस्क्यू मोड से अनमाउंट करके e2fsck -fy /dev/vda1 के साथ फाइलसिस्टम की जाँच करें।

क्या मैं कभी वर्चुअल सर्वर पर SMART डेटा पढ़ सकता हूँ?

विशिष्ट मामलों में, हाँ। डेडिकेटेड और बेयर मेटल सर्वर आपको वास्तविक एट्रिब्यूट्स देते हैं। स्टोरेज प्लान जो फिजिकल डिस्क को सीधे गेस्ट तक पहुँचाते हैं, और कोई भी होस्ट जिसे आप स्वयं नियंत्रित करते हैं, वे भी ऐसा कर सकते हैं। कुछ प्लेटफॉर्म गेस्ट को NVMe कंट्रोलर प्रदान करते हैं और nvme smart-log एक लॉग लौटाता है, इसलिए पहले sudo nvme id-ctrl /dev/nvme0 चलाएँ: यदि मॉडल नंबर में किसी नेटवर्क स्टोरेज सर्विस का नाम है, तो इसका मतलब है कि वे काउंटर एक सॉफ्टवेयर कंट्रोलर से आते हैं। और जहाँ एक पासथ्रू नोड किसी साझा मशीन पर वास्तविक काउंटर दिखाता है, वे अन्य किरायेदारों के साथ साझा किए गए हार्डवेयर का वर्णन करते हैं, इसलिए एकमात्र उपयोगी कार्रवाई सपोर्ट टिकट बनाना है।