VPS üzerinde disk sağlığı nasıl izlenir?

VPS üzerinde disk sağlığı izleme ile nelerin görülebileceği

VPS üzerinde disk sağlığı izleme, çoğu rehberin göz ardı ettiği bir gerçekle başlar: disk size ait değildir. Konuk sisteminiz sanal bir blok aygıtı görür. Fiziksel sürücü ve üzerinde tutulan her sayaç, ana makineye (host) aittir. smartctl /dev/vda komutu, yanlış yazdığınız için başarısız olmaz. Aygıtın arkasındaki hiçbir mekanizma bu soruya yanıt veremediği için başarısız olur.

SMART (self-monitoring, analysis and reporting technology), sürücünün kendi üzerinde tutulan bir sayaç tablosudur: yeniden tahsis edilen sektörler, bekleyen sektörler, çalışma saatleri ve medya hataları. Bu tabloyu okumak, ATA veya NVMe (non-volatile memory express) komutlarının gerçek donanıma ulaşması için bir yol gerektirir. Paravirtual bir disk bu yolu sağlamaz, bu nedenle konuk sistem telemetri verilerinden arındırılmış bir depolama alanı alır.

Bir kiracı donanımı değil, etkileri izler. Konuk sistemin içinden dört sinyal görülebilir: çekirdek günlüğündeki I/O (input/output) hataları, salt okunur moda geçen bir dosya sistemi, yukarı doğru kayan gecikme süreleri ve tükenen disk alanı. Bu dört durum için de bugün uyarı mekanizmaları kurulabilir ve dördü de bir kullanıcı şikayet etmeden önce ortaya çıkar. Öncelikle bunları yapılandırın. Sorumluluk paylaşımı en sonda gelir, çünkü bu durum çabanızı nereye harcamanız gerektiğini değiştirir.

Kendi sunucunuzun neyi dışa açtığını kanıtlayın

Hangi durumda olduğunuzu varsaymayın. İnceleyin, ardından eşleşen bölümü okuyun.

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

virtio-blk, standart KVM (kernel-based virtual machine) diski. Cihaz /dev/vda şeklindedir ve smartctl herhangi bir veri göndermeden önce durur:

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

virtio-blk, arkasında ATA veya SCSI komut seti bulunmayan bir paravirtual taşıyıcıdır; bu nedenle SMART isteğini iletecek bir kanal yoktur. -d sat ve -d scsi aynı şekilde başarısız olur, çünkü sorun bayrakta değil, taşıyıcı katmanındadır.

Emüle edilmiş bir SATA veya SCSI diski. Cihaz /dev/sda şeklindedir ve smartctl onu tanımlayacak kadar ilerler. Model satırı QEMU HARDDISK olarak görünür. Bu metin sorunun cevabını kendiliğinden verir: emülatör tarafından oluşturulmuş bir cihazı okuyorsunuz ve bu cihaz kullanılabilir bir SMART yeteneği raporlamıyor.

Bir NVMe namespace. sudo nvme smart-log /dev/nvme0n1 tam bir günlük döndürür; insanlar genellikle burada yanılır. Önce sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)' ile kontrolcü kimliğini doğrulayın. Bir ağ depolama ürününü işaret eden model numarası, kontrolcünün yazılımsal olduğu anlamına gelir; bu nedenle percentage_used ve media_errors, verilerinizin altındaki flash belleği değil, bu emülasyonu tanımlar. Depolama biriminizin gerçekte ne olduğunu öğrenmek istiyorsanız, plan açıklamasına güvenmek yerine Linux üzerinde NVMe diskini doğrulayın.

LXC (Linux containers) veya OpenVZ gibi bir container. Kendinize ait bir blok cihazınız yoktur. lsblk ya ana makinenin cihazlarını gösterir ya da hiçbir şey göstermez; container CAP_SYS_RAWIO yetkisine sahip olmadığı için smartctl reddedilir:

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

Çalıştığı durumla ilgili bir uyarı: Eğer bir VPS üzerinde smartctl tam bir öznitelik tablosu döndürürse, işlem yapmadan önce seri numarasını okuyun. Bazı ana makineler bir passthrough cihaz düğümü açığa çıkarır ve bu sayaçlar, o makinedeki her kiracı tarafından paylaşılan donanıma aittir. Orada artan bir Reallocated_Sector_Ct değeri, bir destek talebi oluşturmanız gerektiği anlamına gelir. Bu, verilerinizle ilgili bir durum bildirimi değildir.

Sinyal 1: Çekirdek günlüğündeki G/Ç hataları

Bu, bir kiracının sahip olduğu en değerli sinyaldir ve herhangi bir aracı (agent) gerektirmez.

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'

Sanal diskten gelen başarısız bir istek şu şekilde görünür:

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

Blok katmanı, ana makineden bir yazma işlemi talep etti ve ana makine bir hata döndürdü. Bir VPS üzerinde bu durum nadiren ölen bir flash hücresidir. Genellikle ana makine depolama katmanı veya ağa bağlı depolama birimine giden ağ yoludur; dolayısıyla bu, sağlayıcı tarafında gerçekleşen bir olaydır. Zaman damgasını, cihaz adını ve sektörü destek talebinize kopyalayın; çünkü depolama ekibinin kendi günlükleriyle eşleştirebileceği veriler bunlardır.

ext4 dizisinde en önemli olan kısım şu ikilidir:

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

İkinci satır asıl sorundur, çünkü makine çalışmaya devam eder. Ping isteklerine yanıt verir, SSH bağlantılarını kabul eder ancak tüm yazma işlemleri başarısız olur. Uygulamanız her istekte hata verirken, basit bir HTTP kontrolü başarılı olmaya devam eder.

XFS ise bunun yerine dosya sistemini kapatır:

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, günlük disk üzerinde tutulmadığı sürece yalnızca mevcut önyüklemeyi okur; birçok imaj RAM üzerinde yaşayan uçucu bir günlük ile gelir. Kalıcılığı etkinleştirin, aksi takdirde sorun giderme sırasında yapacağınız yeniden başlatma ile kanıtlar kaybolur.

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

Bir sonraki yeniden başlatmanızdan sonra, journalctl --list-boots birden fazla önyükleme listelemelidir. Kalıcılık açık olsa bile, salt okunur moda geçen bir dosya sistemi daha sonra ne olduğunu kaydedemez; bu, günlüklerin sunucu dışına gönderilmesi için geçerli bir gerekçedir.

Sinyal 2: salt okunur yeniden bağlamayı yakalamak

Hata tespitini yapmadan önce hatayı belirgin hale getirin.

findmnt -no SOURCE,FSTYPE,OPTIONS /

Seçenekler içinde errors=remount-ro ifadesini arayın. Ubuntu ve Debian bulut imajları bunu /etc/fstab içinde ayarlar; bu sayede bir meta veri hatası oluştuğunda dosya sistemi hasar üzerinde çalışmaya devam etmek yerine salt okunur moda geçer. Eğer bu seçenek eksikse, /etc/fstab içindeki kök dizin girdisine ekleyin veya sudo tune2fs -e remount-ro /dev/vda1 ile süper blok üzerinde ayarlayın. Gürültülü bir duruş, sessiz bir bozulmadan iyidir.

Bir mount bayrağı kanıt değildir. Yazma işlemi yaparak test edin:

touch /var/tmp/.disk-probe

Salt okunur bir kök dizinde bu komut tam olarak şunu yazdırır:

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

/tmp yerine /var/tmp kullanın. Çoğu imajda /tmp bellekte tutulan bir tmpfs'tir; dolayısıyla orada başarılı olan bir yazma işlemi disk hakkında hiçbir şey kanıtlamaz.

Yazma testini bir disk alanı kontrolü ile birleştirin ve yalnızca tüm kontroller geçtiğinde bir heartbeat gönderin:

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

Son satırdaki probe-ok, tüm zincirin çalıştığı anlamına gelir. set -eu, başarısız olan herhangi bir kontrolün curl satırı çalışmadan önce sıfır olmayan bir değerle çıkmasını sağlar; böylece hiçbir heartbeat gönderilmez. Bu tersine çevirme işleminin amacı budur: monitör, hiçbir veri ulaşmadığı için kırmızıya döner; yazma yapamayan bir sunucuya kendi sorununu tanımlaması konusunda güvenilemez. Salt okunur bir dosya sisteminde okuma işlemleri hala çalıştığı için betiğin kendisi başlatılabilir.

Betiği bir systemd timer üzerinden çalıştırın.

# /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, birimi NEXT süresi beş dakikadan az kalacak şekilde göstermelidir. Başarısız bir çalıştırma, journalctl -u disk-probe.service içinde kabuğun kendi hata metniyle görünür; böylece sisteme giriş yapmadan salt okunur bir dosya sistemi ile dolu bir dosya sistemi arasındaki farkı anlayabilirsiniz.

Bu push URL'si bir Uptime Kuma push monitörüdür. Push tipinde bir monitör oluşturun, token değerini betiğe kopyalayın ve monitörün heartbeat aralığını timer aralığından biraz daha uzun ayarlayın; böylece yavaş bir çalıştırma sizi saat 03:00'te uyandırmaz. Henüz bir durum sayfanız yoksa, kendi kendine barındırılan bir Uptime Kuma örneği bu kontrolü koymak için en ucuz yerdir.

İki dürüst sınırlama. Bu test, yazma işleminin kabul edildiğini doğrular; baytların kalıcı depolamaya ulaştığını değil, çünkü geri okuma işlemi sayfa önbelleğinden (page cache) sunulabilir. Ayrıca test, izlediği makine üzerinde çalışır; bu nedenle tamamen kilitlenmiş bir sunucu, bir teşhis raporu sunmak yerine sessizliğe gömülür.

Sinyal 3: gecikme ve iş hacmi eğilimleri

sudo apt install -y sysstat
iostat -xdz 5 3

Önce r_await ve w_await değerlerini okuyun. Bunlar, kuyrukta beklenen süre dahil olmak üzere bir okuma veya yazma işleminin ortalama milisaniye cinsinden süresidir. Ardından, işlemdeki ortalama istek sayısı olan aqu-sz değerini inceleyin. Sanal bir disk üzerindeki %util değerini görmezden gelin: bu sadece kuyruğun boş olmadığını gösterir; paralel olarak birçok isteğe hizmet veren bir aygıt, sınırına yakın olmasa bile yüzde 100'e yakın bir değerde çalışabilir. Kullanıcıların deneyimlediği durumu takip eden sayı await değeridir.

Mutlak değerlerden ziyade kendi temel performans verileriniz önemlidir; bu nedenle sistemin sakin olduğu bir saati kaydedin ve referans olarak saklayın. Sayaçları kendiniz toplamak isterseniz ham kaynak /proc/diskstats değeridir.

Kasıtlı bir ölçüm için:

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

Özellikle 99. yüzdelik dilim olmak üzere clat percentiles bloğunu okuyun. --direct=1, sayfa önbelleğinizi (page cache) atlar. Ana makinenin önbelleğini atlamaz, bu nedenle sonuç, sürecinizden platformun depolama birimine kadar olan tüm yolu tanımlar. Kendi iş yükünüzle rekabet edeceği için sunucu boşta iken çalıştırın.

Çekirdek günlüğünde (kernel log) hata olmaksızın yükselen await değeri, genellikle arızalı bir sürücüye işaret etmez. Bu durum, ana makine üzerindeki çekişmedir; yani gürültülü komşudan kaynaklanan CPU çalınma süresinin depolama karşılığıdır. Eğer bu durum her gün aynı saatte tekrarlanıyorsa ve destek talebiniz temiz sonuçlanıyorsa, çözüm I/O kaynakları bu şekilde paylaşılmayan bir plan seçmektir; iş yükü disk odaklı olduğunda standart bir VPS yerine depolama odaklı bir VPS kullanmak bu duruma örnektir.

Sinyal 4: Bağlı durumdayken çalıştırabileceğiniz dosya sistemi denetimleri

ext4, hata sayacını superblock içinde tutar; bu sayaç, günlük kayıtlarınız silinse bile yeniden başlatmalardan sonra varlığını korur.

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

Sağlıklı bir dosya sistemi Filesystem state: clean ve FS Error count: 0 çıktılarını verir. clean with errors ve sıfırdan farklı bir değer, çekirdeğin bir noktada meta veri hatasıyla karşılaştığı anlamına gelir; kimse fark etmemiş veya günlük kayıtları dönmüş olsa bile bu durum geçerlidir. Bu komut, haftalık kontrollerin bir parçası olmalıdır.

Bağlı (mounted) bir kök dosya sisteminde fsck çalıştıramazsınız; canlı bir dosya sisteminde e2fsck -n çalıştırmak, yalnızca altta değişen verilerden kaynaklanan sorunları raporlar. Gerçek bir denetim zorlamak için, sağlayıcınızın konsolu üzerinden bir kerelik yeniden başlatma için çekirdek komut satırına fsck.mode=force fsck.repair=yes parametresini ekleyin. systemd-fsck, kök dizin okuma-yazma modunda bağlanmadan önce denetimi gerçekleştirecektir.

XFS üzerinde çevrimiçi denetim özelliği yoktur. xfs_repair -n /dev/vda1, bağlı bir dosya sisteminde çalışmayı reddeder; bu nedenle kurtarma modunda (rescue mode) kullanılmalıdır. XFS, bu eksikliği gürültülü çalışarak telafi eder: meta veri hatası durumunda çalışmaya devam etmek yerine dosya sistemini kapatır.

Btrfs üzerinde sayaçlar yerleşik ve kalıcıdır.

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

write_io_errs veya corruption_errs değerlerinin sıfırdan büyük olması gerçek bir olaya işaret eder ve sayaçlar, siz sıfırlayana kadar yeniden başlatmalardan sonra da değerlerini korur. scrub, her bloğu yeniden okur ve sağlama toplamını (checksum) doğrular; bu işlem, sanal disk üzerinde yapılabilecek medya testine en yakın yöntemdir. I/O üzerinde yoğun yük oluşturduğu için bu işlemi sakin saatlere planlayın.

Sinyal 5: df komutunun gizlediği bölümler dahil boş alan

Disk alanının tükenmesi, bir sunucuyu arızalı bir diskle aynı şekilde devre dışı bırakır ve bu durum disk arızalarından çok daha sık yaşanır.

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

No space left on device komutu çalışırken df -h komutunun boş alan göstermesi, bayt yerine inode değerlerinizin tükendiği anlamına gelir; bu durumda df -i komutu IUse% değerini yüzde 100 olarak gösterir. Bir önbellek dizininde veya posta kuyruğunda biriken milyonlarca küçük dosya buna neden olur ve büyük dosyaları silmek sorunu çözmez.

Silme işleminden sonra geri kazanılmayan alan, genellikle çalışan bir süreç tarafından açık tutulan silinmiş bir dosyadır. sudo lsof +L1 komutu, bağlantı sayısı sıfıra düşmüş dosyaları listeler. Dosyayı açık tutan süreci yeniden başlatmak, alanı serbest bırakır.

Sistem günlüğü (journal), genellikle fark edilmeyen bir alan tüketicisidir. journalctl --disk-usage komutu, günlüğün ne kadar yer kapladığını raporlar. /etc/systemd/journald.conf dosyasında SystemMaxUse=200M ayarını yaparak boyutu sınırlayın, ardından sudo systemctl restart systemd-journald komutunu çalıştırın ve sudo journalctl --vacuum-size=200M komutu ile alanı hemen geri kazanın.

Bir durum hata gibi görünse de aslında değildir. İnce yapılandırılmış (thin provisioned) ana makine depolamasında, sizin df çıktınız boş gigabaytlar gösterse bile ana makinenin havuzu dolmuş olabilir. Bu durumda yazma işlemleriniz, çekirdek günlüğünde (kernel log) I/O hataları ile başarısız olur ve konuk sistem içerisinde herhangi bir disk alanı uyarısı almazsınız. Dosya sistemi dolu olmadığı halde alınan hatalar, aynı saat içinde destek bileti açılması gereken bir durumdur.

Sinyallerin bir metrik aracına bağlanması

Bir push probe (itme tabanlı sonda) evet veya hayır yanıtı verir. Trend analizi için bir metrik aracına ihtiyaç duyulur; Prometheus node_exporter yukarıdaki tüm verileri ek bir yapılandırma gerektirmeden zaten dışa aktarır. Temel alınacak metrik adları şunlardır:

• node_filesystem_readonly, bir mount noktası salt okunur (read-only) olduğunda 1 değerini alır; bu, yeniden bağlama (remount) alarmınızdır.
• node_filesystem_avail_bytes ve node_filesystem_files_free, bayt ve inode değerlerini ayrı ayrı kapsar.
• node_disk_io_time_seconds_total ve node_disk_read_time_seconds_total, grafikleyebileceğiniz sayaçlar olarak meşguliyet süresini ve gecikme değerini verir.

İki kural, gerçek anlamda sayfa (page) gönderen durumları yakalar:

- 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

İkinci kural, mevcut trend dört gün içinde sıfıra ulaştığında tetiklenir. Böylece, yüzde 95 doluluk oranında dakikalarınız kalmışken değil, günler öncesinden uyarılmış olursunuz.

Sorumluluk paylaşımı

Fiziksel disklerin sahibi servis sağlayıcınızdır. SMART verilerini okurlar, diziyi yönetirler ve genellikle size haber vermeden, yeniden tahsis edilen sektör sayısı artan bir diski değiştirirler; çünkü dizi, arızayı tolere eder. VPS üzerinde RAID 10 yapısının amacı budur: ölü bir disk, hizmet kesintisi yerine bir yeniden oluşturma sürecine dönüşür. Bunların hiçbirini göremezsiniz ve bu soyutlama için ödeme yapmak, sanal sunucu kiralamanın temel nedenlerinden biridir.

Verilerinizin sahibi sizsiniz ve disk telemetrisi verilerinizi zaten korumaz. Kiracı verilerini gerçekten yok eden olaylar; hatalı bir rm komutu, yanlış bir dağıtım, SSH anahtarınızı ele geçiren bir saldırgan ve diziyi de beraberinde götüren bir platform olayıdır. SMART öznitelikleri bunların hiçbirini öngöremez.

Bu nedenle bir kiracının gerçek koruması, sunucunun dışında barındırılan bir yedek ve bizzat gerçekleştirdiğiniz bir geri yükleme işlemidir. Sağlayıcı anlık görüntüleri (snapshot) kullanışlıdır ancak korudukları şeyle aynı platform üzerinde bulunurlar; anlık görüntüler ve yedekler farklı koruma yöntemleridir ifadesinin nedeni budur. Takviminize bir tatbikat ekleyin: her çeyrekte bir, en güncel yedeği yeni bir VPS'e geri yükleyin, uygulamayı başlatın ve ne kadar sürdüğünü not edin. Bu süre, gerçek kurtarma sürenizdir. İlk tatbikat her zaman tahmin edilenden daha yavaş geçer.

SMART sizin için ne zaman geçerlidir

smartctl öğreten kılavuzlar doğrudur ve donanım gerçekten size ait olduğu anda geçerli olurlar:

• sudo smartctl -a /dev/sda komutunun tam öznitelik tablosunu döndürdüğü ve smartd aracının bir öznitelik değiştiğinde size e-posta gönderebildiği özel veya bare metal sunucular.
• Fiziksel diski doğrudan konuk sisteme aktaran depolama planları. Sağlayıcılar bunu açıkça belgeler çünkü bu bir satış noktasıdır.
• Evinizde veya kiraladığınız kabin alanında bulunan, size ait donanımlar.
• sudo smartctl -a -d megaraid,0 /dev/sda ile erişilebilen bir RAID denetleyicisi arkasındaki diskler veya -d sat kullanan bir USB muhafazası.

Gerçek NVMe disklerde sudo smartctl -a -d nvme /dev/nvme0 ve sudo nvme smart-log /dev/nvme0n1, sürücünün kendisinden critical_warning ve percentage_used verilerini raporlar. Gerçek SATA disklerde ise arızayı önceden bildiren öznitelikler Reallocated_Sector_Ct (5), Current_Pending_Sector (197), Offline_Uncorrectable (198) ve Reported_Uncorrect (187) değerleridir. Bunlardan herhangi birinin sıfırdan farklı bir değere ulaşması, bir değişim planlamanız gerektiği anlamına gelir. Büyük ölçekli sürücü araştırmaları sürekli olarak aynı kısa listeye işaret etmektedir; diğer özniteliklerin çoğu ise gürültüden ibarettir.

Elle kontrol etmek yerine arka plan sürecini (daemon) çalıştırın.

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

Kendi kendine test günlüğü, yeni başlattığınız çalışma için Completed without error sonucunu göstermelidir. Ubuntu ve Debian, Ağustos 2026 itibarıyla güncel olan DEVICESCAN satırına sahip /etc/smartd.conf paketini sunar; böylece arka plan süreci görebildiği her diski algılar ve bir değişiklik olduğunda root kullanıcısına e-posta gönderir. Bunların hiçbiri sanal disklerde çalışmaz, bu kılavuzun geri kalanının var olma nedeni de budur.

FAQ

Neden smartctl VPS üzerinde çalışmıyor?

Disk sanal olduğu için çalışmaz. virtio-blk kullanan bir KVM konuğunda smartctl -a /dev/vda komutu /dev/vda: Unable to detect device type çıktısını verir; çünkü paravirtual bir disk, SMART isteğinin iletilebileceği bir ATA veya SCSI komut kanalı taşımaz. Emüle edilmiş bir diskte, arkasında kullanılabilir SMART verisi bulunmayan ve modeli QEMU HARDDISK olarak görünen bir aygıta ulaşırsınız. Bir container içerisinde ise CAP_SYS_RAWIO eksikliği nedeniyle smartctl doğrudan reddedilir. Bunların hiçbiri yanlış yapılandırma değildir ve hiçbir -d bayrağı bu durumu düzeltemez.

VPS diskimin arızalandığını nasıl anlarım?

Donanımdan ziyade sonuçları izleyin. blk_update_request: I/O error satırları ve Remounting filesystem read-only için sudo journalctl -k -p err -b dosyasını kontrol edin. Logların zaten kaybettiği hataları bulmak için sudo dumpe2fs -h /dev/vda1 | grep -i 'error count' komutunu çalıştırın. İşler yolundayken kaydettiğiniz bir temel değerle karşılaştırarak iostat -xdz 5 üzerinden r_await verisini takip edin. Bir VPS üzerinde I/O hatası genellikle ölen bir sürücüden ziyade ana makine depolama sorununa işaret eder; bu nedenle hata zaman damgası ve sektör bilgisiyle birlikte bir destek talebi olarak iletilmelidir.

VPS disk sağlığı için neleri izlemeliyim?

Dört uyarı yeterlidir. node_filesystem_readonly == 1 üzerinden veya başarısız olan bir yazma testi ile tespit edilen salt okunur mount durumu. Sıfıra doğru yaklaşan boş alan ve boş inode miktarı. Son aralıkta görülen herhangi bir çekirdek I/O error hatası. Sunucudan gelen bir heartbeat sinyali; böylece sunucu yanıt vermeyi kestiğinde sessizlik sizi uyarır. SMART verilerinden türetilen her şeyi atlayın; çünkü sanal disklerde bu değerler ya eksiktir ya da hipervizörün emülasyonunu tanımlar.

Dosya sistemim neden salt okunur olarak yeniden bağlandı?

errors=remount-ro ile bağlanan ext4, bir meta veri hatasıyla karşılaştığında bunu kasıtlı olarak yapar: hasar üzerinde işlem yapmaya devam etmek yerine yazmayı durdurur. Tetikleyici, çekirdek günlüğünde yeniden bağlama satırının hemen üzerinde yer alır; genellikle alttaki aygıt bir I/O hatası döndürdükten sonra iptal edilen bir günlük hakkında bir EXT4-fs error mesajıdır. Dosya sistemini kontrol etmeden salt okunur moddan salt yazılır moda geçmek, belirtiyi gizler ve nedeni olduğu gibi bırakır. Günlüğü kaydedin, ardından kurtarma modunda dosya sistemini unmount ederek e2fsck -fy /dev/vda1 ile kontrol edin.

Sanal bir sunucuda SMART verilerini okuyabilir miyim?

Belirli durumlarda evet. Dedicated ve bare metal sunucular size gerçek öznitelikleri verir. Fiziksel diski doğrudan konuğa aktaran depolama planları ve sahibi olduğunuz tüm ana makineler de bunu sağlar. Bazı platformlar konuğa bir NVMe denetleyicisi sunar ve nvme smart-log bir günlük döndürür; bu yüzden önce sudo nvme id-ctrl /dev/nvme0 komutunu çalıştırın: bir ağ depolama hizmetini adlandıran model numarası, bu sayaçların bir yazılım denetleyicisinden geldiği anlamına gelir. Passthrough düğümü paylaşımlı bir makinede gerçek sayaçları gösterse bile, bunlar diğer kiracılarla paylaşılan donanımı tanımlar; bu nedenle yapılabilecek tek yararlı işlem destek talebi oluşturmaktır.