☰

LVM, nachdem vgcfgrestore Folgendes erhalten hat: Device-Mapper: Neuladen von ioctl am (254:19) fehlgeschlagen: Keine Daten verfügbar

tag-icon • tag-icon lvm data-recovery disk-volume
LVM, nachdem vgcfgrestore Folgendes erhalten hat: Device-Mapper: Neuladen von ioctl am (254:19) fehlgeschlagen: Keine Daten verfügbar

Der Server verfügt über Thin LVM mit einigen Volumes:

vm-130-disk-0 - was deleted and need to be restored.
vm-137-disk-0 - was NOT deleted.

Versuch, /etc/lvm/archive/pve_00336-2034680334.vg wiederherzustellen, das vor dem Löschen erstellt wurde:

# vgcfgrestore --force --file /etc/lvm/archive/pve_00336-2034680334.vg pve
# vgimport pve
# lvchange -ay /dev/pve/vm-130-disk-0
      Thin pool pve-data-tpool (254:6) transaction_id is 324, while expected 311.
      ...

# lvs -a              
  LV              VG   Attr       LSize   Pool Origin Data%  Meta%
  data            pve  twi---tz--   1.57t      # NOT activated pool data
  [data_tdata]    pve  Twi-a-----   1.57t      # OK  a=Activated
  [data_tmeta]    pve  ewi-a-----  16.00g      # OK  a=Activated                                              
  root            pve  -wi-a-----  10.00g      # OK  a=Activated                                 
  vm-130-disk-0   pve  Vwi---tz--  32.00g data # NOT activated deleted volume
  vm-137-disk-0   pve  Vwi---tz--  22.00g data # NOT activated non-deleted volume
  ...

Nun, hier haben wir einen Fehler gemacht, weil die Transaktion zwischen tmeta und tpool nicht übereinstimmt. Die meisten Leute, die im Internet geantwortet haben, haben eine gespiegelte Situation: tpool=312 und tmeta=324 und es sieht so aus, als ob ihnen die Korrektur der Transaktions-ID in der .vg-Datei hilft. Versuchen wir, die .vg-Datei zu reparieren und zu aktivieren:

Changed by hands transaction_id from 311 to 324 in /etc/lvm/archive/pve_00336-2034680334.vg ..

# vgcfgrestore --force --file /etc/lvm/archive/pve_00336-2034680334.vg pve
# vgimport pve
# lvchange -ay /dev/pve/vm-130-disk-0
   device-mapper: reload ioctl on (254:19) failed: No data available

In debug log appears: pve-vm--130--disk--0: Skipping NODE_DEL [trust_udev]

# lvs -a
  LV              VG   Attr       LSize   Pool Origin Data%  Meta%
  data           pve  twi-aotz--   1.57t             5.86   0.44  # OK
  [data_tdata]   pve  Twi-a-----   1.57t                          # OK                      
  [data_tmeta]   pve  ewi-a-----  16.00g                          # OK                      
  root           pve  -wi-a-----  10.00g                          # OK                      
  vm-130-disk-0  pve  Vwi---tz--  32.00g data                     # NOT activated deleted volume
  vm-137-disk-0  pve  Vwi-a-tz--  22.00g data        67.91        # OK activated non-deleted volume
  ...

„Keine Daten verfügbar“ für gelöschtes Volume. Traurig. Soweit ich weiß, hat tpool die Transaktions-ID 324 und ich muss tpool irgendwie auf 312 zurücksetzen. Keine Ahnung wie.

Was kann ich tun, um pve/vm-130-disk-0 zu aktivieren?

# lvm version
  LVM version:     2.02.168(2) (2016-11-30)
  Library version: 1.02.137 (2016-11-30)
  Driver version:  4.35.0

# uname -a
Linux adminslotlogicrestoreasap 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u2 (2019-11-11) x86_64 GNU/Linux

Danke fürs Lesen! Ich bin für jeden Rat dankbar.

Antwort1

Dünne LVM-Archivdateien /etc/lvm/archive/*.vg haben keine physischen Extents in Segmenten, sondern nur Geräte-IDs. Die Zuordnung zwischen Geräte-IDs und physischen Extents auf Blockgeräten ist in den LVM-Metadaten gespeichert und kann aus dem inaktiven Pool ausgelesen werden:

vgimport pve
lvchange --yes -ay pve/data_tmeta
thin_dump  /dev/mapper/pve-data_tmeta -o thin_dump_pve-data_tmeta.xml
lvchange       -an pve/data_tmeta

Dank anlventfernenSie können keine gelöschten Geräte-IDs sehen.

Daher ist im beschriebenen Fall eine Thin-Wiederherstellung nicht möglich.

Siehe auchEntwickler-Feedback (2014).

verwandte Informationen