VPS پر ڈسک کی صحت کیسے مانیٹر کریں؟

VPS پر ڈسک کی صحت کی نگرانی حقیقت میں کیا دیکھ سکتی ہے

VPS پر ڈسک کی صحت کی نگرانی ایک ایسی حقیقت سے شروع ہوتی ہے جس سے زیادہ تر رہنما اجتناب کرتے ہیں: ڈسک آپ کی ملکیت نہیں ہے۔ آپ کا guest ایک virtual block device دیکھتا ہے۔ physical drive اور اس میں محفوظ ہر counter host کی ملکیت ہوتا ہے۔ smartctl /dev/vda اس لیے fail نہیں ہوتا کہ آپ نے command غلط لکھی ہے۔ یہ اس لیے fail ہوتا ہے کہ اس device کے پیچھے موجود کوئی چیز اس سوال کا جواب نہیں دے سکتی۔

SMART (self-monitoring, analysis and reporting technology) counters کی ایک table ہے جو خود drive پر محفوظ ہوتی ہے: reallocated sectors، pending sectors، power-on hours اور media errors۔ اس table کو پڑھنے کے لیے ATA یا NVMe (non-volatile memory express) commands کو حقیقی hardware تک پہنچانے والا path درکار ہوتا ہے۔ paravirtual disk ایسا path فراہم نہیں کرتی، اس لیے guest کو وہ storage ملتی ہے جس سے telemetry ہٹا دی گئی ہوتی ہے۔

tenant hardware کے بجائے اس کے اثرات monitor کرتا ہے۔ guest کے اندر سے چار signals نظر آتے ہیں: kernel log میں I/O (input/output) errors، ایسا filesystem جو read-only کے طور پر دوبارہ mount ہو جائے، بڑھتی ہوئی latency، اور ختم ہوتی ہوئی space۔ ان چاروں پر آج ہی alerts قائم کیے جا سکتے ہیں، اور user کی شکایت سے پہلے یہ چاروں ظاہر ہو جاتے ہیں۔ پہلے انہیں configure کریں۔ ذمہ داری کی تقسیم آخر میں آتی ہے، کیونکہ اس سے طے ہوتا ہے کہ آپ کو اپنی کوشش کہاں صرف کرنی چاہیے۔

اپنا سرور کیا expose کرتا ہے، اس کی تصدیق کریں

یہ فرض نہ کریں کہ آپ کی صورتِ حال کون سی ہے۔ پہلے معائنہ کریں، پھر اس صورتِ حال سے متعلق section پڑھیں۔

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) disk ہے۔ device /dev/vda ہے اور smartctl کوئی request بھیجنے سے پہلے رک جاتا ہے:

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

virtio-blk ایک paravirtual transport ہے جس کے پیچھے ATA یا SCSI command set موجود نہیں ہوتا، اس لیے SMART request منتقل کرنے کا کوئی channel نہیں ہوتا۔ -d sat اور -d scsi بھی اسی طرح fail ہوتے ہیں، کیونکہ مسئلہ transport میں ہے، flag میں نہیں۔

Emulated SATA یا SCSI disk۔ device /dev/sda ہے اور smartctl اتنا آگے پہنچ جاتا ہے کہ device کی شناخت کر سکے۔ model line میں QEMU HARDDISK درج ہوتا ہے۔ یہ string خود ہی سوال کا جواب دیتی ہے: آپ وہ device پڑھ رہے ہیں جسے emulator نے بنایا ہے، اور یہ usable SMART capability رپورٹ نہیں کرتا۔

NVMe namespace۔ sudo nvme smart-log /dev/nvme0n1 مکمل log واپس کرتا ہے، اور یہی وہ مقام ہے جہاں لوگ غلط فہمی کا شکار ہوتے ہیں۔ پہلے sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)' سے controller identity چیک کریں۔ اگر model number کسی network storage product کا نام بتاتا ہے تو controller software پر مبنی ہے۔ اس صورت میں percentage_used اور media_errors آپ کے data کے نیچے موجود flash کے بجائے اسی emulation کی وضاحت کرتے ہیں۔ اگر آپ جاننا چاہتے ہیں کہ آپ کی storage حقیقت میں کیا ہے تو plan description پر بھروسا کرنے کے بجائے Linux پر NVMe disk کی تصدیق کریں۔

Container، جیسے LXC (Linux containers) یا OpenVZ۔ آپ کے پاس اپنا کوئی block device نہیں ہوتا۔ lsblk host کے devices دکھاتا ہے یا کچھ بھی نہیں دکھاتا، اور 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 سے متعلق ہوتے ہیں جسے اس machine کے تمام tenants share کرتے ہیں۔ وہاں Reallocated_Sector_Ct کا بڑھنا support ticket کا معاملہ ہے۔ یہ آپ کے data کے بارے میں کوئی بیان نہیں ہے۔

کرنل لاگ میں 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 ہوتا ہے۔ اپنے ticket میں timestamp، device name اور sector شامل کریں، کیونکہ storage team اپنے logs میں انہی معلومات سے واقعے کا matching کر سکتی ہے۔

اہم 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 ناکام ہوتی ہے۔ عام 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

journalctl -k صرف موجودہ boot کے logs پڑھتا ہے، جب تک journal disk پر محفوظ نہ ہو۔ بہت سی images volatile journal استعمال کرتی ہیں، جو RAM میں رہتا ہے۔ 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 کو ایک سے زیادہ boots دکھانے چاہییں۔ persistence فعال ہونے کے باوجود read-only ہو جانے والا filesystem اس کے بعد ہونے والے واقعات record نہیں کر سکتا۔ یہی وجہ ہے کہ logs کو machine سے باہر بھیجنا ضروری ہے۔

سگنل 2: read-only remount کا پتا لگانا

اس کا پتا لگانے سے پہلے failure کو نمایاں بنائیں۔

findmnt -no SOURCE,FSTYPE,OPTIONS /

options میں errors=remount-ro تلاش کریں۔ Ubuntu اور Debian cloud images اسے /etc/fstab میں set کرتی ہیں، اس لیے metadata error کی صورت میں filesystem نقصان کے باوجود کام جاری رکھنے کے بجائے read-only ہو جاتا ہے۔ اگر یہ موجود نہ ہو تو /etc/fstab میں root entry میں اسے شامل کریں، یا sudo tune2fs -e remount-ro /dev/vda1 سے superblock میں set کریں۔ خاموش 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-based tmpfs ہوتا ہے، اس لیے وہاں کامیاب write آپ کی disk کے بارے میں کچھ ثابت نہیں کرتی۔

write test کو space check کے ساتھ یکجا کریں، اور heartbeat صرف اس وقت بھیجیں جب ہر check کامیاب ہو:

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 کسی بھی failed check پر non-zero کے ساتھ exit کر دیتا ہے، اس لیے curl line چلنے سے پہلے heartbeat نہیں بھیجا جاتا۔ یہی الٹ منطق اس کا مقصد ہے: کیونکہ کچھ موصول نہیں ہوا، monitor red ہو جاتا ہے، اور جو server لکھ نہیں سکتا اس پر اپنی خرابی کی درست اطلاع دینے کے لیے اعتماد نہیں کیا جا سکتا۔ read-only filesystem پر reads بدستور کام کرتے ہیں، اس لیے script خود start ہو جاتی ہے۔

اسے 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 type کا monitor بنائیں، اس کا token script میں copy کریں، اور monitor کا heartbeat interval timer interval سے کچھ زیادہ رکھیں تاکہ ایک سست run آپ کو 03:00 بجے page نہ کرے۔ اگر ابھی status page موجود نہیں ہے تو self-hosted Uptime Kuma instance یہ check رکھنے کے لیے کم ترین لاگت والی جگہ ہے۔

دو اہم حدود ہیں۔ probe اس بات کی تصدیق کرتا ہے کہ write قبول ہوئی، لیکن یہ نہیں کہ bytes durable storage تک پہنچ گئے، کیونکہ read back page cache سے فراہم کیا جا سکتا ہے۔ مزید یہ کہ یہ اسی machine پر چلتا ہے جس کی نگرانی کرتا ہے، اس لیے مکمل طور پر معطل server diagnosis بھیجنے کے بجائے خاموش ہو جاتا ہے۔

سگنل 3: تاخیر اور throughput کے رجحانات

sudo apt install -y sysstat
iostat -xdz 5 3

پہلے r_await اور w_await دیکھیں۔ یہ اوسط milliseconds ہیں جو کسی read یا write کو مکمل ہونے میں لگے، جس میں queue میں انتظار کا وقت بھی شامل ہے۔ اس کے بعد aqu-sz دیکھیں، جو in-flight requests کی اوسط تعداد ہے۔ virtual disk پر %util کو نظرانداز کریں: اس کا مطلب صرف یہ ہے کہ queue خالی نہیں تھی۔ جو device متعدد requests کو متوازی طور پر پورا کرتا ہے، وہ اپنی حد سے بہت دور ہوتے ہوئے بھی تقریباً 100 percent پر رہ سکتا ہے۔ await وہ عدد ہے جو صارفین کے محسوس کردہ performance کو ظاہر کرتا ہے۔

Absolute values کی نسبت آپ کا اپنا baseline زیادہ اہم ہے، اس لیے ایک پُرسکون گھنٹے کے اعداد record کریں اور محفوظ رکھیں۔ اگر آپ counters خود collect کرنا چاہیں تو /proc/diskstats raw source ہے۔

جان بوجھ کر measurement کرنے کے لیے:

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 کو bypass کرتا ہے۔ یہ host کے cache کو bypass نہیں کرتا، اس لیے نتیجہ آپ کے process سے platform کے storage تک پورے راستے کی عکاسی کرتا ہے۔ اسے اس وقت چلائیں جب server idle ہو، کیونکہ یہ آپ کے اپنے workload کے ساتھ resources کے لیے مقابلہ کرتا ہے۔

Kernel log میں errors کے بغیر await کا بڑھنا عموماً failing drive کی علامت نہیں ہوتا۔ یہ host پر contention ہوتا ہے؛ storage کے لیے وہی صورتِ حال جو مصروف پڑوسی کی وجہ سے CPU steal time میں ہوتی ہے۔ اگر یہ ہر روز اسی گھنٹے میں دوبارہ ظاہر ہو اور آپ کا ticket معمول کے مطابق close ہو جائے، تو حل ایسا plan ہے جس میں I/O اسی طرح shared نہ ہو۔ Disk-bound workload کی صورت میں یہ regular VPS کے مقابلے میں storage VPS کا معاملہ ہوتا ہے۔

mounted حالت میں چلائے جانے والے filesystem checks

ext4 اپنے superblock میں error counter برقرار رکھتا ہے، اور یہ reboots کے بعد بھی موجود رہتا ہے، چاہے آپ کے 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 اور non-zero count کا مطلب ہے کہ kernel کو کسی مرحلے پر metadata error ملا، چاہے کسی نے اسے محسوس نہ کیا ہو اور log roll ہو چکا ہو۔ یہ ایک command ہفتہ وار check میں شامل ہونی چاہیے۔

آپ mounted root filesystem پر fsck نہیں چلا سکتے، اور live filesystem پر e2fsck -n چلانے سے ایسے مسائل رپورٹ ہوتے ہیں جو صرف اس لیے نظر آتے ہیں کہ data اسی وقت تبدیل ہو رہا ہوتا ہے۔ حقیقی check کرانے کے لیے ایک boot کے دوران اپنے provider کے console سے kernel command line میں fsck.mode=force fsck.repair=yes شامل کریں۔ اس کے بعد systemd-fsck، root کو read-write mount کرنے سے پہلے check چلاتا ہے۔

XFS کے لیے online check موجود نہیں ہے۔ xfs_repair -n /dev/vda1 mounted filesystem کے خلاف چلنے سے انکار کرتا ہے، اس لیے اسے rescue mode میں چلائیں۔ XFS اس کے بدلے مسئلے کو واضح طور پر ظاہر کرتا ہے: metadata error ملنے پر filesystem کو بند کر دیتا ہے، بجائے اس کے کہ کام جاری رکھے۔

Btrfs میں counters built in اور 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 کریں۔

خلا کا اشارہ 5: free space، بشمول وہ حصے جو df چھپا دیتا ہے

Space ختم ہونے سے سرور اسی طرح متاثر ہوتا ہے جیسے خراب disk سے، اور یہ کہیں زیادہ عام ہے۔

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

No space left on device جبکہ df -h یہ دکھاتا ہے کہ free space موجود ہے، اس کا مطلب ہے کہ bytes کے بجائے inodes ختم ہو گئے ہیں، اور df -i یہ دکھاتا ہے کہ IUse% 100 percent پر ہے۔ Cache directory یا mail spool میں موجود لاکھوں چھوٹی files اس مسئلے کا سبب بنتی ہیں، اور بڑی files حذف کرنے سے مسئلہ حل نہیں ہوتا۔

Delete کرنے کے بعد واپس نہ آنے والی space عموماً ایسی deleted file کی ہوتی ہے جسے running process نے ابھی open رکھا ہوا ہے۔ sudo lsof +L1 ان files کی فہرست دیتا ہے جن کا link count صفر ہو چکا ہے۔ جس process نے ایسی file کھول رکھی ہو، اسے restart کرنے سے space آزاد ہو جاتی ہے۔

Journal خاموشی سے space استعمال کرنے والا ایک عام جزو ہے۔ journalctl --disk-usage بتاتا ہے کہ یہ کتنی space استعمال کر رہا ہے۔ /etc/systemd/journald.conf میں SystemMaxUse=200M کے ذریعے اس کی حد مقرر کریں، پھر sudo systemctl restart systemd-journald کے بعد sudo journalctl --vacuum-size=200M سے ابھی space واپس حاصل کریں۔

ایک صورت bug جیسی دکھائی دیتی ہے، لیکن bug نہیں ہوتی۔ Thin-provisioned host storage میں host کا pool بھر سکتا ہے، جبکہ آپ کا df اب بھی کئی gigabytes free دکھاتا ہے۔ اس کے بعد آپ کی writes kernel log میں I/O errors کے ساتھ fail ہوتی ہیں، اور guest کے اندر کہیں بھی space ختم ہونے کی warning نہیں آتی۔ Full filesystem کے بغیر errors ایک ایسا مجموعہ ہے جس کے لیے اسی گھنٹے ticket بنانا چاہیے۔

signals کو metrics agent تک پہنچانا

Push probe صرف ہاں یا نہیں کا جواب دیتا ہے۔ رجحانات کے لیے metrics agent درکار ہوتا ہے، اور Prometheus node_exporter بغیر کسی اضافی configuration کے اوپر بیان کردہ تمام metrics پہلے ہی export کرتا ہے۔ جن metric names کو بنیاد بنانا ہے:

• node_filesystem_readonly اس وقت 1 ہو جاتا ہے جب mount read-only ہو، اور یہی آپ کا 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 کے طور پر فراہم کرتے ہیں، جنہیں آپ graph میں دکھا سکتے ہیں۔

درج ذیل دو rules ان صورتوں کو پکڑتے ہیں جن پر واقعی 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

دوسرا rule اس وقت fire ہوتا ہے جب موجودہ رجحان چار دن کے اندر zero تک پہنچنے کا اندازہ ہو۔ اس طرح آپ کو 95 percent full ہونے کے وقت alert ملنے کے بجائے کئی دن پہلے warning مل جاتی ہے، جب عموماً صرف چند minutes باقی ہوتے ہیں۔

کس کی کیا ذمہ داری ہے

آپ کا provider physical drives کا مالک ہوتا ہے۔ وہ SMART پڑھتا ہے، array چلاتا ہے، اور rising reallocated sectors والی drive تبدیل کرتا ہے۔ عموماً وہ آپ کو اطلاع نہیں دیتا، کیونکہ array failure کو absorb کر لیتا ہے۔ آپ کے VPS کے تحت RAID 10 کا مقصد یہی ہے: dead drive outage کے بجائے rebuild کا سبب بنتی ہے۔ آپ اس میں سے کچھ بھی نہیں دیکھ سکتے، اور virtual server کرائے پر لینے کی abstraction کی اصل قدر بھی یہی ہے۔

آپ اپنے data کے ذمہ دار ہیں، اور drive telemetry بہرحال آپ کے data کو محفوظ نہیں رکھتی۔ وہ واقعات جو tenant data کو حقیقتاً تباہ کرتے ہیں، ان میں ایک غلط rm، خراب deploy، آپ کی SSH key رکھنے والا intruder، اور platform incident شامل ہیں جو array کو بھی متاثر کر دے۔ SMART attributes ان میں سے کسی کی پیش گوئی نہیں کرتیں۔

اس لیے tenant کا حقیقی تحفظ ایسی backup ہے جو server سے باہر موجود ہو، اور ایسا restore ہے جسے آپ نے خود انجام دیا ہو۔ Provider snapshots سہولت فراہم کرتے ہیں، لیکن وہ اسی platform پر موجود ہوتے ہیں جس چیز کی حفاظت کر رہے ہوتے ہیں۔ اسی لیے snapshots اور backups مختلف تحفظات ہیں۔ Calendar میں drill مقرر کریں: ہر quarter میں newest backup کو ایک fresh VPS پر restore کریں، application شروع کریں، اور لکھیں کہ اس میں کتنا وقت لگا۔ یہی عدد آپ کا حقیقی recovery time ہے۔ پہلی drill ہمیشہ اندازے سے زیادہ وقت لیتی ہے۔

جب SMART کا اطلاق آپ پر ہوتا ہے

smartctl سکھانے والی رہنما دستاویزات درست ہیں، اور جیسے ہی hardware واقعی آپ کی ملکیت ہو، ان کا اطلاق ہو جاتا ہے:

• Dedicated یا bare metal server، جہاں sudo smartctl -a /dev/sda مکمل attribute table واپس کرتا ہے اور smartd کسی attribute میں تبدیلی ہونے پر آپ کو email بھیج سکتا ہے۔
• ایسے storage plans جو guest کو physical disk براہِ راست فراہم کرتے ہیں۔ Providers اس بات کو واضح طور پر document کرتے ہیں، کیونکہ یہ ان کی فروخت کا ایک اہم نکتہ ہے۔
• وہ hardware جو آپ کے پاس گھر میں ہو یا آپ کے کرائے کے 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 پر failure کی پیش گوئی کرنے والے attributes Reallocated_Sector_Ct (5)، Current_Pending_Sector (197)، Offline_Uncorrectable (198) اور Reported_Uncorrect (187) ہیں۔ ان میں سے کسی کی value صفر سے بڑھ جائے تو replacement کی منصوبہ بندی کریں۔ بڑے پیمانے پر کی جانے والی drive studies بار بار اسی مختصر فہرست تک پہنچتی ہیں، اور زیادہ تر دوسرے attributes قابلِ اعتماد اشارے نہیں ہوتے۔

ہاتھ سے جانچنے کے بجائے daemon چلائیں۔

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

Self-test log میں اس run کے لیے Completed without error دکھائی دینا چاہیے جو آپ نے ابھی شروع کیا ہے۔ Ubuntu اور Debian، /etc/smartd.conf کو DEVICESCAN line کے ساتھ ship کرتے ہیں، جو August 2026 تک موجودہ ہے۔ اس لیے daemon ہر وہ disk اٹھا لیتا ہے جسے وہ دیکھ سکتا ہے، اور کسی تبدیلی کی صورت میں root کو email بھیجتا ہے۔ Virtual disk پر ان میں سے کوئی چیز کام نہیں کرتی، اسی لیے اس guide کا باقی حصہ موجود ہے۔

FAQ

smartctl میرے VPS پر کیوں کام نہیں کرتا؟

کیونکہ disk virtual ہے۔ virtio-blk استعمال کرنے والے KVM guest میں smartctl -a /dev/vda، /dev/vda: Unable to detect device type دکھاتا ہے، کیونکہ paravirtual disk میں SMART request کے لیے ATA یا SCSI command channel موجود نہیں ہوتا۔ emulated disk پر آپ ایسے device تک پہنچتے ہیں جس کا model QEMU HARDDISK دکھاتا ہے، اور اس کے پیچھے قابلِ استعمال SMART data نہیں ہوتا۔ container کے اندر CAP_SYS_RAWIO نہ ہونے کی وجہ سے smartctl کو براہِ راست مسترد کر دیا جاتا ہے۔ ان میں سے کوئی بھی configuration کی خرابی نہیں، اور کوئی -d flag انہیں درست نہیں کرتا۔

مجھے کیسے معلوم ہو کہ میرے VPS کی disk خراب ہو رہی ہے؟

hardware کے بجائے اس کے اثرات monitor کریں۔ sudo journalctl -k -p err -b میں blk_update_request: I/O error lines اور Remounting filesystem read-only دیکھیں۔ sudo dumpe2fs -h /dev/vda1 | grep -i 'error count' چلائیں تاکہ وہ errors مل سکیں جو logs پہلے ہی کھو چکے ہیں۔ r_await کو iostat -xdz 5 سے track کریں اور اس baseline سے موازنہ کریں جو نظام کے درست حالت میں ہونے پر record کیا گیا تھا۔ VPS پر I/O error عموماً host storage problem کی نشاندہی کرتا ہے، نہ کہ drive کے خراب ہونے کی؛ اس لیے timestamp اور sector کے ساتھ اسے support ticket میں شامل کریں۔

VPS disk health کے لیے کن چیزوں پر alert لگانا چاہیے؟

چار alerts کافی ہیں۔ Read-only mount، خواہ وہ node_filesystem_readonly == 1 سے بنا ہو یا ناکام ہونے والے write probe سے۔ Free space اور free inodes کا صفر کی طرف بڑھنا۔ آخری interval میں کوئی بھی kernel I/O error۔ Server کی heartbeat، تاکہ server جواب دینا بند کرے تو silence آپ کو page کر دے۔ SMART سے حاصل کردہ کسی بھی value کو نظرانداز کریں، کیونکہ virtual disk پر یہ values یا تو موجود نہیں ہوتیں یا hypervisor کی emulation کو بیان کرتی ہیں۔

میری filesystem read-only پر remount کیوں ہوئی؟

errors=remount-ro کے ساتھ mounted ext4 metadata error ملنے پر یہ عمل جان بوجھ کر کرتی ہے: نقصان کے باوجود writing جاری رکھنے کے بجائے writing روک دیتی ہے۔ Trigger kernel log میں remount line سے عین اوپر ہوتا ہے، عموماً underlying device کے I/O error واپس کرنے کے بعد aborted journal کے بارے میں ایک EXT4-fs error۔ Filesystem کی جانچ کیے بغیر اسے read-write پر remount کرنے سے symptom چھپ جاتا ہے اور cause برقرار رہتا ہے۔ Log محفوظ کریں، پھر rescue mode سے filesystem کو unmounted حالت میں e2fsck -fy /dev/vda1 کے ذریعے check کریں۔

کیا virtual server پر کبھی SMART data پڑھا جا سکتا ہے؟

مخصوص حالات میں، ہاں۔ Dedicated اور bare metal servers آپ کو حقیقی attributes دیتے ہیں۔ وہ storage plans بھی ایسا کرتے ہیں جو physical disk کو guest کے ذریعے براہِ راست استعمال کرنے دیتے ہیں، اور ہر وہ host بھی جس کی ملکیت خود آپ کے پاس ہو۔ کچھ platforms guest کو NVMe controller فراہم کرتے ہیں اور nvme smart-log ایک log واپس کرتا ہے، اس لیے پہلے sudo nvme id-ctrl /dev/nvme0 چلائیں: اگر model number کسی network storage service کا نام ہو تو یہ counters software controller سے آ رہے ہیں۔ اسی طرح اگر shared machine پر passthrough node حقیقی counters فراہم بھی کرے، تو وہ دوسرے tenants کے ساتھ مشترکہ hardware کو بیان کرتے ہیں؛ اس لیے واحد مفید اقدام support ticket بنانا ہے۔