كيف تراقب صحة القرص على خادم VPS؟

ما الذي يمكن لمراقبة صحة القرص على خادم VPS رؤيته فعلياً

تبدأ مراقبة صحة القرص على خادم VPS بحقيقة يتجاهلها معظم الأدلة: القرص ليس ملكك. يرى نظامك الضيف جهاز كتلة افتراضياً (virtual block device). أما القرص المادي، وكل عدّاد مخزن عليه، فهو ملك للمضيف. لا يفشل smartctl /dev/vda لأنك كتبت الأمر بشكل خاطئ، بل يفشل لأن لا شيء خلف هذا الجهاز يمكنه الإجابة على الطلب.

تقنية SMART (تقنية المراقبة الذاتية والتحليل وإعداد التقارير) هي جدول من العدّادات المحفوظة على القرص نفسه: القطاعات المعاد تخصيصها، القطاعات المعلقة، ساعات التشغيل، وأخطاء الوسائط. قراءة هذا الجدول تتطلب مساراً لأوامر ATA أو NVMe (ذاكرة غير متطايرة سريعة) للوصول إلى العتاد الحقيقي. القرص شبه الافتراضي (paravirtual disk) لا يوفر هذا المسار، لذا يحصل الضيف على مساحة تخزين مجردة من بيانات القياس عن بُعد.

يراقب المستأجر الآثار، لا العتاد. هناك أربع إشارات مرئية من داخل الضيف: أخطاء الإدخال/الإخراج (I/O) في سجل النواة، نظام ملفات يعيد تحميل نفسه للقراءة فقط، زمن وصول يتزايد تدريجياً، ونفاد المساحة. يمكن إعداد تنبيهات لكل هذه الإشارات الأربع اليوم، وجميعها تظهر قبل أن يشتكي المستخدم. ابدأ بإعداد هذه التنبيهات أولاً. يأتي تقسيم المسؤولية في النهاية، لأنه يحدد أين يجب أن توجّه جهدك.

تحقق مما يكشفه خادمك

لا تفترض الحالة التي أنت فيها. افحص أولاً، ثم اقرأ القسم المطابق لحالتك.

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 (جهاز افتراضي قائم على النواة) المعتاد. الجهاز هو /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 بالطريقة نفسها، لأن المشكلة تكمن في وسيلة النقل وليس في العلم (flag) المستخدم.

قرص SATA أو SCSI محاكى. الجهاز هو /dev/sda ويصل smartctl إلى مرحلة كافية لتحديده. يظهر سطر الطراز كـ QEMU HARDDISK. هذا النص يجيب على سؤالك بنفسه: أنت تقرأ جهازاً ابتكره المحاكي، وهو لا يبلغ عن أي قدرة SMART قابلة للاستخدام.

نطاق NVMe (NVMe namespace). يُرجع sudo nvme smart-log /dev/nvme0n1 سجلاً كاملاً، وهو ما يخدع المستخدمين. تحقق من هوية وحدة التحكم (controller) أولاً باستخدام sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)'. إذا كان رقم الطراز يشير إلى منتج تخزين شبكي، فهذا يعني أن وحدة التحكم برمجية، وبالتالي يصف كل من percentage_used و media_errors هذا المحاكي بدلاً من ذاكرة الفلاش التي تخزن بياناتك. إذا أردت معرفة ماهية وحدة التخزين الخاصة بك فعلياً، تحقق من قرص NVMe على Linux بدلاً من الوثوق بوصف الخطة.

حاوية (Container)، مثل LXC (حاويات Linux) أو OpenVZ. أنت لا تملك جهاز تخزين (block device) خاصاً بك. يعرض lsblk أجهزة المضيف أو لا يعرض شيئاً على الإطلاق، ويتم رفض smartctl لأن الحاوية لا تملك CAP_SYS_RAWIO:

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

تحذير واحد حول الحالة التي يعمل فيها البرنامج. إذا أرجع smartctl على خادم VPS جدول سمات كاملاً، اقرأ الرقم التسلسلي قبل اتخاذ أي إجراء. بعض المضيفين يكشفون عن عقدة جهاز (device node) عبر التمرير المباشر (passthrough)، وتلك العدادات تخص أجهزة يتشاركها جميع المستأجرين على ذلك الخادم. ارتفاع قيمة Reallocated_Sector_Ct هناك يعني ضرورة فتح تذكرة دعم فني. إنه ليس مؤشراً على حالة بياناتك.

الإشارة 1: أخطاء الإدخال/الإخراج (I/O) في سجل النواة

تُعد هذه الإشارة ذات القيمة الأعلى للمستأجر، ولا تتطلب أي وكيل (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'

يبدو الطلب الفاشل من القرص الافتراضي كما يلي:

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

طلبت طبقة الكتل (block layer) من المضيف إجراء عملية كتابة، فأعاد المضيف خطأً. في خوادم VPS، نادراً ما يكون هذا بسبب تلف في خلايا الذاكرة الوميضية (flash cell). عادة ما يكون السبب هو طبقة التخزين في المضيف أو مسار الشبكة إلى وحدة التخزين المرتبطة بالشبكة، لذا فهو حدث يقع في جانب مزود الخدمة. انسخ الطابع الزمني، واسم الجهاز، والقطاع (sector) في تذكرتك، لأن فريق التخزين يحتاج هذه البيانات لمطابقتها مع سجلاتهم الخاصة.

تسلسل 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 الإقلاعة الحالية فقط ما لم يتم تخزين السجل (journal) على القرص، وتأتي العديد من صور الأنظمة بسجل متطاير يعيش في الذاكرة العشوائية (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 أكثر من إقلاعة واحدة. حتى مع تفعيل الاستمرارية، لا يمكن لنظام الملفات الذي تحول إلى وضع "القراءة فقط" تسجيل ما حدث لاحقاً، وهذا هو السبب المنطقي لإرسال السجلات إلى خارج الخادم.

الإشارة 2: رصد إعادة التثبيت للقراءة فقط

اجعل الفشل مسموعاً قبل محاولة اكتشافه.

findmnt -no SOURCE,FSTYPE,OPTIONS /

ابحث عن errors=remount-ro في الخيارات. تضبط صور Ubuntu وDebian السحابية هذا الخيار في /etc/fstab، لذا فإن أي خطأ في البيانات الوصفية يجعل نظام الملفات للقراءة فقط بدلاً من الاستمرار فوق التلف. إذا كان الخيار مفقوداً، أضفه إلى إدخال الجذر في /etc/fstab، أو اضبطه في الـsuperblock باستخدام sudo tune2fs -e remount-ro /dev/vda1. التوقف الصاخب أفضل من التلف الصامت.

علم التثبيت ليس دليلاً. اختبر عبر الكتابة:

touch /var/tmp/.disk-probe

على جذر للقراءة فقط، سيطبع هذا بالضبط:

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

استخدم /var/tmp، وليس /tmp. في معظم الصور، /tmp هو tmpfs موجود في الذاكرة، لذا فإن الكتابة الناجحة هناك لا تثبت شيئاً عن القرص الخاص بك.

اجمع اختبار الكتابة مع فحص المساحة، وأرسل نبضة قلب (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 في السطر الأخير أن السلسلة بأكملها تعمل. تجعل set -eu أي فحص فاشل يخرج بقيمة غير صفرية قبل تشغيل سطر curl، لذا لا يتم إرسال أي نبضة قلب. هذا الانعكاس هو الهدف: يتحول لون الشاشة إلى الأحمر لأن شيئاً لم يصل، والخادم الذي لا يمكنه الكتابة لا يمكن الوثوق به لوصف مشكلته الخاصة. لا تزال عمليات القراءة تعمل على نظام ملفات للقراءة فقط، لذا يبدأ البرنامج النصي نفسه.

شغّله من مؤقت 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 أقل من خمس دقائق. يظهر التشغيل الفاشل في journalctl -u disk-probe.service مع نص خطأ الصدفة (shell) نفسه، لذا يمكنك تمييز نظام ملفات للقراءة فقط عن نظام ممتلئ دون تسجيل الدخول.

رابط الدفع (push URL) هو مراقب دفع في Uptime Kuma. أنشئ مراقباً من نوع Push، وانسخ رمزه المميز (token) إلى البرنامج النصي، واضبط الفاصل الزمني لنبضات قلب المراقب ليكون أطول قليلاً من الفاصل الزمني للمؤقت حتى لا يزعجك تشغيل بطيء في الساعة 03:00. إذا لم يكن لديك صفحة حالة بعد، فإن مثيل Uptime Kuma ذاتي الاستضافة هو أرخص مكان لوضع هذا الفحص.

حدّان صادقان. يؤكد الاختبار أن الكتابة قُبلت، وليس أن البايتات وصلت إلى التخزين الدائم، لأن القراءة يمكن أن تتم من ذاكرة التخزين المؤقت للصفحات (page cache). كما أنه يعمل على الجهاز الذي يراقبه، لذا فإن الخادم المتوقف تماماً يصمت بدلاً من الإبلاغ عن تشخيص.

الإشارة 3: اتجاهات زمن الاستجابة والإنتاجية

sudo apt install -y sysstat
iostat -xdz 5 3

اقرأ r_await و w_await أولاً. تمثل هذه القيم متوسط الوقت بالملي ثانية الذي تستغرقه عملية القراءة أو الكتابة، بما في ذلك الوقت المستغرق في الانتظار ضمن طابور العمليات. بعد ذلك، راجع 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 ذاكرة التخزين المؤقت للصفحات (page cache) الخاصة بك. لكنه لا يتخطى ذاكرة التخزين المؤقت للمضيف، لذا تصف النتيجة المسار الكامل من عمليتك وصولاً إلى وحدة تخزين المنصة. شغّل هذا الاختبار بينما يكون الخادم في حالة خمول، لأنه يتنافس مع عبء العمل الخاص بك.

ارتفاع await دون وجود أخطاء في سجل النواة (kernel log) لا يعني عادةً تعطل القرص. بل هو تنافس على الموارد لدى المضيف، وهو ما يعادل في التخزين وقت سرقة المعالج من جار مزعج. إذا تكرر هذا الأمر في نفس الساعة يومياً وجاء رد الدعم الفني بأن النظام سليم، فالحل هو الانتقال إلى خطة لا تتشارك في مدخلات ومخرجات القرص (I/O) بنفس الطريقة، وهو ما ينطبق على خادم VPS مخصص للتخزين مقارنة بـ VPS عادي عندما يكون عبء العمل مقيداً بأداء القرص.

الإشارة 4: فحوصات نظام الملفات التي يمكنك تشغيلها أثناء التثبيت (Mount)

يحتفظ نظام ext4 بعدّاد أخطاء في الـ superblock، ويبقى هذا العدّاد محفوظاً بعد إعادة التشغيل حتى لو فُقدت سجلاتك.

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 وقيمة غير صفرية يعني أن النواة واجهت خطأ في البيانات الوصفية (metadata) في مرحلة ما، حتى لو لم يلحظ أحد ذلك وتم تدوير السجلات. هذا الأمر يستحق أن يكون جزءاً من فحصك الأسبوعي.

لا يمكنك تشغيل fsck على نظام ملفات الجذر (root) وهو مثبت، كما أن تشغيل 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 تعني وقوع حدث حقيقي، وتحتفظ العدادات بقيمها عبر عمليات إعادة التشغيل حتى تقوم بتصفيرها. يقوم scrub بإعادة قراءة كل كتلة (block) والتحقق من مجموعها الاختباري (checksum)، وهو أقرب شيء لاختبار الوسائط متاح على قرص افتراضي. هذا الإجراء يستهلك الكثير من عمليات الإدخال والإخراج (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 نفادها، فهذا يعني أنك استنفدت الـ inodes بدلاً من البايتات، ويظهر df -i أن IUse% ممتلئ بنسبة 100 بالمئة. تسبب ملايين الملفات الصغيرة في دليل التخزين المؤقت (cache) أو طابور البريد (mail spool) هذه المشكلة، ولن يساعدك حذف الملفات الكبيرة في حلها.

المساحة التي لا تعود بعد الحذف هي عادةً ملف محذوف لا يزال مفتوحاً بواسطة عملية قيد التشغيل. يسرد sudo lsof +L1 الملفات التي وصل عدد روابطها إلى صفر. إعادة تشغيل العملية التي تحتفظ بالملف ستؤدي إلى تحرير المساحة.

سجل النظام (journal) مستهلك صامت شائع للمساحة. يوضح journalctl --disk-usage حجم ما يشغله. حدد حجمه باستخدام SystemMaxUse=200M في ملف /etc/systemd/journald.conf متبوعاً بـ sudo systemctl restart systemd-journald، ثم استعد المساحة فوراً باستخدام sudo journalctl --vacuum-size=200M.

هناك حالة تبدو كخطأ برمجي لكنها ليست كذلك. في وحدات التخزين ذات التخصيص الرقيق (thin provisioned)، قد يمتلئ مجمع التخزين الخاص بالمضيف بينما لا يزال df الخاص بك يظهر وجود جيجابايتات حرة. عندها ستفشل عمليات الكتابة الخاصة بك مع ظهور أخطاء إدخال/إخراج (I/O errors) في سجل النواة (kernel log) دون أي تحذير بنفاد المساحة داخل النظام الضيف. ظهور أخطاء دون امتلاء نظام الملفات هو مزيج يستحق فتح تذكرة دعم في نفس الساعة.

ربط الإشارات بوكيل المقاييس

يجيب مسبار الدفع (push probe) بنعم أو لا. تتطلب الاتجاهات وكيل مقاييس، ويقوم node_exporter الخاص بـ Prometheus بتصدير كل ما سبق تلقائياً دون الحاجة لإعدادات إضافية. أسماء المقاييس التي يمكنك البناء عليها هي:

• ينتقل node_filesystem_readonly إلى 1 عندما يصبح نقطة التثبيت (mount) للقراءة فقط، وهو ما يمثل تنبيه إعادة التثبيت الخاص بك.
• يغطي كل من node_filesystem_avail_bytes و node_filesystem_files_free البايتات والـ inodes بشكل منفصل.
• يمنحك node_disk_io_time_seconds_total و node_disk_read_time_seconds_total وقت الانشغال وزمن الاستجابة كعدادات يمكنك رسمها بيانياً.

هناك قاعدتان تلتقطان الحالات التي تستدعي التنبيه فعلياً:

- 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، ويدير مصفوفة الأقراص، ويستبدل القرص الذي تظهر فيه قطاعات تالفة (reallocated sectors) متزايدة، وعادة ما يتم ذلك دون إبلاغك لأن المصفوفة تستوعب الفشل. هذا هو الغرض من مصفوفة RAID 10 في خادمك الافتراضي VPS؛ إذ يتحول القرص التالف إلى عملية إعادة بناء بدلاً من أن يصبح انقطاعاً في الخدمة. لا يمكنك رؤية أي من ذلك، ودفع تكاليف هذا التجريد هو الجزء الأكبر من الهدف وراء استئجار خادم افتراضي.

أنت تمتلك بياناتك، كما أن بيانات القياس عن بُعد للأقراص لن تحميها على أي حال. الأحداث التي تدمر بيانات المستأجر فعلياً هي تنفيذ أمر rm خاطئ، أو نشر سيئ (bad deploy)، أو متسلل يمتلك مفتاح SSH الخاص بك، أو حادث في المنصة يؤدي إلى فقدان المصفوفة بالكامل. لا تتنبأ سمات SMART بأي من هذه الأمور.

لذا، فإن الحماية الحقيقية للمستأجر هي نسخة احتياطية موجودة خارج الخادم وعملية استعادة قمت أنت بتنفيذها بنفسك. لقطات النظام (snapshots) التي يوفرها المزود مريحة، لكنها تقع على نفس المنصة التي تحميها، وهذا هو السبب في أن اللقطات والنسخ الاحتياطية توفر حمايات مختلفة. ضع جدولاً زمنياً للتدريب: مرة كل ربع سنة، استعد أحدث نسخة احتياطية في خادم VPS جديد، وشغّل التطبيق، وسجّل الوقت الذي استغرقته العملية. هذا الرقم هو وقت التعافي الحقيقي لديك. يكون التدريب الأول دائماً أبطأ مما توقعه أي شخص.

متى ينطبق عليك استخدام SMART

الأدلة التي تشرح smartctl صحيحة، وهي تنطبق في اللحظة التي تمتلك فيها العتاد فعلياً:

• خادم مخصص أو Bare Metal، حيث يعيد sudo smartctl -a /dev/sda جدول السمات كاملاً، ويمكن لـ smartd إرسال بريد إلكتروني إليك عند تغير أي سمة.
• خطط التخزين التي تمرر القرص الفيزيائي مباشرة إلى النظام الضيف (Guest). يوثق المزودون هذا الأمر صراحةً لأنه ميزة تسويقية.
• العتاد الذي تمتلكه، سواء في المنزل أو في مساحة خادم مستأجرة.
• قرص خلف وحدة تحكم RAID، يمكن الوصول إليه عبر sudo smartctl -a -d megaraid,0 /dev/sda، أو حاوية USB تدعم -d sat.

في أقراص 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). أي تحرك لهذه القيم بعيداً عن الصفر يعني أنه يجب عليك التخطيط لاستبدال القرص. تشير دراسات الأقراص واسعة النطاق باستمرار إلى هذه القائمة القصيرة، بينما تعتبر معظم السمات الأخرى مجرد ضجيج.

شغّل الـ daemon بدلاً من الفحص يدوياً.

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

يجب أن يظهر سجل الاختبار الذاتي Completed without error للعملية التي بدأتَها للتو. توفر توزيعتا Ubuntu و Debian برنامج /etc/smartd.conf مع سطر DEVICESCAN، وهو محدث حتى أغسطس 2026، بحيث يلتقط الـ daemon كل قرص يمكنه رؤيته ويرسل بريداً إلى root عند حدوث أي تغيير. لا يعمل أي من هذا على الأقراص الافتراضية، وهذا هو سبب وجود بقية هذا الدليل.

FAQ

لماذا لا تعمل أداة smartctl على خادمي الافتراضي (VPS)؟

لأن القرص افتراضي. على خادم KVM يستخدم virtio-blk، تطبع smartctl -a /dev/vda رسالة /dev/vda: Unable to detect device type، حيث إن القرص شبه الافتراضي لا يحمل قناة أوامر ATA أو SCSI لكي تنتقل عبرها طلبات SMART. على الأقراص المحاكية، أنت تصل إلى جهاز يقرأ طرازه QEMU HARDDISK، ولا توجد بيانات SMART قابلة للاستخدام خلفه. داخل الحاويات، يتم رفض smartctl مباشرة لعدم وجود CAP_SYS_RAWIO. لا يُعد أي من هذا خطأً في الإعداد، ولا يوجد أي خيار -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' للعثور على الأخطاء التي فقدتها السجلات بالفعل. تتبع r_await من iostat -xdz 5 مقارنةً بخط أساس سجلته عندما كان النظام سليماً. في الـ VPS، عادةً ما يعني خطأ الإدخال/الإخراج (I/O error) وجود مشكلة في تخزين المضيف وليس في قرص تالف، لذا يجب إدراج ذلك في تذكرة دعم مع إرفاق الطابع الزمني والقطاع (sector) المتضرر.

ما الذي يجب أن أضبط التنبيهات بشأنه بخصوص صحة قرص الـ VPS؟

تغطي أربعة تنبيهات هذا الأمر. التثبيت للقراءة فقط (read-only mount) من node_filesystem_readonly == 1 أو فشل اختبار الكتابة. المساحة الحرة وعدد الـ inodes الحرة التي تتجه نحو الصفر. أي I/O error في النواة خلال الفترة الزمنية الأخيرة. نبضات القلب (heartbeat) من الخادم، بحيث يتم تنبيهك عند الصمت إذا توقف الخادم عن الاستجابة. تجاهل أي شيء مشتق من SMART، لأن هذه القيم على القرص الافتراضي إما مفقودة أو تصف محاكاة الـ hypervisor.

لماذا أعاد نظام الملفات تثبيت نفسه للقراءة فقط؟

يقوم ext4 المثبت بـ errors=remount-ro بهذا الإجراء عمداً عند مواجهة خطأ في البيانات الوصفية (metadata): فهو يتوقف عن الكتابة بدلاً من الاستمرار فوق التلف. يظهر سبب التشغيل في سجل النواة مباشرة فوق سطر إعادة التثبيت، وعادة ما يكون EXT4-fs error حول سجل (journal) تم إجهاضه بعد أن أعاد الجهاز الأساسي خطأ إدخال/إخراج. إن إعادة التثبيت للقراءة والكتابة دون فحص نظام الملفات يخفي العرض ويبقي السبب. التقط السجل، ثم افحص نظام الملفات وهو غير مثبت (unmounted) من وضع الإنقاذ باستخدام e2fsck -fy /dev/vda1.

هل يمكنني قراءة بيانات SMART على خادم افتراضي في أي وقت؟

في حالات محددة، نعم. الخوادم المخصصة (Dedicated) و bare metal تمنحك سمات حقيقية. وكذلك خطط التخزين التي تمرر قرصاً فيزيائياً مباشرة إلى الضيف، وأي مضيف تمتلكه بنفسك. تقدم بعض المنصات وحدة تحكم NVMe للضيف وتعيد nvme smart-log سجلاً، لذا شغّل sudo nvme id-ctrl /dev/nvme0 أولاً: إذا كان رقم الطراز يشير إلى خدمة تخزين شبكي، فهذا يعني أن تلك العدادات تأتي من وحدة تحكم برمجية. وحيثما تكشف عقدة التمرير (passthrough) عن عدادات حقيقية على جهاز مشترك، فهي تصف عتاداً مشتركاً مع مستأجرين آخرين، لذا فإن الإجراء الوحيد المفيد هو فتح تذكرة دعم.