Proxmox hängt sich auf wenn der Trim/Scrub Cronjob startet

[shanoviachan]

Hallo zusammen
ich habe mich immer montlich über eine Komplettausfall meines Servers gewundert. Nun konnte ich die Uhrzeit genau feststellen und vermute das es mit dem Cronjob am zweiten Sonntag im Monat um 0:24 zu tun haben muss.

Sobald der Vorgang gestartet wird, fällt der Server aus. Nur ein Neustart hilft. Anschließend sehe ich das meine NAS ZFS (seperate SSD, Nur Dateiablage) als degregated und untrimed angezeigt wird. Starte ich nun scrub manuell, findet er Fehler aber kann diese auch sofort beheben. Dann geht die Platte wieder online.

Die Logs sind leider leer, weil der Server offensichtlich sofort abstürzt.

Zu meinem System:
- Proxmox 8.0.3
- 3 SSD, davon eine für Proxmox und Container sowie eine für NAS und eine für Backups.

Kennt jemand den Fehler und hat eine Lösung für mich? Temporär habe den den Trim Job deaktiviert, aber das ist ja auch nicht die Lösung.

Besten Dank
Shano

 

[Dunuin]

Was für Fehler kommen denn beim Scrub? Read/Write Fehler oder Checksum-Fehler?
Ist da dein IO Delay hoch wenn der Scrub läuft?

 

[shanoviachan]

Also gestern Nacht konnte ich beobachten, das der Fehler vermutlich eher am Trimmen als am Scrubben liegt. Denn der Scrub Job ist nach dem manuellen Reboot durchgelaufen. Den IO Delay habe ich zum Zeitpunkt des Ausfalls nicht nachvollziehen können, weil mit Start des Prozesses um 0:24 wirklich alles tot ist. Starte ich den ScrubJob dann manuell sind die Werte für IO Delay niedrig.

Beim Scrubben kam folgendes Ergebniss für mein NAS ZFS:

status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
        
        DEGRADED 26.7K     0 98.3K  too many errors

Ich habe dann gecleared und den Scrub noch mal manuell angestoßen. Dabei sind dann keine Fehler mehr gefunden. Erstmalig kam der Fehler mit einem monatlichen Job nachdem zwei Dinge passiert waren:
- Update auf die Proxmox Version 8.x
- Ein ZFS Pool hat mir einen IO Error gemeldet. Da ich den Pool an OMV gegeben hatte und dort ein eigenes Dateisystem drauf lief, habe ich nur noch den Neustart gesehen und sowohl das Dataset als auch den ZFS Pool durch formatieren neu zu erstellen

 

[Dunuin]

Ich habe dann gecleared und den Scrub noch mal manuell angestoßen.

Clearen ignoriert nur die Fehler und as macht auch höchstens bei Read/Write Fehlern Sinn. Du hast unzählige Checksum Fehler also Datenverlust.
Kannst du natürlich ignorieren, aber dann bleiben die Daten trotzdem kaputt, auch wenn der Pool dann sagt alles wäre heil, weil du den Error-Counter zurücksetzt.
Wenn du ohne ein "zpool clear" nach einem Scrub immer noch Checksum-Fehler siehst, dann würde ich die Disk austauschen und dann alles an Daten aus einem Backup zurückspielen, was erstellt wurde, bevor die ersten Checksum-Fehler aufgetreten sind.

 

[shanoviachan]

Ok, das heißt du würdest diese Fehler als Ursache dafür das der TrimJob den ganzen Proxmox Host schmeißt?

Dann villeicht eine dumme Frage, aber wie finde ich heraus ob ggf in meinem Backup fehlerhafte Dateien sind. Mein Backup hier ist im Grunde ein entfernter Host mit Dateien im Klartext`?

 

[Dunuin]

Dann villeicht eine dumme Frage, aber wie finde ich heraus ob ggf in meinem Backup fehlerhafte Dateien sind. Mein Backup hier ist im Grunde ein entfernter Host mit Dateien im Klartext`?

Das kannst du den Backups nicht entnehmen. Wenn etwas schon vor dem Backup korrumpiert war, dann ist es folglich auch im Backup defekt.
Deshalb hat man ja die Scrub-Jobs und Checksumming bei ZFS, dass man weiß, wann da die Arbeitskopie der Daten defekt geht und man das neuste Backup von vor dem letzten fehlerfreien Scrub-Job restoren kann. Alles was nach dem letzten fehlerfreien Scrub hinzugefügt/editiert wurde kann dann ja schon defekt sein und damit sich dann auch all die Backups, die nach diesem Zeitpunkt erstellt wurden, unbrauchbar.

Da musst du dann in deine Logs/Monitoring gucken, wann das erste mal Checksum-Fehler ausgetreten sind.