Cara pantau kesihatan cakera pada VPS

Apa yang sebenarnya boleh dilihat oleh pemantauan kesihatan cakera pada VPS

Pemantauan kesihatan cakera pada VPS bermula dengan satu fakta yang sering dielakkan oleh kebanyakan panduan: cakera tersebut bukan milik anda. Tetamu (guest) anda hanya melihat peranti blok maya. Pemacu fizikal, dan setiap pembilang yang disimpan di dalamnya, adalah milik hos. smartctl /dev/vda tidak gagal kerana anda tersalah taip arahan. Ia gagal kerana tiada apa-apa di sebalik peranti tersebut yang boleh menjawab pertanyaan itu.

SMART (self-monitoring, analysis and reporting technology) ialah jadual pembilang yang disimpan pada pemacu itu sendiri: sektor yang diperuntukkan semula (reallocated sectors), sektor tertangguh (pending sectors), jam kuasa dihidupkan (power-on hours), dan ralat media. Membaca jadual tersebut memerlukan laluan untuk arahan ATA atau NVMe (non-volatile memory express) sampai ke perkakasan sebenar. Cakera paravirtual tidak menyediakan laluan ini, jadi tetamu menerima storan dengan telemetri yang telah dibuang.

Penyewa memantau kesan, bukan perkakasan. Empat isyarat boleh dilihat dari dalam tetamu: ralat I/O (input/output) dalam log kernel, sistem fail yang dipasang semula (remount) sebagai baca-sahaja (read-only), kependaman (latency) yang meningkat secara beransur-ansur, dan ruang storan yang kehabisan. Keempat-empat isyarat ini boleh diberi amaran hari ini, dan kesemuanya muncul sebelum pengguna membuat aduan. Sediakan pemantauan untuk perkara tersebut terlebih dahulu. Pembahagian tanggungjawab datang pada akhirnya, kerana ia menentukan di mana anda harus menumpukan usaha.

Buktikan apa yang didedahkan oleh pelayan anda sendiri

Jangan buat andaian tentang situasi anda. Periksa dahulu, kemudian baca bahagian yang sepadan.

sudo apt update && sudo apt install -y smartmontools nvme-cli
lsblk -o NAME,TYPE,SIZE,MODEL,TRAN
sudo smartctl -a /dev/vda

virtio-blk, cakera KVM (kernel-based virtual machine) yang biasa. Peranti tersebut ialah /dev/vda dan smartctl berhenti sebelum ia menghantar sebarang data:

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

virtio-blk ialah pengangkutan paravirtual tanpa set arahan ATA atau SCSI di belakangnya, jadi tiada saluran untuk membawa permintaan SMART. -d sat dan -d scsi gagal dengan cara yang sama, kerana masalahnya terletak pada pengangkutan dan bukannya flag tersebut.

Cakera SATA atau SCSI yang diemulasi. Peranti tersebut ialah /dev/sda dan smartctl berjaya sampai ke tahap mengenal pastinya. Baris model memaparkan QEMU HARDDISK. Rentetan itu menjawab soalan tersebut dengan sendirinya: anda sedang membaca peranti yang dicipta oleh emulator, dan ia tidak melaporkan keupayaan SMART yang boleh digunakan.

Namespace NVMe. sudo nvme smart-log /dev/nvme0n1 mengembalikan log penuh, yang merupakan punca orang sering terpedaya. Semak identiti pengawal (controller) terlebih dahulu dengan sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)'. Nombor model yang menamakan produk storan rangkaian bermakna pengawal tersebut adalah perisian, jadi percentage_used dan media_errors menerangkan emulasi tersebut dan bukannya memori flash di bawah data anda. Jika anda ingin mengetahui storan anda yang sebenarnya, sahkan cakera NVMe pada Linux dan jangan hanya mempercayai penerangan pelan tersebut.

Kontena, seperti LXC (Linux containers) atau OpenVZ. Anda tidak mempunyai peranti blok sendiri. lsblk memaparkan peranti hos atau tidak memaparkan apa-apa langsung, dan smartctl ditolak kerana kontena tidak memegang CAP_SYS_RAWIO:

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

Satu amaran mengenai situasi di mana ia berfungsi. Jika smartctl pada VPS mengembalikan jadual atribut penuh, baca nombor siri sebelum anda mengambil tindakan. Sesetengah hos mendedahkan nod peranti passthrough, dan pembilang tersebut adalah milik perkakasan yang dikongsi oleh setiap penyewa pada mesin itu. Nilai Reallocated_Sector_Ct yang meningkat di sana memerlukan tiket sokongan. Ia bukan satu kenyataan mengenai data anda.

Isyarat 1: Ralat I/O dalam log kernel

Ini adalah isyarat paling bernilai yang dimiliki oleh penyewa dan ia tidak memerlukan ejen.

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'

Permintaan yang gagal daripada cakera maya kelihatan seperti ini:

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

Lapisan blok meminta hos untuk melakukan penulisan dan hos mengembalikan kegagalan. Pada VPS, ini jarang sekali disebabkan oleh sel kilat (flash cell) yang rosak. Ia biasanya berpunca daripada lapisan storan hos atau laluan rangkaian ke storan yang disambungkan ke rangkaian (NAS), jadi ia adalah peristiwa di pihak penyedia. Salin cap masa, nama peranti, dan sektor ke dalam tiket anda, kerana maklumat inilah yang boleh dipadankan oleh pasukan storan dengan log mereka sendiri.

Jujukan ext4 yang paling penting ialah pasangan ini:

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

Baris kedua adalah yang paling kritikal, kerana mesin masih kekal hidup. Ia menjawab ping, ia menjawab SSH, dan setiap penulisan gagal. Semakan HTTP biasa akan terus lulus sementara aplikasi anda memaparkan ralat pada setiap permintaan.

XFS pula akan menutup sistem fail tersebut:

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 hanya membaca but semasa melainkan jurnal disimpan pada cakera, dan banyak imej menggunakan jurnal meruap yang hidup dalam RAM. Aktifkan persistensi, atau bukti tersebut akan hilang tepat pada but semula yang akan anda lakukan semasa menyelesaikan masalah.

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

Selepas but semula anda yang seterusnya, journalctl --list-boots sepatutnya menyenaraikan lebih daripada satu but. Walaupun dengan persistensi diaktifkan, sistem fail yang telah bertukar kepada mod baca sahaja tidak dapat merekodkan apa yang berlaku seterusnya, yang merupakan hujah kukuh untuk menghantar log keluar dari pelayan tersebut.

Isyarat 2: mengesan remount baca-sahaja

Jadikan kegagalan itu jelas sebelum anda cuba mengesannya.

findmnt -no SOURCE,FSTYPE,OPTIONS /

Cari errors=remount-ro dalam pilihan. Imej awan Ubuntu dan Debian menetapkannya dalam /etc/fstab, supaya ralat metadata menyebabkan sistem fail menjadi baca-sahaja dan bukannya meneruskan operasi walaupun terdapat kerosakan. Jika ia tiada, tambahkannya pada entri root dalam /etc/fstab, atau tetapkannya dalam superblock dengan sudo tune2fs -e remount-ro /dev/vda1. Berhenti secara jelas adalah lebih baik daripada kerosakan senyap.

Flag mount bukanlah bukti. Uji dengan menulis:

touch /var/tmp/.disk-probe

Pada root baca-sahaja, ia akan mencetak tepat:

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

Gunakan /var/tmp, bukan /tmp. Pada kebanyakan imej, /tmp ialah tmpfs yang disimpan dalam memori, jadi penulisan yang berjaya di sana tidak membuktikan apa-apa tentang cakera anda.

Gabungkan ujian penulisan dengan semakan ruang, dan hantar heartbeat hanya apabila setiap semakan berjaya:

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 pada baris terakhir itu bermakna keseluruhan rantaian berfungsi. set -eu menyebabkan sebarang semakan yang gagal keluar dengan kod bukan-sifar sebelum baris curl dijalankan, jadi tiada heartbeat dihantar. Penyongsangan itu adalah tujuannya: monitor bertukar merah kerana tiada apa-apa yang sampai, dan pelayan yang tidak boleh menulis tidak boleh dipercayai untuk menerangkan masalahnya sendiri. Bacaan masih berfungsi pada sistem fail baca-sahaja, jadi skrip itu sendiri masih bermula.

Jalankannya daripada 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 sepatutnya menunjukkan unit tersebut dengan masa NEXT kurang daripada lima minit lagi. Percubaan yang gagal akan muncul dalam journalctl -u disk-probe.service dengan teks ralat shell itu sendiri, jadi anda boleh membezakan sistem fail baca-sahaja daripada sistem fail yang penuh tanpa perlu log masuk.

URL push itu adalah monitor push Uptime Kuma. Cipta monitor jenis Push, salin tokennya ke dalam skrip, dan tetapkan selang heartbeat monitor sedikit lebih lama daripada selang timer supaya satu larian yang perlahan tidak menghantar amaran kepada anda pada pukul 03:00. Jika anda belum mempunyai halaman status, instans Uptime Kuma yang dihoskan sendiri adalah tempat paling murah untuk meletakkan semakan ini.

Dua had yang jujur. Proba ini mengesahkan bahawa penulisan telah diterima, bukan bahawa bait tersebut sampai ke storan tahan lama, kerana bacaan semula boleh dihidangkan daripada page cache. Dan ia berjalan pada mesin yang dipantaunya, jadi pelayan yang tersekat sepenuhnya akan menjadi senyap dan bukannya melaporkan diagnosis.

Isyarat 3: trend kependaman dan daya pemprosesan

sudo apt install -y sysstat
iostat -xdz 5 3

Baca r_await dan w_await terlebih dahulu. Ini adalah purata milisaat yang diambil oleh operasi baca atau tulis, termasuk masa menunggu dalam baris gilir. Seterusnya, baca aqu-sz, iaitu purata bilangan permintaan yang sedang diproses. Abaikan %util pada cakera maya: ia hanya bermaksud baris gilir tidak kosong, dan peranti yang melayani banyak permintaan secara selari akan berada hampir 100 peratus walaupun ia masih jauh daripada hadnya. await ialah nombor yang menjejaki apa yang dirasai oleh pengguna.

Nilai mutlak kurang penting berbanding garis dasar (baseline) anda sendiri, jadi rekodkan satu jam yang tenang dan simpan data tersebut. /proc/diskstats ialah sumber mentah jika anda lebih suka mengumpul pembilang tersebut sendiri.

Untuk pengukuran yang disengajakan:

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

Baca blok clat percentiles, khususnya persentil ke-99. --direct=1 melangkau cache halaman anda. Ia tidak melangkau cache hos, jadi hasilnya menggambarkan keseluruhan laluan daripada proses anda sehingga ke storan platform. Jalankan ia semasa pelayan melahu, kerana ia akan bersaing dengan beban kerja anda sendiri.

await yang meningkat tanpa ralat dalam log kernel biasanya bukan disebabkan oleh pemacu yang rosak. Ia adalah pertikaian (contention) pada hos, iaitu versi storan bagi masa curi CPU daripada jiran yang bising. Jika ia berlaku pada jam yang sama setiap hari dan tiket sokongan anda kembali dengan status bersih, jawapannya ialah pelan yang I/O-nya tidak dikongsi dengan cara yang sama, seperti yang berlaku pada VPS storan berbanding VPS biasa apabila beban kerja terikat dengan cakera (disk bound).

Isyarat 4: pemeriksaan sistem fail yang boleh dijalankan semasa dipasang (mounted)

ext4 menyimpan pembilang ralat dalam superblock, dan ia kekal selepas but semula walaupun log anda telah hilang.

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

Sistem fail yang sihat akan memaparkan Filesystem state: clean dan FS Error count: 0. clean with errors dan kiraan bukan sifar bermakna kernel telah menemui ralat metadata pada satu ketika, walaupun tiada siapa yang menyedarinya dan log telah diganti. Perintah tersebut perlu dimasukkan dalam pemeriksaan mingguan.

Anda tidak boleh menjalankan fsck pada sistem fail root yang sedang dipasang, dan e2fsck -n pada sistem fail yang aktif hanya melaporkan masalah yang berpunca daripada data yang berubah di bawahnya. Untuk memaksa pemeriksaan sebenar, tambahkan fsck.mode=force fsck.repair=yes pada baris perintah kernel untuk satu sesi but daripada konsol pembekal anda. systemd-fsck kemudiannya akan menjalankan pemeriksaan sebelum root dipasang dalam mod baca-tulis (read-write).

XFS tidak mempunyai pemeriksaan dalam talian. xfs_repair -n /dev/vda1 enggan dijalankan terhadap sistem fail yang sedang dipasang, jadi ia perlu dilakukan dalam mod pemulihan (rescue mode). XFS mengimbangi perkara ini dengan menjadi lebih proaktif: ia mematikan sistem fail apabila berlaku ralat metadata dan bukannya meneruskan operasi.

Pada Btrfs, pembilang dibina secara dalaman dan bersifat kekal.

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

write_io_errs atau corruption_errs yang melebihi sifar adalah peristiwa sebenar, dan pembilang tersebut mengekalkan nilainya merentasi but semula sehingga anda menetapkannya semula. scrub membaca semula setiap blok dan mengesahkan checksum-nya, yang merupakan perkara paling hampir dengan ujian media yang tersedia pada cakera maya. Ia menggunakan I/O yang tinggi, jadi jadualkan ia pada waktu trafik rendah.

Isyarat 5: ruang bebas, termasuk bahagian yang disembunyikan oleh df

Kehabisan ruang akan melumpuhkan pelayan sama seperti kerosakan cakera, dan ia berlaku dengan lebih kerap.

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

No space left on device manakala df -h menunjukkan ruang bebas bermakna anda telah kehabisan inode dan bukannya bait, dan df -i menunjukkan IUse% pada 100 peratus. Berjuta-juta fail kecil dalam direktori cache atau spool mel menyebabkan perkara ini, dan memadam fail besar tidak akan membantu.

Ruang yang tidak kembali selepas pemadaman biasanya disebabkan oleh fail yang telah dipadam tetapi masih dibuka oleh proses yang sedang berjalan. sudo lsof +L1 menyenaraikan fail yang kiraan pautannya telah mencapai sifar. Memulakan semula proses yang memegang fail tersebut akan membebaskan ruang berkenaan.

Jurnal merupakan pengguna ruang yang sering tidak disedari. journalctl --disk-usage melaporkan kandungan yang disimpannya. Hadkan saiznya dengan SystemMaxUse=200M dalam /etc/systemd/journald.conf diikuti dengan sudo systemctl restart systemd-journald, dan tuntut semula ruang tersebut sekarang dengan sudo journalctl --vacuum-size=200M.

Satu kes kelihatan seperti pepijat tetapi sebenarnya bukan. Pada storan hos yang diperuntukkan secara nipis (thin provisioned), pool hos boleh penuh sementara df anda masih menunjukkan ruang gigabait yang bebas. Penulisan anda kemudiannya gagal dengan ralat I/O dalam log kernel tanpa sebarang amaran ruang di dalam tetamu (guest). Ralat tanpa sistem fail yang penuh adalah kombinasi yang perlu dilaporkan melalui tiket pada jam yang sama.

Menyambungkan isyarat ke ejen metrik

Probe tolak (push probe) memberikan jawapan ya atau tidak. Trend memerlukan ejen metrik, dan Prometheus node_exporter sudah mengeksport semua data di atas tanpa konfigurasi tambahan. Nama metrik yang boleh digunakan sebagai asas:

• node_filesystem_readonly menjadi 1 apabila mount berada dalam mod baca sahaja (read-only), yang merupakan penggera untuk remount anda.
• node_filesystem_avail_bytes dan node_filesystem_files_free meliputi bait dan inode secara berasingan.
• node_disk_io_time_seconds_total dan node_disk_read_time_seconds_total memberikan masa sibuk dan kependaman (latency) sebagai pembilang yang boleh anda grafkan.

Dua peraturan menangani kes yang benar-benar mencetuskan amaran (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

Peraturan kedua mencetuskan amaran apabila trend semasa mencecah sifar dalam tempoh empat hari, supaya anda mendapat amaran beberapa hari lebih awal dan bukannya pada tahap 95 peratus penuh, yang hanya memberikan anda masa beberapa minit sahaja.

Tanggungjawab setiap pihak

Penyedia anda memiliki pemacu fizikal. Mereka membaca SMART, mereka mengendalikan tatasusunan (array), dan mereka menggantikan pemacu yang mempunyai sektor teralih (reallocated sectors) yang meningkat, biasanya tanpa memberitahu anda, kerana tatasusunan tersebut menyerap kegagalan itu. Itulah tujuan RAID 10 di bawah VPS anda: pemacu yang rosak akan menjalani proses bina semula (rebuild) dan bukannya menyebabkan gangguan perkhidmatan. Anda tidak dapat melihat semua ini, dan membayar untuk abstraksi tersebut merupakan tujuan utama menyewa pelayan maya.

Anda memiliki data anda sendiri, dan telemetri pemacu juga tidak akan melindunginya. Peristiwa yang sebenarnya memusnahkan data penyewa ialah rm yang tersilap, atur cara (deploy) yang bermasalah, penceroboh yang memiliki kunci SSH anda, dan insiden platform yang turut melumpuhkan tatasusunan tersebut. Atribut SMART tidak dapat meramalkan mana-mana perkara ini.

Oleh itu, perlindungan sebenar bagi penyewa ialah sandaran (backup) yang disimpan di luar pelayan dan proses pemulihan (restore) yang telah anda lakukan sendiri. Snapshot daripada penyedia adalah mudah digunakan, namun ia berada pada platform yang sama dengan perkara yang dilindunginya, itulah sebabnya snapshot dan sandaran adalah perlindungan yang berbeza. Tetapkan jadual latihan: setiap suku tahun, pulihkan sandaran terkini ke dalam VPS baharu, mulakan aplikasi tersebut, dan catatkan berapa lama masa yang diambil. Angka tersebut ialah masa pemulihan sebenar anda. Latihan pertama sentiasa mengambil masa yang lebih lama daripada jangkaan sesiapa pun.

Bilakah SMART terpakai kepada anda

Panduan yang mengajar smartctl adalah tepat, dan ia terpakai sebaik sahaja perkakasan tersebut benar-benar milik anda:

• Pelayan berdedikasi atau bare metal, di mana sudo smartctl -a /dev/sda memaparkan jadual atribut penuh dan smartd boleh menghantar e-mel kepada anda apabila sesuatu atribut berubah.
• Pelan storan yang melalukan cakera fizikal terus kepada tetamu. Penyedia mendokumentasikan perkara ini secara eksplisit kerana ia merupakan nilai jualan.
• Perkakasan yang anda miliki, sama ada di rumah atau di ruang rak yang anda sewa.
• Cakera di sebalik pengawal RAID yang boleh dicapai dengan sudo smartctl -a -d megaraid,0 /dev/sda, atau kepungan USB dengan -d sat.

Pada NVMe sebenar, sudo smartctl -a -d nvme /dev/nvme0 dan sudo nvme smart-log /dev/nvme0n1 melaporkan critical_warning dan percentage_used daripada pemacu itu sendiri. Pada SATA sebenar, atribut yang meramalkan kegagalan ialah Reallocated_Sector_Ct (5), Current_Pending_Sector (197), Offline_Uncorrectable (198) dan Reported_Uncorrect (187). Mana-mana daripadanya yang berubah daripada sifar bermakna anda perlu merancang penggantian. Kajian pemacu berskala besar sentiasa merujuk kepada senarai pendek yang sama, dan kebanyakan atribut lain hanyalah gangguan.

Jalankan daemon tersebut daripada menyemak secara manual.

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

Log ujian kendiri sepatutnya menunjukkan Completed without error untuk ujian yang baru anda mulakan. Ubuntu dan Debian membekalkan /etc/smartd.conf dengan baris DEVICESCAN, yang terkini sehingga Ogos 2026, jadi daemon tersebut akan mengesan setiap cakera yang dapat dilihatnya dan menghantar e-mel kepada root sekiranya berlaku perubahan. Tiada satu pun daripada ini berfungsi pada cakera maya, itulah sebabnya bahagian panduan yang lain ini wujud.

FAQ

Mengapa smartctl tidak berfungsi pada VPS saya?

Kerana cakera tersebut adalah maya. Pada tetamu KVM yang menggunakan virtio-blk, smartctl -a /dev/vda mencetak /dev/vda: Unable to detect device type, memandangkan cakera paravirtual tidak membawa saluran arahan ATA atau SCSI untuk permintaan SMART melaluinya. Pada cakera yang diemulasi, anda mencapai peranti yang modelnya terbaca sebagai QEMU HARDDISK, tanpa data SMART yang boleh digunakan di sebaliknya. Di dalam kontena, smartctl ditolak secara terus kerana kekurangan CAP_SYS_RAWIO. Tiada satu pun daripada ini merupakan salah konfigurasi, dan tiada flag -d yang dapat membaikinya.

Bagaimanakah saya tahu jika cakera VPS saya mengalami kegagalan?

Perhatikan kesan dan bukannya perkakasan. Semak sudo journalctl -k -p err -b untuk baris blk_update_request: I/O error dan untuk Remounting filesystem read-only. Jalankan sudo dumpe2fs -h /dev/vda1 | grep -i 'error count' untuk mencari ralat yang telah hilang daripada log. Jejaki r_await daripada iostat -xdz 5 berbanding garis dasar yang anda rekodkan semasa sistem dalam keadaan baik. Pada VPS, ralat I/O biasanya bermaksud masalah storan hos dan bukannya pemacu yang hampir rosak, jadi ia perlu dilaporkan dalam tiket sokongan dengan menyertakan cap masa dan sektor yang terlibat.

Apakah yang perlu saya pantau untuk kesihatan cakera VPS?

Empat makluman sudah mencukupi. Lekapan baca-sahaja (read-only mount), daripada node_filesystem_readonly == 1 atau ujian tulis yang gagal. Ruang bebas dan inode bebas yang semakin berkurangan menghampiri sifar. Sebarang I/O error kernel dalam selang masa terakhir. Degupan jantung (heartbeat) daripada pelayan, supaya keheningan sistem memberi amaran kepada anda apabila kotak tersebut berhenti memberi respons. Abaikan apa-apa yang diperoleh daripada SMART, kerana pada cakera maya nilai tersebut sama ada tiada atau hanya menggambarkan emulasi hypervisor.

Mengapa sistem fail saya dipasang semula sebagai baca-sahaja?

ext4 yang dipasang dengan errors=remount-ro melakukan perkara ini secara sengaja apabila ia menemui ralat metadata: ia berhenti menulis daripada meneruskan kerosakan. Pencetusnya berada dalam log kernel tepat di atas baris pemasangan semula, biasanya EXT4-fs error mengenai jurnal yang digugurkan selepas peranti asas mengembalikan ralat I/O. Memasang semula sebagai baca-tulis tanpa memeriksa sistem fail hanya menyembunyikan simptom dan mengekalkan puncanya. Dapatkan log tersebut, kemudian periksa sistem fail yang dinyahlekap daripada mod pemulihan dengan e2fsck -fy /dev/vda1.

Bolehkah saya membaca data SMART pada pelayan maya?

Dalam kes tertentu, ya. Pelayan berdedikasi dan bare metal memberikan anda atribut sebenar. Begitu juga dengan pelan storan yang melalukan (pass-through) cakera fizikal kepada tetamu, dan mana-mana hos yang anda miliki sendiri. Sesetengah platform membentangkan pengawal NVMe kepada tetamu dan nvme smart-log mengembalikan log, jadi jalankan sudo nvme id-ctrl /dev/nvme0 dahulu: nombor model yang menamakan perkhidmatan storan rangkaian bermakna pembilang tersebut datang daripada pengawal perisian. Dan di mana nod passthrough mendedahkan pembilang sebenar pada mesin kongsi, ia menggambarkan perkakasan yang dikongsi dengan penyewa lain, jadi satu-satunya tindakan berguna ialah membuka tiket sokongan.