Proxmox Oberfläche nach Stromausfall nicht mehr erreichbar

[ThoSo]

ich denke aber nach wie vor über diesen vorschlag nach: https://forum.proxmox.com/threads/proxmox-oberfläche-nach-stromausfall-nicht-mehr-erreichbar.150913/post-858361

Wenn auf der Backup-Platte die Optionen für VM / CT aktiv sind, kannst auf dieser eine VM/CT erstellen und das testen.

und nach einem kleinen malheur konnte ich auch das Backup auf der 1TB Platte wiederherstellen.
danach hab ich die originale VM runter und die neu erstellte hochgefahren.

Was war das den für ein malheur? Nur falls es die nicht Funktionalität deines Restores erklären könnte.

Dein ExitCode 255 kann alles sein - da es aber wohl Docker APPS sind, wäre das Dogger-Log dann die erste interessante Anlaufstelle.
Als erstes würde ich da mal auf das erreichen der Datebank tippen (Netzwerk, IP) - Aber wie auch @TErxleben passe ich da.
Dann meckert er das nicht finden einer Backup-Datei an.

Bezüglich des Wearout N/A :
Entweder sind im BIOS SMART deaktiviert, die Tools (smartctl) nicht installiert, oder der Controller / die SSD gibt das nicht her.
Könnte man jetzt am schnellsten extern mit einem Livesystem (LinuxMint) via USb Stick prüfen.
Evtl. läuft der SATA Controller im RAID (meist ein Default bei Intel) - das würde ich bei einer Neuinstallation mir dann überlegen und den im AHCI Modus laufen lassen.

 

[lethuer]

Was war das den für ein malheur? Nur falls es die nicht Funktionalität deines Restores erklären könnte.

ich hatte zuerst versehentlich auf local aus dem backup erstellt. dann lief das system natürlich voll. hab ich aber wieder gelöscht und proxmox einmal neu gestartet.

Evtl. die Restore-VM gestartet, bevor die Ursprungs-VM heruntergefahren wurde?

habs nochmal probiert... versucht erst die eigentliche VM herunterzufahren. da bekomme ich aber:
TASK ERROR: VM quit/powerdown failed - got timeout
beim start der backup vm dann wieder dasselbe.


Dann Proxmox neu gestartet ohne das die eigentliche VM beim boot gestartet wird.
dann die neue BackupVM gestartet, leider wieder dasselbe...
Weiß jetzt nicht wie ich das auf der Backup Platte ans laufen bekommen soll.
Nach Eingabe von ha supervisor logs


Ein Gedanke war es nun auf local eine neue kleinere VM zu erstellen.
Wenn ich da nun HomeAssistant installiere kann ich versuchen mein BuildIn HomeAssistant Backup wieder einzuspielen...

Wenn auf der Backup-Platte die Optionen für VM / CT aktiv sind, kannst auf dieser eine VM/CT erstellen und das testen.

Welche Optionen sind gemeint ?
Das wäre ja dasselbe wie das backup auf der backup platte wiederherzustellen. das startet (noch) nicht,

 

[ThoSo]

Die Einstellungen unter Storage im Datacenter für den Mountpoint.
die am besten Mail posten.

 

[Falk R.]

Der USB Stick wird der Zigbee Stick sein, evtl. muss der USB Port irgendwie noch an die VM durchgeleitet werden und das ist nicht bestandteil des Backups ?
Ja und die InfluxDB liegt halt auf dem Container 100, der ist aber an...

Die ursprüngliche VM läuft auch vorerst wieder.

Wenn das System nicht in die Influx schreiben kann, schreibt der das als Caching auf die lokale Disk. Daher unbedingt die Influx Connection kontrollieren.

 

[lethuer]

Die Einstellungen unter Storage im Datacenter für den Mountpoint.
die am besten Mail posten.

meinst du das ?

Daher unbedingt die Influx Connection kontrollieren.

Wie soll ich das prüfen ? Ich habe ja nur das Backup auf der 1TB Backup Platte wieder hergestellt, mit der originalen VM läuft es ja.

 

[Falk R.]

Wie soll ich das prüfen ? Ich habe ja nur das Backup auf der 1TB Backup Platte wieder hergestellt, mit der originalen VM läuft es ja.

Du hast eine Verbindung zu der Influx DB wo auch immer eingerichtet. Bitte prüfe ob die InfluxDB deine Daten empfängt. Wenn die Daten alle in der InfluxDB abrufbar sind, ist alles OK. Sonst schaue mal wie du die InfluxDB eingerichtet hast, ob sich eine IP geändert hat oder DNS korrekt funktioniert

 

[lethuer]

Ein Gedanke war es nun auf local eine neue kleinere VM zu erstellen.
Wenn ich da nun HomeAssistant installiere kann ich versuchen mein BuildIn HomeAssistant Backup wieder einzuspielen...

Die VM habe ich einfach mal aufgesetzt, analog zu dieser Video Anleitung: https://youtu.be/CXBqeis7fgc?si=MCxiRGLzp-KdBM0D
Und Simon42 beschreibt hier was bei der Migration von einem HomeAssistant Backup zu beachten ist: https://youtu.be/3VBrObuwWac?si=JSYILOdJeL7vmQL7

Das habe ich so gemacht und es scheint alles zu laufen, ich würde das jetzt also auf der neuen VM (64GB) vorerst so betreiben bis die neue Platte da ist.
HomeAssistant zeigt mir nach Einspielen des Backups allerdings an, dass nur rund 30% von den jetzt vergebenen 64GB belegt sind, das wären 19,2GB.
43,7GB sind noch frei, 48GB hätten es also auch erstmal getan.
Jetzt komme ich ja doch wieder ans Überlegen alles auf der 128GB weiter laufen zu lassen...
Ich vermute aber das die HomeAssistant Installation mit der Zeit wieder anwachsen wird und würde dennoch die Platte tauschen um da ein für alle mal Ruhe zu haben...
Oder sind das alles alte Leichen gewesen die bei einer Neuinstallation über ein Backup nicht mit eingespielt werden und die man innerhalb von HomeAssistant mal hätte löschen können weil da unnötige Daten rumlagen ?



Den alten überflüssigen Container 101 (Grafana) habe ich gelöscht.
Die Proxmox Backups von InfluxDB + HomeAssistant laufen manuell durch.
Den Backup Modus habe ich jetzt wie ebenfalls von Simon im Video erwähnt auf "Stop" gesetzt.
Ist das so auch von euch empfohlen ?
Blöd ist natürlich, dass HomeAssistat zu Beginn des Backups nicht erreichbar ist, was aber auch nur ca. 2min sind.




Theoretisch könnte ich ja nun auch die alte HomeAssistant VM löschen, dann müsste das Problem der Überprovisionierung damit ja auch erstmal erledigt sein ?
Zumindest wenn gemeinsam mit dem vergebenen Speicher des InfluxDB Containers die Gesamtkapazität nicht überschritten ist.
Aktuell werden im local-lvm für die neue HomeAssistant VM 68.72GB (eigentlich 64GB zugewiesen) bzw. für InfluxDB 37.58GB (eigentlich 35GB zugewiesen) von insgesamt vorhandenen 86.16 GB angezeigt,
Wenn ich jetzt den Speicher der InfluxDB auf 86.16GB - 68.72GB = 17,44GB reduziere sollte doch nichts mehr passieren können ?
Das wäre allerdings sehr knapp, da aktuell laut Anzeige bereits rund 15GB verwendet werden.

Es sei denn ich mache die Übung nochmal und vergebe eben doch nur 48GB für HomeAssistant
Dann wären es statt 17,44GB eben 33,44GB was ja tatsächlich in etwa die aktuelle Größe der InfluxDB entspricht.

 

[lethuer]

In meinem letzten Post habe ich jetzt einen funktionierenden Weg beschrieben wie ich ein HomeAssistant Backup wieder in eine neue VM einspielen kann, Hier geht es letztlich aber noch um den Weg auch über proxmox selber das gesamte System schnell umziehen zu können was für den Fall des neuen Systems sicher deutlich angenehmer wäre.
Ansonsten hätte ich mit den proxmox Backups ja auch nichts gewonnen wenn die im Zweifel nicht funktionieren...

Du hast eine Verbindung zu der Influx DB wo auch immer eingerichtet. Bitte prüfe ob die InfluxDB deine Daten empfängt. Wenn die Daten alle in der InfluxDB abrufbar sind, ist alles OK. Sonst schaue mal wie du die InfluxDB eingerichtet hast, ob sich eine IP geändert hat oder DNS korrekt funktioniert

Sorry da komm ich wieder nicht ganz mit. InluxDB ist bei mir ein separater Container und der läuft auch, die IP Adresse davon kann sich also nicht geändert haben.
Ich habe jetzt mein frisch aufgesetztes System von oben einmal gesichert und proxmox neu gestartet ohne die HomeAssistant VM zu starten.
Dann habe ich wieder das Backup auf der externen Platte wiederhergestellt.

InfluxDB ist über den Webbrowser über die normale iP Adresse erreichbar.
Dieses mal sind die VM und auch HomeAssistant ohne Murren gestartet, ist auf der externen Platte aber spürbar langsamer.
Ich habe zwar keine Ahnung was der Unterschied zu vorher ist aber so wäre nun auch das Proxmox Backup für ein neu aufgesetztes System nutzbar !



Nach diesem erfolgreichen Test habe ich nun die auf der Backup Platte erstelle VM wieder gestoppt und die neue 64GB VM auf der SSD wieder gestartet.
Die alte 128GB VM habe ich nun gelöscht um einfach wieder Platz zu schaffen (hatte so gerade beides noch auf local-lvm gepasst).
Vor dem neu Aufsetzen von proxmox würde ich mit der InfluxDB dann gerne noch von Container auf VM wechseln.
Wie ziehe ich mit meinem InfluxB (bisher Container) dann auf eine VM um ?

Selbstverständlich kannst du LVM statt Thin-LVM als Basis wählen.

Magst du mir schon mal erklären wie ich das wähle ? Ist das bei der Installation von Proxmox selber zu beachten oder bei der Erstellung von VM's ?
Simon downloaded in seinem Video hier das zu dem Zeitpunkt aktuelle Proxmox VE: https://youtu.be/EsNPqoHAjs0?si=S5B0RP30B06lAOKt&t=593
Aktuell müsste das ja 9.2 sein: https://www.proxmox.com/de/downloads/proxmox-virtual-environment/iso/proxmox-ve-9-2-iso-installer

 

[Impact]

das die HomeAssistant Installation mit der Zeit wieder anwachsen wird

Bitte prüfe doch einfach mal was überhaupt den Platz benutzt. Ich habe dir einen ausführlichen Guide dafür verlinkt.
Du hast mir auch noch keine Antwort darauf gegeben wie lvs nach dem trimming aller Gäste aussieht.

Vor dem neu Aufsetzen von proxmox würde ich mit der InfluxDB dann gerne noch von Container auf VM wechseln.

Das hängt stark ab wie du ihn/es betreibst. Warum?

Magst du mir schon mal erklären wie ich das wähle

Das gibt es im Installer nicht als Option.

Man kann das natürlich manuell machen (maxvz 0?) aber ich sehe nicht wirklich wie LVM helfen soll den Platz optimal auszunutzen. Das ist ja genau warum man Thin-Provisioning nutzt. Pures LVM unterstützt zudem nicht direkt Snapshots außer über die volume chain Option die Dinge nur komplizierter und langsamer macht (und eine Preview ist?). Ich würde empfehlen diesen LVM "Tipp" zu ignorieren. Nutze entweder Standard LVM-Thin (ext4 im Installer) oder wie schon gesagt ZFS. Damit hast du durch Kompression und fehlende Reservation für local sogar mehr Platz.

 

[TErxleben]

Du legst das fest, wenn du einen storage hinzufügst.
Du bist nicht der Erste, dem eine Überprovisionierung auf die Füße fällt. Kann bei LVM eben nicht passieren.

 

[lethuer]

Bitte prüfe doch einfach mal was überhaupt den Platz benutzt. Ich habe dir einen ausführlichen Guide dafür verlinkt.

Die HA Installation ist nach der Wiederherstellung des HA Inbuild Backups deutlich kleiner geworden, hier die aktuelle Verteilung:

Du hast mir auch noch keine Antwort darauf gegeben wie lvs nach dem trimming aller Gäste aussieht.

Das Backup Problem kommt eventuell durch thin_pool_autoextend_threshold=70. Versuche mal manuell zu trimmen oder passe /etc/lvm.conf eventuell an.

Ich hatte mit nano /etc/lvm/lvm.conf die config angepasst (thin_pool_autoextend_threshold = 80) und nicht manuell getrimmt.
Ehrlich gesagt weiß ich auch nach dem lesen des Links nicht wie das manuell funktioniert.

Warum?

Weil doch gesagt wurde das lvm-thin bei 2 maschinen praktisch nichts bringt.
ich dachte jetzt, das container lvm-thin und VM lvm nutzen würde, das scheint aber ein misverstämdmis gewesen zu sein.

Du legst das fest, wenn du einen storage hinzufügst.
Du bist nicht der Erste, dem eine Überprovisionierung auf die Füße fällt. Kann bei LVM eben nicht passieren.

Danke für die Klarstellung ! Hier der Menüpunkt dazu


allerdings wurde auch gesagt, dass nur VM einfach simpler ist und daher dachte ich es wäre einfach ein kluger punkt um auf eine normale VM zu wechseln.

Das ist genau der Grund, warum ich LXCs generell sehr kritisch gegenüber stehe. Die Vermischung zwischen host und client ist einfach zu groß.

Und den punkt würde ich dann auch direkt noch in angriff nehmen...

Bezüglich des Wearout N/A :
Entweder sind im BIOS SMART deaktiviert, die Tools (smartctl) nicht installiert, oder der Controller / die SSD gibt das nicht her.
Könnte man jetzt am schnellsten extern mit einem Livesystem (LinuxMint) via USb Stick prüfen.
Evtl. läuft der SATA Controller im RAID (meist ein Default bei Intel) - das würde ich bei einer Neuinstallation mir dann überlegen und den im AHCI Modus laufen lassen.

>> "Das Tool smartctl ist in dem Paket smartmontools enthalten."


Ich müsste nun also noch im BIOS prüfen ob "SMART" deaktiviert ist ?
SATA Controller auf RAID / AHCI finde ich auch im BIOS und könnte ich jetzt umstellen ?

 

[Impact]

hier die aktuelle Verteilung

Sieht soweit im Rahmen aus. Ich nehme an dass du der VM dieses mal nur 32G gegeben hast?

ich dachte jetzt, das container lvm-thin und VM lvm nutzen würde

Ehrlich gesagt weiß ich auch nach dem lesen des Links nicht wie das manuell funktioniert.

Nein. local-lvm ist immer thin. Daher ist discard und das trimmen ja auch so wichtig sonst wird da nie Platz freigegeben.
Bitte lese den Artikel noch mal oder frage ein LLM ihn einfacher zu erklären denn ich kann es leider nicht. Zumindestens nicht wenn du mir nicht sagst wo du festhängst. Das ist absolut essentiell und sollte die Priorität vor allem anderen sein.

TLDR ist das für CTs (welches auch automatisiert werden sollte)

pct list | awk '/^[0-9]/ {print $1}' | while read ct; do echo "Trimming ${ct}";  pct fstrim ${ct}; done

Und das für VMs

qm list | grep "running" | awk '/[0-9]/ {print $1}' | while read vm; do echo "Trimming ${vm}"; qm guest exec ${vm} -- fstrim -av | jq -r '."out-data"'; done

Das hat aber ein paar Vorraussetzungen wie konfiguriertes discard und den Guest Agent. Ansonsten halt fstrim -av als root innerhalb der VM (braucht auch discard).

VM einfach simpler ist

Finde ich nicht. Ein CT kannst du mit ein paar klicks einrichten und PVE managed die virtuellen Platten für dich. Nicht so bei VMs. Es gbt auch wesentlich mehr Optionen die man verstehen muss. Jeder der schon mal beides (ohne Script) erstellt hat wird das aber sicher selber beurteilen können.

SATA Controller auf RAID / AHCI finde ich auch im BIOS und könnte ich jetzt umstellen ?

Ja, eventuell bootet es dann aber nicht mehr. Musst du probieren. Was sagt denn das?

for disk in /dev/sd[a-z]; do smartctl -a $disk; done

 

[ThoSo]

Ich müsste nun also noch im BIOS prüfen ob "SMART" deaktiviert ist ?
SATA Controller auf RAID / AHCI finde ich auch im BIOS und könnte ich jetzt umstellen ?

Das kannst du dir einmal ansehen - umstellen würde ich das nur, wenn ich eine Neuinstallation mache.

Wie ist den jetzt eigentlich dein Plan, was du machen willst?
Falls nicht wäre eine Bestandsaufnahme inkl. Kosten/Verfügbarkeit von Komponten nützlich zur Entscheidungsfindung.
Auf alle Fälle wäre ein aktuelles PVE auf frischen SSDs sinnvoll!

aus : How long will my Proxmox VE version be supported?

Thread 'Proxmox VE - Support Lifecycle'

Jul 17, 2017

How long will my Proxmox VE version be supported?

Proxmox VE versions are supported at least as long as the corresponding Debian Version is oldstable. Proxmox VE uses a rolling release model and using the latest stable version is always recommended.

Proxmox VE 9
First Release: 2025-08, Debian Version 13 (Trixie), Debian EOL: TBA, Proxmox VE EOL: TBA

Proxmox VE 8
First Release: 2023-06, Debian Version 12 (Bookworm), Debian EOL: 2026-07, Proxmox VE EOL: 2026-08

Proxmox VE 7
First Release: 2021-07, Debian Version 11 (Bullseye), Debian...

• martin
• Replies: 40
• Forum: Proxmox VE: Installation and configuration

• 

Proxmox VE 7
First Release: 2021-07, Debian Version 11 (Bullseye), Debian EOL: 2024-07, Proxmox VE EOL: 2024-07

 

[lethuer]

Ich nehme an dass du der VM dieses mal nur 32G gegeben hast?

nein 64GB, und laut HomeAssistant Anzeige 42GB frei

Nein. local-lvm ist immer thin.

Ich hätte jetzt bei einer neuinstallation beim Hinzufügen eines Storage nur noch "LVM" genutzt und eben kein "LVM-Thin" mehr.
ich dachte dann sei auch "local-lvm" nur noch "LVM" und kein "LVM-Thin" mehr...?!

Danke für die Klarstellung ! Hier der Menüpunkt dazu

Das hat aber ein paar Vorraussetzungen wie konfiguriertes discard und den Guest Agent. Ansonsten halt fstrim -av als root innerhalb der VM (braucht auch discard).

Für den Container kann ich keine "Discard" Option finden.



"Discard" ist in der HomeAssistant VM aber aktiv, zu finden unter VM->Hardware->Hard Disk

Daher ist discard und das trimmen ja auch so wichtig sonst wird da nie Platz freigegeben.

TLDR ist das für CTs (welches auch automatisiert werden sollte)

und da viel mir jetzt dieser post wieder ein, anscheinend hatte ich bereits einen cron job für die container angelegt:

L

Post in thread 'local-lvm wird voll'

Apr 19, 2024

Okay das ist krass... ich habe diesen kommentar gefunden:
https://community.home-assistant.io/t/trim-on-an-external-ssd-for-the-rpi/226649/7

Rund 38GB frei geworden, damit hat sich eine neue platte erst einmal erledigt
Die "fstrim" Automation wird jetzt jede nacht um 4 aus HomeAssistant heraus durchgeführt.



Bleibt eigentlich nur noch das offen für die container:

Wäre das so korrekt automatisiert für die container ?

• lethuer

nano /etc/crontab


testweise hiermit nochmal manuell getrimmt:

root@proxmox:~# pct fstrim 100
/var/lib/lxc/100/rootfs/: 304.8 MiB (319586304 bytes) trimmed

und für die VM hatte ich innerhalb von HomeAssistant eine "fstrim" Automation angelegt.

alias: fstrim
description: ""
initial_state: "on"
triggers:
  - at: "04:00:00"
    trigger: time
actions:
  - data: {}
    action: shell_command.fstrim

Was sagt denn das?
for disk in /dev/sd[a-z]; do smartctl -a $disk; done

Linux proxmox 5.15.131-2-pve #1 SMP PVE 5.15.131-3 (2023-12-01T13:42Z) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Jun 25 20:15:55 CEST 2026 on pts/0
root@proxmox:~# for disk in /dev/sd[a-z]; do smartctl -a $disk; done
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.15.131-2-pve] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Toshiba HG6 Series SSD
Device Model:     TOSHIBA THNSNJ128G8NU
Serial Number:    956B50RXKFHX
LU WWN Device Id: 5 00080d c002ac1bd
Firmware Version: JUXA0102
User Capacity:    128,035,676,160 bytes [128 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      < 1.8 inches
TRIM Command:     Available, deterministic, zeroed
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2 (minor revision not indicated)
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Thu Jun 25 20:30:27 2026 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
See vendor-specific Attribute list for marginal Attributes.

General SMART Values:
Offline data collection status:  (0x00) Offline data collection activity
                                        was never started.
                                        Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever
                                        been run.
Total time to complete Offline
data collection:                (  120) seconds.
Offline data collection
capabilities:                    (0x5b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        No Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        (   5) minutes.
SCT capabilities:              (0x003d) SCT Status supported.
                                        SCT Error Recovery Control supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000a   100   098   000    Old_age   Always       -       0
  2 Throughput_Performance  0x0005   100   100   050    Pre-fail  Offline      -       0
  3 Spin_Up_Time            0x0007   100   100   050    Pre-fail  Always       -       0
  5 Reallocated_Sector_Ct   0x0013   100   100   050    Pre-fail  Always       -       0
  7 Unknown_SSD_Attribute   0x000b   100   100   050    Pre-fail  Always       -       0
  8 Unknown_SSD_Attribute   0x0005   100   100   050    Pre-fail  Offline      -       0
  9 Power_On_Hours          0x0012   100   100   000    Old_age   Always       -       36517
 10 Unknown_SSD_Attribute   0x0013   100   100   050    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0012   100   100   000    Old_age   Always       -       710
167 SSD_Protect_Mode        0x0022   100   100   000    Old_age   Always       -       0
168 SATA_PHY_Error_Count    0x0012   100   100   000    Old_age   Always       -       0
169 Bad_Block_Count         0x0013   100   100   010    Pre-fail  Always       -       100
170 Unknown_Attribute       0x0013   100   100   010    Pre-fail  Always       -       0
173 Erase_Count             0x0012   162   162   000    Old_age   Always       -       0
175 Program_Fail_Count_Chip 0x0013   100   100   010    Pre-fail  Always       -       0
192 Power-Off_Retract_Count 0x0012   100   100   000    Old_age   Always       -       148
194 Temperature_Celsius     0x0023   054   017   020    Pre-fail  Always   In_the_past 46 (Min/Max 8/83)
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
240 Unknown_SSD_Attribute   0x0013   100   100   050    Pre-fail  Always       -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.15.131-2-pve] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Toshiba 2.5" HDD MQ01UBD... (USB 3.0)
Device Model:     TOSHIBA MQ01UBD100
Serial Number:    83G6TD4GT
LU WWN Device Id: 0 000000 000000000
Firmware Version: AX001U
User Capacity:    1,000,204,886,016 bytes [1.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5400 rpm
Form Factor:      2.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS (minor revision not indicated)
SATA Version is:  SATA 2.6, 3.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Thu Jun 25 20:30:28 2026 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00) Offline data collection activity
                                        was never started.
                                        Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever
                                        been run.
Total time to complete Offline
data collection:                (  120) seconds.
Offline data collection
capabilities:                    (0x5b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        No Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        ( 237) minutes.
SCT capabilities:              (0x003d) SCT Status supported.
                                        SCT Error Recovery Control supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   050    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   100   100   050    Pre-fail  Offline      -       0
  3 Spin_Up_Time            0x0027   100   100   001    Pre-fail  Always       -       2630
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       4871
  5 Reallocated_Sector_Ct   0x0033   100   100   050    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   050    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   100   100   050    Pre-fail  Offline      -       0
  9 Power_On_Hours          0x0032   001   001   000    Old_age   Always       -       54526
 10 Spin_Retry_Count        0x0033   197   100   030    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       186
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       35
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       8571
194 Temperature_Celsius     0x0022   100   100   000    Old_age   Always       -       39 (Min/Max 18/54)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
220 Disk_Shift              0x0002   100   100   000    Old_age   Always       -       0
222 Loaded_Hours            0x0032   097   097   000    Old_age   Always       -       1364
223 Load_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
224 Load_Friction           0x0022   100   100   000    Old_age   Always       -       0
226 Load-in_Time            0x0026   100   100   000    Old_age   Always       -       176
240 Head_Flying_Hours       0x0001   100   100   001    Pre-fail  Offline      -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Wie ist den jetzt eigentlich dein Plan, was du machen willst?
Falls nicht wäre eine Bestandsaufnahme inkl. Kosten/Verfügbarkeit von Komponten nützlich zur Entscheidungsfindung.
Auf alle Fälle wäre ein aktuelles PVE auf frischen SSDs sinnvoll!

Heute ist die neue 512GB M.2 SSD angekommen. Plan ist also bei Zeiten aktuelles proxmox und dann die beiden jetzt intakten Backups einspielen.

 

[Impact]

Für den Container kann ich keine "Discard" Option finden.

Ist unter Mount options zu finden. Ich würde aber den Cronjob mit pct fstrim aus meinem Snippet empfehlen.

Ich hätte jetzt bei einer neuinstallation beim Hinzufügen eines Storage nur noch "LVM" genutzt

Ich empfehle nach wie vor ZFS. Ja auch auf consumer Hardware. Mit purem LVM kannst du nicht mal Snapshots machen und ich habe bisher kein gutes Argument dafür gesehen.

Die Platten haben SMART support aber keine (PVE bekannten) Attribute für Wear Leveling. Vielleicht kann update-smart-drivedb zu einer besseren betitelung von Unknown_SSD_Attribute führen. Ansonsten vileleicht ein Bug eröffnen. Möglicherweise kann man Erase_Count dafür auswerten.

 

[ThoSo]

Die Platten haben SMART support aber keine (PVE bekannten) Attribute für Wear Leveling. Vielleicht kann update-smart-drivedb zu einer besseren betitelung von Unknown_SSD_Attribute führen. Ansonsten vileleicht ein Bug eröffnen. Möglicherweise kann man Erase_Count dafür auswerten

Es dürfte fraglich sein, ob bei EOL von PVE7 ein bugreport noch sinnvoll ist. Evtl nur wenn das mit einem aktuellen Debian / PVE auch noch so wäre.
Er will ja auf den neuen SSD das aktuelle PVE installieren.