مانیتورینگ سلامت دیسک در VPS و محدودیت‌های SMART

آنچه مانیتورینگ سلامت دیسک در یک VPS واقعاً می‌تواند ببیند

مانیتورینگ سلامت دیسک در یک VPS با حقیقتی شروع می‌شود که اکثر راهنماها از آن اجتناب می‌کنند: دیسک متعلق به شما نیست. سیستم‌عامل مهمان شما یک block device مجازی را می‌بیند. درایو فیزیکی و تمام شمارنده‌های ذخیره‌شده روی آن، متعلق به میزبان (host) است. دستور smartctl /dev/vda به این دلیل که شما آن را اشتباه تایپ کرده‌اید با شکست مواجه نمی‌شود؛ بلکه به این دلیل شکست می‌خورد که هیچ‌چیز در پشت آن دستگاه نمی‌تواند به این پرسش پاسخ دهد.

تکنولوژی SMART (تکنولوژی خود-نظارتی، تحلیل و گزارش‌دهی) جدولی از شمارنده‌هاست که روی خود درایو نگهداری می‌شود: بخش‌های تخصیص‌یافته مجدد (reallocated sectors)، بخش‌های در انتظار (pending sectors)، ساعات روشن بودن و خطاهای رسانه. خواندن این جدول نیازمند مسیری برای دستورات ATA یا NVMe (حافظه غیرفرار اکسپرس) است تا به سخت‌افزار واقعی برسند. یک دیسک paravirtual چنین مسیری را فراهم نمی‌کند، بنابراین سیستم‌عامل مهمان، فضای ذخیره‌سازی را بدون تله‌متری دریافت می‌کند.

یک مستأجر (tenant) اثرات را مانیتور می‌کند، نه سخت‌افزار را. چهار سیگنال از داخل سیستم‌عامل مهمان قابل مشاهده هستند: خطاهای I/O (ورودی/خروجی) در لاگ هسته (kernel log)، فایل‌سیستمی که به حالت read-only بازنشانی (remount) می‌شود، تأخیری (latency) که به‌تدریج افزایش می‌یابد و فضایی که تمام می‌شود. برای هر چهار مورد می‌توان از امروز هشدار تنظیم کرد و هر چهار مورد پیش از آنکه کاربری شکایتی مطرح کند، نمایان می‌شوند. ابتدا این موارد را تنظیم کنید. تقسیم مسئولیت در انتها قرار می‌گیرد، زیرا تعیین می‌کند که باید انرژی خود را کجا صرف کنید.

اثبات آنچه سرور شما در معرض دید قرار می‌دهد

فرض نکنید در کدام وضعیت هستید. ابتدا بررسی کنید، سپس بخشی را که با وضعیت شما مطابقت دارد بخوانید.

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 یک انتقال نیمه‌مجازی (paravirtual) است که هیچ مجموعه دستور ATA یا SCSI در پشت خود ندارد، بنابراین کانالی برای انتقال درخواست SMART وجود ندارد. -d sat و -d scsi به همان دلیل شکست می‌خورند، زیرا مشکل از نوع انتقال است و نه پرچم (flag) مورد استفاده.

یک دیسک SATA یا SCSI شبیه‌سازی‌شده. دستگاه /dev/sda است و smartctl تا حدی پیش می‌رود که آن را شناسایی کند. خط مدل، QEMU HARDDISK را نشان می‌دهد. آن رشته به‌تنهایی به پرسش شما پاسخ می‌دهد: شما در حال خواندن دستگاهی هستید که شبیه‌ساز آن را ابداع کرده است و هیچ قابلیت SMART قابل‌استفاده‌ای را گزارش نمی‌کند.

یک فضای نام (namespace) NVMe. دستور sudo nvme smart-log /dev/nvme0n1 یک لاگ کامل برمی‌گرداند، که همین موضوع باعث گمراهی کاربران می‌شود. ابتدا هویت کنترلر را با sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)' بررسی کنید. شماره مدلی که نام یک محصول ذخیره‌سازی تحت شبکه را دارد، به این معناست که کنترلر نرم‌افزاری است، بنابراین percentage_used و media_errors آن شبیه‌سازی را توصیف می‌کنند، نه حافظه فلشی که داده‌های شما روی آن قرار دارد. اگر می‌خواهید بدانید ذخیره‌سازی شما واقعاً چیست، به‌جای اعتماد به توضیحات طرح، دیسک NVMe را در لینوکس تایید کنید.

یک کانتینر، مانند LXC (کانتینرهای لینوکس) یا OpenVZ. شما هیچ دستگاه بلوک (block device) اختصاصی ندارید. دستور lsblk دستگاه‌های میزبان را نشان می‌دهد یا اصلاً چیزی نمایش نمی‌دهد، و smartctl رد می‌شود زیرا کانتینر دسترسی به CAP_SYS_RAWIO ندارد:

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

یک هشدار در مورد حالتی که دستور کار می‌کند. اگر smartctl در یک VPS یک جدول ویژگی کامل برگرداند، پیش از هر اقدامی شماره سریال را بخوانید. برخی میزبان‌ها یک گره دستگاه passthrough را در معرض دید قرار می‌دهند و آن شمارنده‌ها متعلق به سخت‌افزاری است که بین تمام مستاجران آن ماشین مشترک است. افزایش Reallocated_Sector_Ct در آنجا، یک تیکت پشتیبانی است. این موضوع ارتباطی به وضعیت داده‌های شما ندارد.

سیگنال 1: خطاهای I/O در لاگ هسته

این ارزشمندترین سیگنالی است که یک مستأجر (tenant) در اختیار دارد و نیازی به هیچ عاملی (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، این به‌ندرت به معنای خرابی یک سلول حافظه فلش است. این معمولاً مربوط به لایه ذخیره‌سازی میزبان یا مسیر شبکه به سمت حافظه متصل به شبکه (NAS) است، بنابراین یک رویداد سمت ارائه‌دهنده (provider) محسوب می‌شود. برچسب زمانی (timestamp)، نام دستگاه و سکتور را در تیکت خود کپی کنید، زیرا این‌ها مواردی هستند که تیم ذخیره‌سازی می‌تواند با لاگ‌های خود مطابقت دهد.

دنباله 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 فقط بوت فعلی را می‌خواند مگر اینکه journal روی دیسک ذخیره شده باشد، و بسیاری از ایمیج‌ها یک journal ناپایدار (volatile) دارند که در 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) شده است، نمی‌تواند اتفاقات بعدی را ثبت کند، که این دلیل منطقی برای ارسال لاگ‌ها به خارج از سرور است.

سیگنال 2: شناسایی remount شدن به حالت read-only

پیش از آنکه سعی کنید خرابی را تشخیص دهید، کاری کنید که شکست با صدای بلند اعلام شود.

findmnt -no SOURCE,FSTYPE,OPTIONS /

به دنبال errors=remount-ro در گزینه‌ها بگردید. ایمیج‌های ابری Ubuntu و Debian این گزینه را در /etc/fstab تنظیم می‌کنند، بنابراین در صورت بروز خطای متادیتا، فایل‌سیستم به‌جای ادامه کار روی داده‌های آسیب‌دیده، به حالت read-only در می‌آید. اگر این گزینه وجود ندارد، آن را به ورودی root در /etc/fstab اضافه کنید یا با استفاده از sudo tune2fs -e remount-ro /dev/vda1 در superblock تنظیم نمایید. توقف پرصدا بهتر از خرابی خاموش است.

یک mount flag به تنهایی مدرک نیست. با نوشتن، آن را تست کنید:

touch /var/tmp/.disk-probe

روی یک روت read-only، خروجی دقیقاً به این صورت خواهد بود:

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 با کد خروجی غیر صفر متوقف شود، بنابراین هیچ heartbeat ارسال نمی‌شود. هدف از این وارونگی همین است: مانیتور قرمز می‌شود چون چیزی دریافت نشده است و سروری که نمی‌تواند بنویسد، قابل اعتماد نیست که بتواند مشکل خود را گزارش کند. عملیات خواندن روی فایل‌سیستم read-only همچنان کار می‌کند، بنابراین خود اسکریپت اجرا می‌شود.

آن را با یک 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 کمتر از 5 دقیقه نشان دهد. اجرای ناموفق در journalctl -u disk-probe.service با متن خطای خودِ shell ظاهر می‌شود، بنابراین می‌توانید بدون لاگین کردن، تفاوت فایل‌سیستم read-only را از فایل‌سیستم پر تشخیص دهید.

آن URL ارسال (push)، یک مانیتور Push در Uptime Kuma است. یک مانیتور از نوع Push بسازید، توکن آن را در اسکریپت کپی کنید و بازه زمانی heartbeat مانیتور را کمی طولانی‌تر از بازه زمانی timer تنظیم کنید تا یک اجرای کند، شما را ساعت 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 عددی است که تجربه کاربران را نشان می‌دهد.

مقادیر مطلق اهمیت کمتری نسبت به خط مبنای (baseline) اختصاصی شما دارند؛ بنابراین یک ساعت خلوت را ثبت کرده و آن را نگه دارید. اگر ترجیح می‌دهید شمارنده‌ها را خودتان جمع‌آوری کنید، /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 (99th) را بخوانید. --direct=1 از کش صفحه (page cache) شما عبور می‌کند. این دستور از کش میزبان (host) عبور نمی‌کند، بنابراین نتیجه، کل مسیر از پردازش شما تا فضای ذخیره‌سازی پلتفرم را توصیف می‌کند. این دستور را زمانی اجرا کنید که سرور بیکار است، زیرا با بار کاری خودتان رقابت می‌کند.

افزایش await بدون وجود خطا در لاگ هسته (kernel log)، معمولاً به معنای خرابی درایو نیست. این وضعیت ناشی از رقابت بر سر منابع در میزبان است؛ نسخه ذخیره‌سازیِ زمان CPU گرفته‌شده توسط همسایه پرمصرف. اگر این مشکل هر روز در ساعت مشخصی تکرار می‌شود و تیکت پشتیبانی شما نتیجه‌ای در بر ندارد، راه‌حل، استفاده از طرحی است که I/O آن به اشتراک گذاشته نمی‌شود؛ این همان تفاوت یک VPS ذخیره‌سازی نسبت به یک VPS معمولی در زمانی است که بار کاری محدود به دیسک (disk bound) است.

نشانه 4: بررسی‌های سیستم‌فایل که می‌توانید هنگام mount بودن اجرا کنید

سیستم‌فایل ext4 یک شمارنده خطا در superblock نگه می‌دارد که حتی پس از reboot، زمانی که لاگ‌های شما پاک شده‌اند، باقی می‌ماند.

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 و هر عددی غیر از صفر به این معناست که هسته (kernel) در مقطعی با خطای metadata مواجه شده است، حتی اگر کسی متوجه آن نشده باشد و لاگ‌ها چرخش (roll) کرده باشند. این دستور باید در چک‌لیست‌های هفتگی قرار گیرد.

شما نمی‌توانید روی سیستم‌فایل root که mount شده است fsck اجرا کنید و اجرای e2fsck -n روی یک سیستم‌فایل فعال، مشکلاتی را گزارش می‌کند که صرفاً ناشی از تغییر داده‌ها در حین اجراست. برای اجبار به یک بررسی واقعی، پارامتر fsck.mode=force fsck.repair=yes را به خط فرمان هسته (kernel command line) برای یک بار boot از طریق کنسول ارائه‌دهنده سرور خود اضافه کنید. در این حالت، systemd-fsck پیش از آنکه root به صورت read-write mount شود، بررسی را انجام می‌دهد.

سیستم‌فایل XFS بررسی آنلاین ندارد. دستور xfs_repair -n /dev/vda1 از اجرا روی سیستم‌فایل mount شده خودداری می‌کند، بنابراین باید در حالت rescue mode اجرا شود. XFS این محدودیت را با حساسیت بالا جبران می‌کند: در صورت بروز خطای metadata، سیستم‌فایل را به جای ادامه کار، متوقف (shutdown) می‌کند.

در Btrfs شمارنده‌ها داخلی و ماندگار هستند.

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

مقادیر بالای صفر در write_io_errs یا corruption_errs نشان‌دهنده یک رویداد واقعی است و این شمارنده‌ها مقادیر خود را تا زمانی که آن‌ها را reset نکنید، در طول rebootها حفظ می‌کنند. دستور scrub تمام بلوک‌ها را مجدداً می‌خواند و checksum آن‌ها را تایید می‌کند که نزدیک‌ترین معادل به تست رسانه (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 فضای آزاد را نشان می‌دهد، به این معناست که شما با کمبود inode مواجه شده‌اید نه بایت، و df -i مقدار IUse% را 100 درصد نشان می‌دهد. میلیون‌ها فایل کوچک در یک دایرکتوری کش یا صف ایمیل باعث این وضعیت می‌شوند و حذف فایل‌های حجیم کمکی به حل آن نمی‌کند.

فضایی که پس از حذف فایل‌ها آزاد نمی‌شود، معمولاً مربوط به فایلی است که حذف شده اما همچنان توسط یک پردازش در حال اجرا باز نگه داشته شده است. دستور sudo lsof +L1 فایل‌هایی را فهرست می‌کند که شمارنده لینک آن‌ها به صفر رسیده است. راه‌اندازی مجدد پردازشی که فایل را باز نگه داشته، فضا را آزاد می‌کند.

ژورنال سیستم یکی از مصرف‌کنندگان بی‌سروصدای فضا است. دستور journalctl --disk-usage میزان فضای اشغال‌شده توسط آن را گزارش می‌دهد. با استفاده از SystemMaxUse=200M در فایل /etc/systemd/journald.conf و سپس اجرای sudo systemctl restart systemd-journald، سقف آن را محدود کنید و با دستور sudo journalctl --vacuum-size=200M فضا را بلافاصله بازیابی کنید.

یک مورد وجود دارد که شبیه به باگ است اما نیست. در فضای ذخیره‌سازی thin provisioned، ممکن است pool میزبان پر شود در حالی که df شما همچنان گیگابایت‌های آزاد را نشان می‌دهد. در این حالت، عملیات نوشتن شما با خطاهای I/O در لاگ کرنل مواجه می‌شود بدون اینکه هیچ هشدار کمبود فضایی در داخل سیستم‌عامل مهمان (guest) دریافت کنید. بروز خطا بدون پر شدن فایل‌سیستم، ترکیبی است که باید در همان ساعت اول برای آن تیکت پشتیبانی ثبت شود.

اتصال سیگنال‌ها به یک agent متریک

یک probe از نوع push فقط پاسخ بله یا خیر می‌دهد. برای تحلیل روندها به یک agent متریک نیاز دارید و node_exporter در Prometheus تمامی موارد بالا را بدون نیاز به پیکربندی اضافی صادر می‌کند. نام متریک‌هایی که باید بر اساس آن‌ها کار کنید:

• node_filesystem_readonly زمانی که یک mount به حالت read-only در می‌آید برابر با 1 می‌شود که همان هشدار remount شماست.
• node_filesystem_avail_bytes و node_filesystem_files_free به ترتیب بایت‌ها و inodeها را پوشش می‌دهند.
• node_disk_io_time_seconds_total و node_disk_read_time_seconds_total زمان مشغول بودن (busy time) و تأخیر (latency) را به عنوان شمارنده (counter) در اختیار شما می‌گذارند تا بتوانید آن‌ها را نمودار کنید.

دو قانون، مواردی را که واقعاً نیاز به هشدار فوری (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 روز به صفر برسد؛ بنابراین به‌جای رسیدن به 95 درصد ظرفیت که تنها چند دقیقه فرصت دارید، چندین روز زودتر هشدار دریافت خواهید کرد.

مسئولیت هر بخش با کیست

ارائه‌دهندهٔ خدمات شما مالک درایوهای فیزیکی است. آن‌ها وضعیت SMART را پایش می‌کنند، آرایه را مدیریت می‌کنند و درایوی که سکتورهای جایگزین‌شده (reallocated sectors) آن رو به افزایش است را تعویض می‌کنند؛ معمولاً هم بدون اطلاع به شما، زیرا آرایه این خرابی را پوشش می‌دهد. هدف از RAID 10 در VPS شما دقیقاً همین است: درایو ازکارافتاده به جای ایجاد قطعی، بازسازی می‌شود. شما هیچ‌کدام از این فرآیندها را نمی‌بینید و پرداخت هزینه برای این انتزاع، بخش بزرگی از دلیل اجارهٔ یک سرور مجازی است.

شما مالک داده‌های خود هستید و تله‌متری درایو در هر صورت از آن‌ها محافظت نمی‌کند. رویدادهایی که واقعاً داده‌های مستأجر را نابود می‌کنند عبارتند از: یک دستور rm اشتباه، یک استقرار (deploy) معیوب، نفوذگری که به کلید SSH شما دسترسی دارد، و یک حادثه در پلتفرم که کل آرایه را از بین می‌برد. ویژگی‌های SMART هیچ‌کدام از این موارد را پیش‌بینی نمی‌کنند.

بنابراین، محافظت واقعی برای یک مستأجر، داشتن نسخه‌ای پشتیبان است که خارج از سرور نگهداری شود و فرآیند بازیابی‌ای که خودتان شخصاً انجام داده باشید. اسنپ‌شات‌های ارائه‌دهنده راحت هستند، اما روی همان پلتفرمی قرار دارند که از آن محافظت می‌کنند؛ به همین دلیل است که اسنپ‌شات‌ها و پشتیبان‌ها محافظت‌های متفاوتی هستند. در تقویم خود یک تمرین دوره‌ای ثبت کنید: هر سه ماه یک‌بار، جدیدترین نسخهٔ پشتیبان را در یک 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

لاگ self-test باید برای اجرایی که به‌تازگی شروع کرده‌اید، Completed without error را نشان دهد. توزیع‌های Ubuntu و Debian، بسته /etc/smartd.conf را با یک خط DEVICESCAN ارائه می‌دهند که تا اوت 2026 به‌روز است؛ بنابراین daemon هر دیسکی را که ببیند شناسایی کرده و در صورت تغییر، به root ایمیل می‌زند. هیچ‌کدام از این موارد روی دیسک مجازی کار نمی‌کنند، و به همین دلیل است که ادامه این راهنما وجود دارد.

FAQ

چرا smartctl روی VPS من کار نمی‌کند؟

زیرا دیسک مجازی است. در یک KVM guest که از virtio-blk استفاده می‌کند، smartctl -a /dev/vda خروجی /dev/vda: Unable to detect device type را چاپ می‌کند، چرا که یک دیسک paravirtual فاقد کانال دستور ATA یا SCSI برای ارسال درخواست SMART است. روی یک دیسک شبیه‌سازی‌شده، شما به دستگاهی دسترسی دارید که مدل آن QEMU HARDDISK خوانده می‌شود و هیچ داده SMART قابل‌استفاده‌ای پشت آن نیست. داخل یک container، اجرای 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 معمولاً به معنای مشکل در فضای ذخیره‌سازی میزبان (host) است تا خرابی یک درایو؛ بنابراین باید با ذکر timestamp و سکتور مربوطه، در قالب یک تیکت پشتیبانی ارسال شود.

برای سلامت دیسک VPS باید روی چه مواردی هشدار (alert) تنظیم کنم؟

چهار هشدار این موضوع را پوشش می‌دهند: یک mount با دسترسی فقط‌خواندنی (read-only) که از طریق node_filesystem_readonly == 1 یا یک تست نوشتن (write probe) که با شکست مواجه شده شناسایی می‌شود. فضای خالی و inodeهای خالی که به سمت صفر میل می‌کنند. هرگونه I/O error در کرنل در بازه زمانی اخیر. یک heartbeat از سرور، تا در صورت عدم پاسخگویی دستگاه، سکوت آن به شما اطلاع داده شود. هر چیزی که از SMART مشتق شده را نادیده بگیرید، زیرا در یک دیسک مجازی این مقادیر یا وجود ندارند یا صرفاً شبیه‌سازی hypervisor را توصیف می‌کنند.

چرا فایل‌سیستم من به حالت read-only بازگردانی (remount) شد؟

ext4 که با errors=remount-ro مونت شده است، هنگام برخورد با خطای متادیتا عمداً این کار را انجام می‌دهد: به جای ادامه دادن روی داده‌های آسیب‌دیده، نوشتن را متوقف می‌کند. عامل محرک در لاگ کرنل درست بالای خط remount قرار دارد؛ معمولاً یک EXT4-fs error درباره ژورنال متوقف‌شده پس از آنکه دستگاه زیرین خطای I/O بازگردانده است. بازگردانی به حالت read-write بدون بررسی فایل‌سیستم، فقط نشانه را پنهان می‌کند و علت اصلی باقی می‌ماند. لاگ را ضبط کنید، سپس فایل‌سیستم را در حالت unmounted از طریق rescue mode با e2fsck -fy /dev/vda1 بررسی کنید.

آیا می‌توانم در یک سرور مجازی داده‌های SMART را بخوانم؟

در موارد خاص، بله. سرورهای اختصاصی (Dedicated) و bare metal ویژگی‌های واقعی را به شما می‌دهند. همچنین طرح‌های ذخیره‌سازی که یک دیسک فیزیکی را مستقیماً به guest پاس می‌دهند (passthrough) و هر میزبانی که خودتان مالک آن هستید. برخی پلتفرم‌ها یک کنترلر NVMe به guest ارائه می‌دهند و nvme smart-log یک لاگ برمی‌گرداند؛ بنابراین ابتدا sudo nvme id-ctrl /dev/nvme0 را اجرا کنید: اگر شماره مدل نام یک سرویس ذخیره‌سازی شبکه باشد، یعنی آن شمارنده‌ها از یک کنترلر نرم‌افزاری می‌آیند. و در جایی که یک گره passthrough شمارنده‌های واقعی را روی یک ماشین اشتراکی نمایش می‌دهد، آن‌ها سخت‌افزاری را توصیف می‌کنند که با سایر مستاجران مشترک است، بنابراین تنها اقدام مفید، ارسال تیکت پشتیبانی است.