[Hilfe] Nach Stromausfall und USV-Versagen alle LVM-Pools nicht verfügbar

J

jacotec

Member
Nov 19, 2024
37
15
8
Kerpen, DE
Hallo zusammen,

ich habe hier gerade ein größeres Problem :confused:

Es gab heute Abend einen Stromausfall, und obwohl meine USV nicht zusammengebrochen ist und nur je eines meiner beiden Netzteile meiner Dell-Server keinen Strom hatte, sind meine beiden R730 dunkel geworden. Und leider beschert mir Proxmox ein Szenario, welches ich bei ähnlichen "Unfällen" in den letzten Jahren bei VMWare nie hatte: Kein LVM-Storage läuft mehr hoch. Gut 40 VMs stehen :mad:

Beim Booten sagt er mir immer "Manual Repair Required". Ich habe dann mal nach einigen gefundenden Tipps hier im Forum gemacht:

Code: 
root@pmx1:~# lvchange -an pve/data_tdata
root@pmx1:~# lvchange -an pve/data_tmeta
root@pmx1:~# lvchange -ay pve/data
cannot perform fix without a full examination
Usage: thin_check [options] {device|file}
Options:
  {-q|--quiet}
  {-h|--help}
  {-V|--version}
  {-m|--metadata-snap}
  {--auto-repair}
  {--override-mapping-root}
  {--clear-needs-check-flag}
  {--ignore-non-fatal-errors}
  {--skip-mappings}
  {--super-block-only}
  Check of pool pve/data failed (status:1). Manual repair required!
root@pmx1:~# thin_check pve/data
Couldn't stat path

Wie führt man denn das "thin_check" aus? Mit welchem Pfad? Ich bin gerade völlig überfordert mit der Situation und muss wohl mal schlafen gehen in einem Haus, in dem gerade nichts mehr wirklich läuft :-(

Wie bekomme ich das Ganze wieder ans laufen (ohne alle Server neu aufzusetzen und tagelang 40VMs aus den Backups wiederzuholen)

Ich bedanke mich für eure Hilfe!

LG,
Marco
 
Habe noch mal schnell das hier versucht, funktioniert auch nicht:

Code: 
root@pmx1:~# thin_check --auto-repair /dev/mapper/pve-root
syscall 'open' failed: Device or resource busy
Note: you cannot run this tool with these options on live metadata.
 
Guten Morgen,
schade zu hören, dass man auf das "falsche Pferd" gesetzt hat.

Was ich meine LVM und kein ZFS als Mirror, RaidZn usw.
Bei 40 VM, die so wichtig sind, dass man nicht die Sicherungen innerhalb kurzer Zeit einspielen könnte.

Versuchen würden ich auf den aktuellen Datenbestand durch eine Widerherstellungssystem zu zugreifen und zu sichern.
Dann alles neu unter ZFS aufsetzen und die LXC, und VM zurück spielen und nach der alten Vorlage das Netzwerk wieder einrichten. Alles neu geht dann meistens schneller.
Auch könnte man sich noch eine einfach SSD SATA3 einhängen und dort mal Proxmox VE installieren und dies als Rettungssystem verwenden.
 
Last edited:
Dann würde ich mir mal einen Systembericht generieren, um auch heraus zu bekommen, welche Teile der Server-Hardware gestorben sind.
Die SSD, NVMe und HDD kann man mit smartmontools überwachen lassen und jede einzelne mit smartctl überprüfen lassen.
man smartctl
lshw
inxi -Fxz
 
Ich gehe davon, dass SSD, NVMe "gestorben" sind, evtl. sind dort QLC Datenspeicher implementiert.
Für ZFS VDEV funktioniert auf lange Sicht Kingston DC600M.

Crucial MX500 haben viele gute Eigenschaften nur zu wenige TWB und sind nun ausgelistet.

ADATA Ultimate SU800 verwende ich in einigen System auch, auch wenn sie die benötigten maximal Eigenschaften für ZFS VDEV nicht vollständig erfüllen, für Rettungssystem ist sie zu empehlen und bestimmt auch preislich sehr interssant.

# https://geizhals.de/adata-ultimate-su800-1tb-asu800ss-1tt-c-a1501289.html.
 
Last edited:
Das hilft mir konstruktiv gerade nicht weiter. LVM deshalb, weil das Ganze auf Hardware-RAID läuft, die extrem gut performt und für meine Hardware die bessere Wahl ist. Warum die Server "runtergeknallt" sind anstatt dass die USV diese über den Versorgungsstrang 1 weiter am Leben hält (und ggfs. kontrolliert runterfährt) bleibt getrennt zu klären.

Einspielen der Backups verliert halt Daten, zwischen 1 Tag und 1 Woche. Daher würde ich die bestehenden Volumes gerne wieder ans Laufen bekommen.

Wer also konkrete Tipps hat - würde mich freuen.

Insbesondere - warum bekomme ich hier diese Fehlermeldung:

Code: 
root@pmx2:~# lvconvert --repair --yes pve/data
  Volume group "pve" has insufficient free space (2024 extents): 2073 required.

Auf dem "pve" liegt bei den Servern nicht eine einzige VM! Die liegen alle in local-lvm1 und local-lvm2. Da muss Platz mehr als genug sein.

Weitere Infos:

Code: 
root@pmx2:~# vgs
  VG         #PV #LV #SN Attr   VSize    VFree
  local-lvm1   1  28   0 wz--n-   13.64t 376.00m
  local-lvm2   1  20   0 wz--n-   13.64t 376.00m
  pve          1   5   0 wz--n- <930.00g  <7.91g
root@pmx2:~# lvs -a -o +seg_monitor
  LV                 VG         Attr       LSize    Pool       Origin Data%  Meta%  Move Log Cpy%Sync Convert Monitor
  local-lvm1         local-lvm1 twi---tz--   13.61t
  [local-lvm1_tdata] local-lvm1 Twi-------   13.61t
  [local-lvm1_tmeta] local-lvm1 ewi-------  <15.88g
  [lvol0_pmspare]    local-lvm1 ewi-------  <15.88g
  vm-100-disk-0      local-lvm1 Vwi---tz--  250.00g local-lvm1
  vm-101-disk-0      local-lvm1 Vwi---tz--  200.00g local-lvm1
  vm-102-disk-0      local-lvm1 Vwi---tz--  250.00g local-lvm1
  vm-104-disk-0      local-lvm1 Vwi---tz--  500.00g local-lvm1
  vm-105-disk-0      local-lvm1 Vwi---tz--  500.00g local-lvm1
  vm-106-disk-0      local-lvm1 Vwi---tz--  500.00g local-lvm1
  vm-107-disk-0      local-lvm1 Vwi---tz--  512.00g local-lvm1
  vm-109-disk-0      local-lvm1 Vwi---tz--  250.00g local-lvm1
  vm-112-disk-0      local-lvm1 Vwi---tz--  500.00g local-lvm1
  vm-113-disk-0      local-lvm1 Vwi---tz--    4.00m local-lvm1
  vm-113-disk-1      local-lvm1 Vwi---tz--    1.00t local-lvm1
  vm-113-disk-2      local-lvm1 Vwi---tz--    4.00m local-lvm1
  vm-127-disk-0      local-lvm1 Vwi---tz--  500.00g local-lvm1
  vm-128-disk-0      local-lvm1 Vwi---tz--    4.00m local-lvm1
  vm-128-disk-1      local-lvm1 Vwi---tz--  128.00g local-lvm1
  vm-133-disk-0      local-lvm1 Vwi---tz--    1.00t local-lvm1
  vm-135-disk-0      local-lvm1 Vwi---tz--  150.00g local-lvm1
  vm-140-disk-0      local-lvm1 Vwi---tz--    4.00m local-lvm1
  vm-140-disk-1      local-lvm1 Vwi---tz--   36.03g local-lvm1
  vm-141-disk-0      local-lvm1 Vwi---tz--  100.00g local-lvm1
  vm-153-cloudinit   local-lvm1 Vwi---tz--    4.00m local-lvm1
  vm-153-disk-0      local-lvm1 Vwi---tz--    4.00m local-lvm1
  vm-153-disk-1      local-lvm1 Vwi---tz--  100.00g local-lvm1
  vm-155-disk-0      local-lvm1 Vwi---tz--    3.50t local-lvm1
  vm-158-disk-0      local-lvm1 Vwi---tz--  250.00g local-lvm1
  vm-161-disk-0      local-lvm1 Vwi---tz--    1.00t local-lvm1
  vm-163-disk-0      local-lvm1 Vwi---tz--  500.00g local-lvm1
  local-lvm2         local-lvm2 twi---tz--   13.61t
  [local-lvm2_tdata] local-lvm2 Twi-------   13.61t
  [local-lvm2_tmeta] local-lvm2 ewi-------  <15.88g
  [lvol0_pmspare]    local-lvm2 ewi-------  <15.88g
  vm-108-disk-0      local-lvm2 Vwi---tz--  100.00g local-lvm2
  vm-108-disk-1      local-lvm2 Vwi---tz--    4.00t local-lvm2
  vm-132-disk-0      local-lvm2 Vwi---tz--    4.00m local-lvm2
  vm-132-disk-1      local-lvm2 Vwi---tz--  250.00g local-lvm2
  vm-154-disk-0      local-lvm2 Vwi---tz--    2.00t local-lvm2
  vm-156-disk-0      local-lvm2 Vwi---tz--    2.00t local-lvm2
  vm-157-disk-0      local-lvm2 Vwi---tz--  500.00g local-lvm2
  vm-159-disk-0      local-lvm2 Vwi---tz--    4.00m local-lvm2
  vm-159-disk-1      local-lvm2 Vwi---tz--    1.00t local-lvm2
  vm-160-disk-0      local-lvm2 Vwi---tz--  500.00g local-lvm2
  vm-162-disk-0      local-lvm2 Vwi---tz--  250.00g local-lvm2
  vm-164-disk-0      local-lvm2 Vwi---tz--  300.00g local-lvm2
  vm-165-disk-0      local-lvm2 Vwi---tz--  500.00g local-lvm2
  vm-166-disk-0      local-lvm2 Vwi---tz--    1.00t local-lvm2
  vm-167-disk-0      local-lvm2 Vwi---tz--  250.00g local-lvm2
  vm-168-disk-0      local-lvm2 Vwi---tz--  250.00g local-lvm2
  vm-169-disk-0      local-lvm2 Vwi---tz--    1.00t local-lvm2
  vm-171-disk-0      local-lvm2 Vwi---tz--  300.00g local-lvm2
  vm-172-disk-0      local-lvm2 Vwi---tz--  100.00g local-lvm2
  data               pve        twi---tz-- <793.80g
  data_meta0         pve        -wi-------   <8.10g
  data_meta1         pve        -wi-------   <8.10g
  [data_tdata]       pve        Twi------- <793.80g
  [data_tmeta]       pve        ewi-------   <8.10g
  root               pve        -wi-ao----   96.00g
  swap               pve        -wi-ao----    8.00g
root@pmx2:~#

Vor allem aber:

In vielen Anleitungen, auch von ChatGPT, findet man

Code: 
thin_check /dev/pve/data_tmeta

Die Pfade gibt es auf keinem meiner Proxmox-Server - auch nicht auf den Laufenden.
 
Last edited:
jacotec said:
Habe noch mal schnell das hier versucht, funktioniert auch nicht:
Click to expand...
Keine Hektik bitte, nicht in so einer Stresssituation.

Ich benutzte KEIN LVM, aber vielleicht hilft man thin_repair
 
  • Like
Reactions: Johannes S
Nun dann fang mal an meiner Anleitung zu folgen und eine 2.tes System als Rettungssystem auf zu setzen.
Und dann auch mehr zur Hardware und zu den Datenträgern zu veröffentlichen.

Mit ZFS könnte man auch x Minuten ZFS Snapshots synchronisieren auf einen 2.ten Server.
Jeder wie er will.
 
  • Like
Reactions: news
@UdoB ja das schrieb ich indirekt, aber für ein temporäres Rettungssystem auf ext4 zu gebrauchen und bezahlbar.

Leider erfahren wir nicht was der TO genau an Hardware hat.
Weiter tippe ich auf Ausfall des Flashspeichers auf seinen Datenträgern.
 
Last edited:
  • Like
Reactions: UdoB
news said:
@UdoB ja das schrieb ich indirekt, aber für ein temporäres Rettungssystem auf ext4 zu gebrauchen und bezahlbar.

Leider erfahren wir nicht was der TO genau an Hardware hat.
Weiter tippe ich auf Ausfall des Flashspeichers auf seinen Datenträgern.
Click to expand...

Es sind zwei Dell R730 mit jeweils 24 3TB-SAS-Disks über H730P RAID-Controller. Zusätzlich zwei 1TB SAS im RAID-1 als Boot-Drive.

/pve/data liegt auf den Boot-Drives ohne VMs.
/local-lvm1/local-lvm1 sowie /local-lvm2/local-lvm2 liegen auf jeweils zwei virtuellen Disks des RAID.

Leider finde ich keinen Pfad, um den verlangten thin_check auszuführen, den er für die Aktivierung haben möchte.

Code: 
dmsetup ls
local--lvm1-local--lvm1_meta0   (252:4)
local--lvm2-local--lvm2_meta0   (252:5)
pve-data_meta0  (252:2)
pve-data_meta1  (252:3)
pve-root        (252:1)
pve-swap        (252:0)

Er findet hier nur die Snapshots, die das "lvconvert --repair --yes " auf die Volumes angelegt hatte. Prüfe ich diese mit thin_check, so findet er in keinem dieser Snapshots einen Fehler.

Aktivieren kann ich die Volumes aber immer noch nicht, da sagt er dann wieder, dass er einen check mit thin_check haben möchte - natürlich auf die Original-Metadaten, die ich aber nirgends im Zugriff habe.

Code: 
root@pmx2:~# lvchange -ay pve/data
cannot perform fix without a full examination
Usage: thin_check [options] {device|file}
Options:
  {-q|--quiet}
  {-h|--help}
  {-V|--version}
  {-m|--metadata-snap}
  {--auto-repair}
  {--override-mapping-root}
  {--clear-needs-check-flag}
  {--ignore-non-fatal-errors}
  {--skip-mappings}
  {--super-block-only}
  Check of pool pve/data failed (status:1). Manual repair required!
 
Last edited:
Last edited:
ThoSo said:
Sind deine Raids im PERC in Ordnung?
Ich mache auch einen Bogen um LVMs und lege auf einem Raid-Volume mit dem PERC lieber ein "natives" Dateisystem (Ext4 demnächst vielleicht BTRFS) an.
Click to expand...
Yap, die sind gut.
Und leider gibt es keine Alternative zu LVM-Thin ... Snapshots sind genauso essentiell wie Thin-Provisioning.

Ich bin aber gerade wirklich geschockt, wie empfindlich dieser LVM-Kram ist. 6 (!) Volumes auf zwei Servern schreien nach dem Thin_Check, den man irgendwie nicht durchführen kann ... oder sagen wir: Von dem ich nicht weiß, wie ich den laufenlassen kann, weil ich nicht an diesen Meta-Krams mit Schreibberechtigung komme. Unter VMWare ist mir so vielleicht mal eine VM kaupttgegangen, die ich reparieren konnte. Aber hier hilft es mir gerade nicht. Chat_GPT sagt mir unermüdlich, dass das tmeta unter /dev/pve/data_tmeta zu finden sind. Sind sie aber eben nicht.

Komme ich wenigstens irgendwie an die Daten-Disks dran, um ein paar auf meinen Reserveserver zu migrieren? Wohl eher nicht ...
 
  • Like
Reactions: ThoSo
Lt. ManPages (https://man7.org/linux/man-pages/man7/lvmthin.7.html)

Thin Pool Metadata check and repair
If thin pool metadata is damaged, it may be repairable. Checking
and repairing thin pool metadata is analogous to running
fsck/repair on a file system. Thin pool metadata is compact, so
even small areas of damage or corruption can result in significant
data loss. Resilient storage for thin pool metadata can have
extra value.

When a thin pool LV is activated, lvm runs the thin_check(8)
command to check the correctness of the metadata on the pool
metadata LV. To configure thin_check use, location or options
used by lvm, set lvm.conf:

thin_check_executable
The location of the program. Setting to an empty string ("")
disables running thin_check by lvm. This is not recommended.

thin_check_options
Controls the command options that lvm will use when running
thin_check.

If thin_check finds a problem with the metadata, the thin pool LV
is not activated, and the thin pool metadata needs to be repaired.

Simple repair commands are not always successful. Advanced repair
may require editing thin pool metadata and lvm metadata. Newer
versions of the kernel and lvm tools may be more successful at
repair. Report the details of damaged thin metadata to get the
best advice on recovery.

Command to repair a thin pool:
$ lvconvert --repair VG/ThinPool

Repair performs the following steps:

1 Creates a new, repaired copy of the metadata.
lvconvert runs the thin_repair(8) command to read damaged
metadata from the existing pool metadata LV, and writes a new
repaired copy to the VG's pmspare LV.

2 Replaces the thin pool metadata LV.
If step 1 is successful, the thin pool metadata LV is replaced
with the pmspare LV containing the corrected metadata. The
previous thin pool metadata LV, containing the damaged
metadata, becomes visible with the new name ThinPool_metaN
(where N is 0,1,...).

If the repair works, the thin pool LV and its thin LVs can be
activated. The user should verify that each thin LV in the thin
pool can be successfully activated, and then verify the integrity
of the file system on each thin LV (e.g. using fsck or other
tools.) Once the thin pool is considered fully recovered, the
ThinPool_metaN LV containing the original, damaged metadata can be
manually removed to recovery the space.

If the repair fails, the original, unmodified ThinPool_metaN LV
should be preserved for support, or more advanced recovery
methods. Data from thin LVs may ultimately be unrecoverable.

If metadata is manually restored with thin_repair directly, the
pool metadata LV can be manually swapped with another LV
containing new metadata:

$ lvconvert --thinpool VG/ThinPool --poolmetadata VG/NewMetadataLV
Click to expand...


Yap, die sind gut.
Und leider gibt es keine Alternative zu LVM-Thin ... Snapshots sind genauso essentiell wie Thin-Provisioning.
Click to expand...
Immerhin -Snapshots sind kein Problem, die gehen auch mit ext4
 
Last edited:
Die "lvrepair" habe ich schon ausgeführt, leider kommt da immer sowas:

Code: 
Volume group "local-lvm1" has insufficient free space (94 extents): 4065 required.

Und das, obwohl keines der Volumes voll ausgelastet ist ... die 18TB-Volumes liegen so bei maximal 30%
 
Als Laie blicke ich hier im THread nicht richtig durch, aber wäre der Pfad nicht /dev/mapper/pve-data.... ?
 
jacotec said:
Volume group "local-lvm1" has insufficient free space (94 extents): 4065 required.
Click to expand...
Check mal das hier :
G

[SOLVED] Thread 'lvconvert --repair pve/data and insufficient free space'

I get the following error in /var/log/syslog


Code: 
Sep  4 08:44:30 pve pvedaemon[264889]: activating LV 'pve/data' failed:   Check of pool pve/data failed (status:1). Manual repair required!

When I try to repair I get

Code: 
lvconvert --repair pve/data
  Volume group "pve" has insufficient free space (144 extents): 4048 required.

Here some system information:

Code: 
lsblk
NAME               MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                  8:0    0   3.6T  0 disk
└─sda1               8:1    0   3.6T  0 part /mnt/backup
sdb                  8:16   0   3.6T  0 disk
├─sdb1...
ab Eintrag 7 ff - Eintrag #11


Frage: kommst du auf die GUI? und wie sieht das dort aus?
 
Last edited:
  • Like
Reactions: MarkusKo
ThoSo said:
Check mal das hier :
Click to expand...
DU BIST MEIN HELD!!!!!!!

Aus beschriebenem Grund hatte auch ich die Option "--skip-mappings" in meinem LVM-Konfigfile. Die habe ich rausgenommen und nun aktiviert er die Volumes und die VM's starten wieder nach Reboot :D

Ich habe im iDrac (also quasi auf dem "Monitor" des Servers) beim Start von Proxmox zwar immer noch die Meldungen von wegen "Manual Check Required", aber das Proxmox-Log an sich ist sauber und ich scheine an alles ran zu kommen.

Ein "--auto-repair" in der thin_check-Config im /etc/lvm/lvm.conf beseitigt diese Startmeldungen auch nicht ... muss ich mir da sorgen machen?
 
  • Like
Reactions: MarkusKo, Johannes S, ThoSo and 1 other person
jacotec said:
DU BIST MEIN HELD!!!!!!!
Click to expand...
Danke - Tante Google ist halt besser als der ChatGPT Quatsch.


jacotec said:
Ich habe im iDrac (also quasi auf dem "Monitor" des Servers) beim Start von Proxmox zwar immer noch die Meldungen von wegen "Manual Check Required", aber das Proxmox-Log an sich ist sauber und ich scheine an alles ran zu kommen.
Click to expand...
Evtl. beim iDrac mal die Events löschen / bestätigen.

jacotec said:
Ein "--auto-repair" in der thin_check-Config im /etc/lvm/lvm.conf beseitigt diese Startmeldungen auch nicht ... muss ich mir da sorgen machen?
Click to expand...
Das ist eine Frage an die LVM Spezialisten von Proxmox Team - evtl. @fiona ?

Bleibt noch die Frage für Dich, warum das mit dem DELL so geknallt hat - aber darüber würde ich erst einmal eine Runde schlafen.
 
You must log in or register to reply here.
Top Bottom