Festplattenzustand auf einem VPS überwachen

Was die Datenträgerüberwachung auf einem VPS tatsächlich erkennen kann

Die Überwachung des Datenträgerzustands auf einem VPS beginnt mit einer Tatsache, die viele Anleitungen auslassen: Der Datenträger gehört Ihnen nicht. Ihr Gastbetriebssystem sieht ein virtuelles Blockgerät. Das physische Laufwerk und jeder darauf gespeicherte Zähler gehören dem Host. smartctl /dev/vda schlägt nicht fehl, weil Sie den Befehl falsch eingegeben haben. Der Befehl schlägt fehl, weil nichts hinter diesem Gerät die Anfrage beantworten kann.

SMART (Self-Monitoring, Analysis and Reporting Technology) ist eine Tabelle mit Zählern, die direkt auf dem Laufwerk gespeichert ist: neu zugewiesene Sektoren, ausstehende Sektoren, Betriebsstunden und Medienfehler. Zum Auslesen dieser Tabelle müssen ATA- oder NVMe-Befehle (Non-Volatile Memory Express) das physische Gerät erreichen können. Ein paravirtualisierter Datenträger stellt diesen Pfad nicht bereit. Daher erhält der Gast Speicher, dessen Telemetriedaten entfernt wurden.

Als Tenant überwachen Sie Auswirkungen, nicht die Hardware. Innerhalb des Gasts sind vier Signale sichtbar: I/O-Fehler (Input/Output-Fehler) im Kernel-Log, ein Dateisystem, das wieder schreibgeschützt eingebunden wird, ansteigende Latenz und ein voller Speicher. Für alle vier Signale können Sie heute Alarme einrichten. Alle vier werden sichtbar, bevor sich ein Benutzer beschwert. Richten Sie diese Überwachung zuerst ein. Die Zuständigkeitsteilung folgt am Ende, weil sie bestimmt, wofür Sie Ihren Aufwand einsetzen sollten.

Was der eigene Server tatsächlich exponiert

Nehmen Sie nicht an, welcher Fall vorliegt. Prüfen Sie zuerst die Ausgabe und lesen Sie anschließend den passenden Abschnitt.

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

virtio-blk, die übliche KVM-Festplatte (kernel-based virtual machine). Das Gerät ist /dev/vda, und smartctl beendet sich, bevor es irgendeine Anfrage sendet:

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

virtio-blk ist ein paravirtualisierter Transport ohne ATA- oder SCSI-Befehlssatz dahinter. Daher gibt es keinen Kanal, über den eine SMART-Anfrage übertragen werden kann. -d sat und -d scsi schlagen aus demselben Grund fehl, weil der Transport das Problem verursacht und nicht das Flag.

Eine emulierte SATA- oder SCSI-Festplatte. Das Gerät ist /dev/sda, und smartctl kommt weit genug, um es zu identifizieren. Die Modellzeile lautet QEMU HARDDISK. Diese Zeichenfolge beantwortet die Frage bereits: Sie lesen ein Gerät, das der Emulator erzeugt hat, und es meldet keine nutzbare SMART-Funktion.

Ein NVMe-Namespace. sudo nvme smart-log /dev/nvme0n1 gibt ein vollständiges Protokoll zurück. Genau dadurch lassen sich viele täuschen. Prüfen Sie zuerst die Controller-Identität mit sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)'. Eine Modellnummer, die ein Network-Storage-Produkt bezeichnet, bedeutet, dass der Controller eine Software ist. percentage_used und media_errors beschreiben dann diese Emulation und nicht den Flash-Speicher, auf dem Ihre Daten liegen. Wenn Sie wissen möchten, welche Speicherhardware tatsächlich verwendet wird, prüfen Sie die NVMe-Festplatte unter Linux, statt der Beschreibung im Tarif zu vertrauen.

Ein Container, beispielsweise LXC (Linux containers) oder OpenVZ. Sie besitzen kein eigenes Blockgerät. lsblk zeigt die Geräte des Hosts oder überhaupt nichts, und smartctl wird abgewiesen, weil der Container CAP_SYS_RAWIO nicht besitzt:

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

Ein Hinweis zu dem Fall, in dem es funktioniert. Wenn smartctl auf einem VPS eine vollständige Attributtabelle zurückgibt, lesen Sie vor weiteren Maßnahmen die Seriennummer. Einige Hosts stellen einen durchgereichten Geräteknoten bereit. Die Zähler gehören dann zu Hardware, die von allen Mandanten auf diesem Computer gemeinsam genutzt wird. Ein steigendes Reallocated_Sector_Ct ist in diesem Fall ein Support-Ticket. Es ist keine Aussage über Ihre Daten.

Signal 1: I/O-Fehler im Kernel-Log

Dies ist das aussagekräftigste Signal, das ein Mieter erhalten kann, und dafür ist kein Agent erforderlich.

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'

Eine fehlgeschlagene Anforderung der virtuellen Festplatte sieht so aus:

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

Die Blockschicht forderte den Host zu einem Schreibvorgang auf, und der Host meldete einen Fehler zurück. Auf einem VPS handelt es sich dabei nur selten um eine ausgefallene Flash-Zelle. Meist liegt die Ursache in der Speicherinfrastruktur des Hosts oder im Netzwerkpfad zu einem netzwerkgebundenen Speicher. Es handelt sich daher um ein providerseitiges Ereignis. Übernehmen Sie den Zeitstempel, den Gerätenamen und den Sektor in Ihr Ticket. Ein Storage-Team kann diese Angaben mit den eigenen Logs abgleichen.

Bei ext4 ist vor allem diese Sequenz relevant:

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

Die zweite Zeile ist kritisch, weil der Rechner weiterläuft. Er antwortet auf Ping und SSH, aber jeder Schreibvorgang schlägt fehl. Eine einfache HTTP-Prüfung bleibt erfolgreich, während Ihre Anwendung bei jeder Anfrage einen Fehler ausgibt.

XFS fährt das Dateisystem stattdessen herunter:

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 liest nur den aktuellen Bootvorgang, sofern das Journal nicht auf dem Datenträger gespeichert wird. Viele Images verwenden ein flüchtiges Journal, das im RAM liegt. Aktivieren Sie die Persistenz. Andernfalls verschwinden die Beweise genau bei dem Reboot, den Sie während der Fehleranalyse durchführen werden.

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

Nach Ihrem nächsten Reboot sollte journalctl --list-boots mehr als einen Bootvorgang auflisten. Auch bei aktivierter Persistenz kann ein Dateisystem, das in den schreibgeschützten Modus gewechselt ist, nicht mehr protokollieren, was danach passiert ist. Das ist ein wesentlicher Grund, Logs vom System weg an einen externen Speicher zu übertragen.

Signal 2: ein schreibgeschütztes Remount erkennen

Machen Sie den Fehler sichtbar, bevor Sie versuchen, ihn zu erkennen.

findmnt -no SOURCE,FSTYPE,OPTIONS /

Suchen Sie in den Optionen nach errors=remount-ro. Ubuntu- und Debian-Cloud-Images setzen diese Option in /etc/fstab. Dadurch wird das Dateisystem bei einem Metadatenfehler schreibgeschützt eingebunden, statt trotz der Beschädigung fortzufahren. Wenn die Option fehlt, fügen Sie sie in /etc/fstab zum Root-Eintrag hinzu oder setzen Sie sie mit sudo tune2fs -e remount-ro /dev/vda1 im Superblock. Ein sichtbarer Abbruch ist besser als eine unbemerkte Beschädigung.

Ein Mount-Flag ist kein Beweis. Prüfen Sie das Schreiben durch einen Test:

touch /var/tmp/.disk-probe

Auf einem schreibgeschützten Root-Dateisystem wird genau Folgendes ausgegeben:

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

Verwenden Sie /var/tmp, nicht /tmp. Auf den meisten Images ist /tmp ein im Arbeitsspeicher gehaltenes tmpfs. Ein erfolgreicher Schreibvorgang dort sagt daher nichts über Ihre Festplatte aus.

Kombinieren Sie den Schreibtest mit einer Prüfung des verfügbaren Speicherplatzes. Senden Sie den Heartbeat nur, wenn alle Prüfungen erfolgreich sind:

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 in der letzten Zeile bedeutet, dass die gesamte Befehlskette funktioniert. set -eu beendet den Befehl bei jeder fehlgeschlagenen Prüfung mit einem Status ungleich 0, bevor die Zeile curl ausgeführt wird. Dadurch wird kein Heartbeat gesendet. Genau das ist der Zweck: Der Monitor zeigt einen Fehler an, weil nichts eingetroffen ist. Ein Server, der nicht schreiben kann, ist nicht vertrauenswürdig, wenn er sein eigenes Problem beschreiben soll. Lesevorgänge funktionieren auf einem schreibgeschützten Dateisystem weiterhin. Daher startet das Skript selbst noch.

Führen Sie es über einen systemd-Timer aus.

# /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 sollte die Unit mit einer NEXT Zeit anzeigen, die weniger als fünf Minuten entfernt ist. Ein fehlgeschlagener Lauf erscheint in journalctl -u disk-probe.service zusammen mit der Fehlermeldung der Shell. Dadurch können Sie ein schreibgeschütztes Dateisystem von einem vollen Dateisystem unterscheiden, ohne sich anzumelden.

Diese Push-URL gehört zu einem Uptime-Kuma-Push-Monitor. Erstellen Sie einen Monitor vom Typ Push, kopieren Sie dessen Token in das Skript und setzen Sie das Heartbeat-Intervall des Monitors etwas länger als das Timer-Intervall. Dadurch löst ein langsamer Lauf um 03:00 keinen Alarm aus. Wenn Sie noch keine Statusseite haben, ist eine selbst gehostete Uptime-Kuma-Instanz der kostengünstigste Ort für diese Prüfung.

Zwei wichtige Einschränkungen. Die Prüfung bestätigt, dass ein Schreibvorgang angenommen wurde. Sie bestätigt nicht, dass die Bytes auf einem dauerhaft gespeicherten Medium angekommen sind, weil der Lesevorgang aus dem Page Cache bedient werden kann. Außerdem läuft die Prüfung auf dem überwachten Rechner. Ein vollständig blockierter Server bleibt daher stumm, statt eine Diagnose zu melden.

Signal 3: Trends bei Latenz und Durchsatz

sudo apt install -y sysstat
iostat -xdz 5 3

Lesen Sie zuerst r_await und w_await. Sie geben die durchschnittliche Zeit in Millisekunden an, die ein Lese- oder Schreibvorgang benötigt hat, einschließlich der Wartezeit in der Warteschlange. Lesen Sie anschließend aqu-sz, die durchschnittliche Anzahl gleichzeitig laufender Anfragen. Ignorieren Sie %util auf einer virtuellen Festplatte: Der Wert bedeutet nur, dass die Warteschlange nicht leer war. Ein Gerät, das viele Anfragen parallel verarbeitet, kann nahe bei 100 Prozent liegen, obwohl es noch weit von seiner Auslastungsgrenze entfernt ist. await ist der Wert, der die wahrgenommene Leistung bestimmt.

Absolute Werte sind weniger wichtig als Ihre eigene Baseline. Erfassen Sie daher eine ruhige Stunde und bewahren Sie die Werte auf. /proc/diskstats ist die Rohquelle, falls Sie die Zähler lieber selbst erfassen möchten.

Für eine gezielte Messung:

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

Lesen Sie den Block clat percentiles, insbesondere den 99. Perzentilwert. --direct=1 umgeht Ihren Page Cache. Der Cache des Hosts wird jedoch nicht umgangen. Das Ergebnis beschreibt daher den gesamten Pfad von Ihrem Prozess bis zum Speicher des Hostsystems. Führen Sie den Test aus, wenn der Server nicht ausgelastet ist, da er mit Ihrer eigenen Workload konkurriert.

Steigendes await ohne Fehler im Kernel-Log weist normalerweise nicht auf ein ausfallendes Laufwerk hin. Ursache ist eine Konkurrenz um Ressourcen auf dem Host. Bei Speicher entspricht das dem CPU-Steal-Time durch einen lauten Nachbarn. Wenn der Wert jeden Tag zur gleichen Stunde wieder ansteigt und Ihr Ticket ohne Befund geschlossen wird, benötigen Sie einen Tarif, dessen I/O nicht auf dieselbe Weise gemeinsam genutzt wird. Das ist bei einem Storage-VPS gegenüber einem normalen VPS der Fall, wenn die Workload durch den Speicher begrenzt ist.

Signal 4: Dateisystemprüfungen, die Sie im eingehängten Zustand ausführen können

ext4 führt im Superblock einen Fehlerzähler. Dieser bleibt auch nach einem Reboot erhalten, selbst wenn Ihre Logs nicht mehr verfügbar sind.

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

Ein fehlerfreies Dateisystem gibt Filesystem state: clean und FS Error count: 0 aus. clean with errors und ein Wert ungleich null bedeuten, dass der Kernel irgendwann einen Metadatenfehler festgestellt hat. Das gilt auch dann, wenn niemand ihn bemerkt hat und das Log bereits rotiert wurde. Dieser eine Befehl gehört in eine wöchentliche Prüfung.

Sie können kein fsck auf einem eingehängten Root-Dateisystem ausführen. Außerdem meldet e2fsck -n auf einem aktiven Dateisystem Probleme, die nur dadurch entstehen, dass sich die Daten während der Prüfung ändern. Für eine echte Prüfung fügen Sie fsck.mode=force fsck.repair=yes für einen Bootvorgang an der Kernel-Befehlszeile hinzu. Verwenden Sie dafür die Konsole Ihres Providers. systemd-fsck führt die Prüfung dann aus, bevor das Root-Dateisystem mit Schreibzugriff eingehängt wird.

XFS bietet keine Online-Prüfung. xfs_repair -n /dev/vda1 verweigert die Ausführung auf einem eingehängten Dateisystem. Der Befehl gehört daher in den Rescue-Modus. XFS hat dafür einen anderen Vorteil: Bei einem Metadatenfehler fährt es das Dateisystem herunter, statt den Betrieb fortzusetzen.

Bei Btrfs sind die Zähler integriert und dauerhaft.

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

write_io_errs oder corruption_errs größer als null ist ein tatsächliches Ereignis. Die Zähler behalten ihre Werte über Reboots hinweg, bis Sie sie zurücksetzen. scrub liest jeden Block erneut und prüft seine Prüfsumme. Das kommt einem Medientest auf einer virtuellen Festplatte am nächsten. Der Vorgang verursacht viel I/O. Planen Sie ihn daher für eine ruhige Betriebszeit ein.

Signal 5: freier Speicherplatz einschließlich der von df nicht angezeigten Bereiche

Wenn der Speicherplatz ausgeht, fällt ein Server genauso aus wie bei einem defekten Datenträger. Das passiert jedoch deutlich häufiger.

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

No space left on device, während df -h freien Speicherplatz anzeigt, bedeutet, dass Ihnen nicht Bytes, sondern Inodes ausgegangen sind. df -i zeigt IUse% mit 100 Prozent an. Millionen kleiner Dateien in einem Cache-Verzeichnis oder einer Mail-Spool verursachen dieses Problem. Das Löschen großer Dateien hilft dann nicht.

Speicherplatz, der nach dem Löschen nicht wieder verfügbar wird, gehört meist zu einer gelöschten Datei, die von einem laufenden Prozess weiterhin geöffnet ist. sudo lsof +L1 listet Dateien auf, deren Link-Anzahl auf null gesunken ist. Ein Neustart des Prozesses, der eine solche Datei geöffnet hält, gibt den Speicherplatz frei.

Das Journal ist ein häufiger, unauffälliger Speicherverbraucher. journalctl --disk-usage zeigt an, wie viel Speicherplatz es belegt. Begrenzen Sie die Größe mit SystemMaxUse=200M in /etc/systemd/journald.conf und führen Sie anschließend sudo systemctl restart systemd-journald aus. Geben Sie den Speicherplatz sofort mit sudo journalctl --vacuum-size=200M frei.

Ein Fall sieht wie ein Fehler aus, ist aber keiner. Bei Thin Provisioning kann sich der Pool des Hosts füllen, während df im Gast weiterhin freie Gigabytes anzeigt. Ihre Schreibvorgänge schlagen dann mit I/O-Fehlern im Kernel-Log fehl. Innerhalb des Gasts erscheint dabei keine Warnung über fehlenden Speicherplatz. Fehler ohne ein volles Dateisystem sind eine Kombination, für die Sie noch in derselben Stunde ein Ticket erstellen sollten.

Signale in einen Metrik-Agenten einbinden

Eine Push-Prüfung liefert Ja oder Nein. Für Trends benötigen Sie einen Metrik-Agenten. Prometheus node_exporter exportiert bereits alle oben genannten Werte ohne zusätzliche Konfiguration. Auf diesen Metriknamen können Sie aufbauen:

• node_filesystem_readonly wird auf 1 gesetzt, wenn ein Mount schreibgeschützt ist. Das ist Ihr Alarm für ein erneutes Einhängen.
• node_filesystem_avail_bytes und node_filesystem_files_free erfassen Bytes und Inodes getrennt.
• node_disk_io_time_seconds_total und node_disk_read_time_seconds_total liefern Auslastungszeit und Latenz als Zähler, die Sie grafisch darstellen können.

Zwei Regeln erfassen die Fälle, die tatsächlich einen Pager-Alarm auslösen:

- 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

Die zweite Regel wird ausgelöst, wenn der aktuelle Trend innerhalb von vier Tagen null erreicht. Dadurch werden Sie mehrere Tage im Voraus gewarnt und nicht erst bei 95 Prozent Auslastung, wenn nur noch wenige Minuten bleiben.

Wer wofür verantwortlich ist

Ihr Provider ist für die physischen Laufwerke verantwortlich. Er liest SMART-Daten aus, betreibt das Array und ersetzt ein Laufwerk mit steigenden Reallocated-Sector-Werten normalerweise, ohne Sie zu informieren, weil das Array den Ausfall abfängt. Genau dafür gibt es RAID 10 unter Ihrem VPS: Aus einem ausgefallenen Laufwerk wird ein Rebuild statt eines Ausfalls. Sie können davon nichts sehen. Für diese Abstraktion zu bezahlen, ist einer der Hauptgründe für das Mieten eines virtuellen Servers.

Sie sind für Ihre Daten verantwortlich. Die Laufwerks-Telemetrie würde Ihre Daten ohnehin nicht schützen. Ereignisse, die Mandantendaten tatsächlich zerstören, sind ein fehlerhaftes rm, ein fehlerhaftes Deployment, ein Angreifer mit Ihrem SSH-Schlüssel und ein Plattformvorfall, der auch das Array außer Betrieb setzt. SMART-Attribute sagen keines dieser Ereignisse voraus.

Der tatsächliche Schutz eines Mandanten besteht daher aus einem Backup außerhalb des Servers und einer Wiederherstellung, die Sie selbst durchgeführt haben. Provider-Snapshots sind praktisch. Sie liegen jedoch auf derselben Plattform wie das, was sie schützen. Deshalb sind Snapshots und Backups unterschiedliche Schutzmaßnahmen. Planen Sie einen Wiederherstellungstest ein: Stellen Sie einmal pro Quartal das neueste Backup in einem neuen VPS wieder her, starten Sie die Anwendung und notieren Sie, wie lange der Vorgang gedauert hat. Diese Zeit ist Ihre tatsächliche Wiederherstellungszeit. Der erste Test dauert immer länger als erwartet.

Wann SMART auf Sie zutrifft

Anleitungen zu smartctl sind korrekt. Sie gelten, sobald die Hardware tatsächlich Ihnen gehört:

• Ein dedizierter oder Bare-Metal-Server, bei dem sudo smartctl -a /dev/sda die vollständige Attributtabelle zurückgibt und smartd Sie per E-Mail benachrichtigen kann, wenn sich ein Attribut ändert.
• Storage-Tarife, bei denen ein physischer Datenträger direkt an den Gast durchgereicht wird. Anbieter weisen ausdrücklich darauf hin, weil dies ein Verkaufsargument ist.
• Hardware, die Sie selbst besitzen, zu Hause oder in gemieteter Rack-Fläche.
• Ein Datenträger hinter einem RAID-Controller, der mit sudo smartctl -a -d megaraid,0 /dev/sda erreichbar ist, oder ein USB-Gehäuse mit -d sat.

Auf echten NVMe-Datenträgern melden sudo smartctl -a -d nvme /dev/nvme0 und sudo nvme smart-log /dev/nvme0n1 die Werte critical_warning und percentage_used direkt vom Laufwerk. Auf echten SATA-Datenträgern sind die ausfallprognostisch relevanten Attribute Reallocated_Sector_Ct (5), Current_Pending_Sector (197), Offline_Uncorrectable (198) und Reported_Uncorrect (187). Sobald einer dieser Werte von null abweicht, sollten Sie einen Austausch einplanen. Groß angelegte Laufwerksstudien kommen immer wieder zu derselben kurzen Liste. Die meisten anderen Attribute sind Rauschen.

Starten Sie den Daemon, anstatt die Prüfung manuell durchzuführen.

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

Das Selbsttestprotokoll sollte für den gerade gestarteten Lauf Completed without error anzeigen. Ubuntu und Debian liefern /etc/smartd.conf mit einer DEVICESCAN-Zeile aus, Stand August 2026. Der Daemon erkennt dadurch jeden sichtbaren Datenträger und sendet root bei einer Änderung eine E-Mail. Auf einer virtuellen Festplatte funktioniert dies nicht. Deshalb gibt es den restlichen Teil dieser Anleitung.

FAQ

Warum funktioniert smartctl auf meinem VPS nicht?

Weil der Datenträger virtuell ist. Auf einem KVM-Gast mit virtio-blk gibt smartctl -a /dev/vda /dev/vda: Unable to detect device type aus, weil ein paravirtualisierter Datenträger keinen ATA- oder SCSI-Befehlskanal für eine SMART-Anfrage bereitstellt. Bei einem emulierten Datenträger erreichen Sie ein Gerät, dessen Modell QEMU HARDDISK lautet und hinter dem keine nutzbaren SMART-Daten verfügbar sind. In einem Container wird smartctl mangels CAP_SYS_RAWIO direkt abgewiesen. Keine dieser Situationen ist eine Fehlkonfiguration, und kein -d-Flag behebt sie.

Woran erkenne ich, dass der Datenträger meines VPS ausfällt?

Überwachen Sie die Auswirkungen, nicht die Hardware. Prüfen Sie sudo journalctl -k -p err -b auf blk_update_request: I/O error-Zeilen und auf Remounting filesystem read-only. Führen Sie sudo dumpe2fs -h /dev/vda1 | grep -i 'error count' aus, um Fehler zu finden, die aus den Logs bereits verschwunden sind. Verfolgen Sie r_await aus iostat -xdz 5 und vergleichen Sie den Wert mit einer Referenz, die Sie bei ordnungsgemäßem Betrieb aufgezeichnet haben. Auf einem VPS weist ein I/O-Fehler normalerweise auf ein Speicherproblem des Hosts und nicht auf einen ausfallenden Datenträger hin. Er gehört daher mit Zeitstempel und Sektorangabe in ein Support-Ticket.

Worauf sollte ich bei der Überwachung des Datenträgerzustands eines VPS alarmieren?

Vier Alarme decken die wichtigsten Fälle ab. Ein schreibgeschütztes Mount, verursacht durch node_filesystem_readonly == 1 oder durch eine fehlschlagende Schreibprüfung. Freier Speicherplatz und freie Inodes, die gegen null tendieren. Jeder Kernel-I/O error im letzten Intervall. Ein Heartbeat des Servers, damit Sie alarmiert werden, wenn das System nicht mehr antwortet. Ignorieren Sie alles, was aus SMART abgeleitet wird, da diese Werte auf einem virtuellen Datenträger entweder fehlen oder die Emulation des Hypervisors beschreiben.

Warum wurde mein Dateisystem schreibgeschützt erneut eingehängt?

ext4 führt dies bei einer Einbindung mit errors=remount-ro absichtlich durch, wenn ein Metadatenfehler auftritt. Das Dateisystem beendet Schreibvorgänge, statt die Beschädigung zu verschlimmern. Der Auslöser steht im Kernel-Log direkt oberhalb der Zeile zum erneuten Einhängen. Meist handelt es sich um einen EXT4-fs error zu einem abgebrochenen Journal, nachdem das zugrunde liegende Gerät einen I/O-Fehler zurückgegeben hat. Wenn Sie das Dateisystem ohne Prüfung wieder schreibbar einhängen, verbergen Sie das Symptom und lassen die Ursache bestehen. Sichern Sie das Log und prüfen Sie das nicht eingebundene Dateisystem anschließend aus dem Rescue-Modus mit e2fsck -fy /dev/vda1.

Kann ich SMART-Daten auf einem virtuellen Server überhaupt auslesen?

In bestimmten Fällen ja. Dedizierte und Bare-Metal-Server stellen reale Attribute bereit. Das gilt auch für Storage-Tarife, die einen physischen Datenträger an den Gast durchreichen, sowie für jeden Host, den Sie selbst verwalten. Einige Plattformen präsentieren dem Gast einen NVMe-Controller, und nvme smart-log gibt ein Log zurück. Führen Sie daher zuerst sudo nvme id-ctrl /dev/nvme0 aus: Eine Modellnummer, die einen Network-Storage-Dienst bezeichnet, bedeutet, dass diese Zähler von einem Software-Controller stammen. Wenn ein Passthrough-Gerät auf einem gemeinsam genutzten System reale Zähler bereitstellt, beschreiben diese außerdem Hardware, die mit anderen Mandanten geteilt wird. Die einzig sinnvolle Maßnahme ist dann ein Support-Ticket.