LVM Physical Volume
Olaf Meiser
wir haben eine System- und Datenplatte mit LVM aus einem gecrashten
Rechner ausgebaut und versuchen nun, die letzten nicht mehr gesicherten
daten runterzubekommen.
Der Mitarbeiter versteht leider nciht allzuviel von LVM (und ich auch
nicht). Nachdem das Physical Volume von pgscan erkannt wurde:
PV /dev/sdc2 lvm2 [1,09 TiB]
Total: 1 [1,09 TiB] / in use: 0 [0 ] / in no VG: 1 [1,09 TiB]
hat er ein
sudo vgcreate oldsystem /dev/sdc2
ausgefï¿œhrt. Ich habe dann unterbruochen, weil mir solche Experimente zu
gefï¿œhrlich sind.
Was ist zu tun? :)
Diedrich Ehlerding
> Der Mitarbeiter versteht leider nciht allzuviel von LVM (und ich auch
> nicht). Nachdem das Physical Volume von pgscan erkannt wurde:
> PV /dev/sdc2 lvm2 [1,09 TiB]
Es war also schon vorher ein für lvm initialisiertes Volume. (Waren da denn
wirklich Daten drauf?)
> Total: 1 [1,09 TiB] / in use: 0 [0 ] / in no VG: 1 [1,09 TiB]
> hat er ein
> sudo vgcreate oldsystem /dev/sdc2
> ausgeführt.
und hat damit die alten Metadaten kaputtgemacht, wenn da schon eine
Volumestruktur drauf war..
Wenn du Glück hast, hast du noch irgendwo im alten system vgcfgbackup-Dateien
für die Volumegruppe, die da vielleicht mal drauf war. Mit denen kannst du -
wenn du Glück hast - die Volumestruktur wiederherstellen. Bzw. nicht du kannst
das, sondern derjenige, den du suchst und vielleicht findest, der von LVM was
versteht.
Und wenn du Pech hast, sind deine Daten im Nirwana.
> Ich habe dann unterbruochen, weil mir solche Experimente zu
> gefährlich sind.
Du hättest besser schon vorher unterbrochen, wenn da wirklich Daten auf der
Platte waren, die du noch brauchst. Merke jemand, der "nicht allzuviel von
LVM" versteht, sollte auch besser nicht dran rumadministrieren.
> Was ist zu tun?
vgcfgbackup-Daten suchen (könnten in der letzten Datensicherung deines alten
systems stehen; typischerweise irgendwo unter /etc/lvm)
Dann jemanden suchen, der von LVM was versteht und dir aus diesen Daten wieder
gültige Metadaten der Volumegruppe bastelt. Flasche Schampus bereithalten für
den Fall, dass der dir deine Daten rettet. Flasche Gabiko bereithalten für den
Fall, dass ers nicht schafft, und du deinen Ärger in Alkohol ertränken willst.
Dann Kontakt mit der örtlichen LUG aufnehmen und jemanden suchen, der dir LVM
soweit erklärt, dass du diesen Fehler wie oben jedenfalls in Zukunft nicht
mehr machst.
Und wenn die Daten weg sind: letzte Sicherung einspielen. Wenn die nicht
existiert: in die Tischkante beißen und damit beginnen, eine regelmäßige
Datensicherung nach sinnvollen Kriterien aufzubauen.
Diedrich
--
pgp-Key (RSA) 1024/09B8C0BD
fingerprint = 2C 49 FF B2 C4 66 2D 93 6F A1 FF 10 16 59 96 F3
HTML-Mail wird ungeleſen entſorgt.
Thomas Bächler
Die richtige Lï¿œsung wï¿œre gewesen, das vgcreate zu unterlassen (siehe das
Posting von Diedrich) und ein 'vgscan && vgchange -ay' auszufï¿œhren.
Michael Limburg
> Olaf Meiser meinte:
>> Ich habe dann unterbruochen, weil mir solche Experimente zu
>> gefährlich sind.
>
> Du hättest besser schon vorher unterbrochen, wenn da wirklich Daten
> auf der Platte waren, die du noch brauchst. Merke jemand, der "nicht
> allzuviel von LVM" versteht, sollte auch besser nicht dran
> rumadministrieren.
Kardinalfehler ist aus meiner Sicht das Versäumnis, _vor_ irgendwelchen
Rettungsaktionen die betroffenen Daten/Platten zu sichern/kopieren, um
sie im Notfall zurückspielen zu können.
Dann ist es wenigsten nicht tragisch, wenn's bei "Basteln" zu Unfällen
kommt
>> Was ist zu tun?
Vor allen weiteren Aktionen: s.o.
Michael
Hauke Laging
> hat er ein
> sudo vgcreate oldsystem /dev/sdc2
> ausgeführt. Ich habe dann unterbruochen, weil mir solche Experimente zu
> gefährlich sind.
>
> Was ist zu tun? :)
Die Lage der LVs ist zu ermitteln. Wenn nie LVs verändert wurden, sollte das
unproblematisch sein. Allerdings unter der Annahme, dass es sich nur um eine
Festplatte oder die erste von mehreren handelt. Ansonsten bleibt wohl nur
die gpart-Variante für LVs, die komplett auf der Platte liegen, wenn nicht
auch auf dem zweiten PV ein LV beginnt.
LVM funktioniert so, dass es aus den Metadaten auf der Platte die Lage der
LVs ermittelt und sie dann über den device mapper einrichtet. Sobald das
passiert ist, ist LVM raus. Man sieht nicht mal mehr, dass es sich um LVM-
Speicherplatz handelt. Die (aktiven) LVs kann man sich mit
dmsetup ls
anzeigen lassen. Bei mir ist einer dieser Einträge linux2-rootfs. Das meint
das LV rootfs in der VG linux2. Wenn man sich nun anschaut, wie dieses dm-
Volume ausgebaut ist
# dmsetup table linux2-rootfs
0 25165824 linear 8:8 384
sieht man, dass das einfach nur ein zusammenhängender Block auf sda8 (major
number 8, minor number 8) ist (beginnend in Sektor 384, weil davor die LVM-
Metadaten liegen). Wenn man diese Information hat, kann man auch ohne LVM
ein block device erzeugen, über das man auf die Daten zugreifen kann,
nämlich mittels
dmsetup create restore-lv --table "0 25165824 linear 8:8 384"
Die spannende Frage ist also, wie in Eurem Fall die beiden Zahlen lauten.
Den Offset (also bei mir die 384) findet Ihr mit gpart heraus. Aber da das
erste LV offenbar immer bei 384 beginnt, würde ich das erst mal
ausprobieren. Die Sektoranzahl (bei mir 25165824) muss nicht korrekt sein.
Falls man fsck fragt, wie groß das Volume ist, darf sie aber nicht kleiner
sein, also einfach etwas größer wählen, ggf. bis zum Ende des PV. Aber Ihr
wisst ja vermutlich, wie groß das LV war.
Wenn es ein ext2-, ext3- oder ext4-Laufwerk war, kann man sich einfach den
Inhalt des Superblocks ausgeben lassen. Ich habe mal testhalber eine VG in
einem leeren PV erzeugt und darin ein LV von 50 MiB Größe, das ich mit ext2
formatiert habe. So sieht das im device mapper aus:
# dmsetup table test1-test
0 106496 linear 7:5 384
Nun tun wir mal so, als hätte ich die LVM-Metadaten geschreddert. Ich lege
unabhängig von LVM ein (ganz kleines) block device an, das an derselben
Stelle beginnt:
dmsetup create restore-lv --table "0 100 linear 7:5 384"
Und nun lasse ich dumpe2fs darauf los:
# dumpe2fs -h /dev/mapper/restore-lv
dumpe2fs 1.41.14 (22-Dec-2010)
[...]
Block count: 53248
[...]
Block size: 1024
[...]
dumpe2fs ist die falsche Größe des block device egal, weil es eh nur den
Superblock liest. Und siehe da, 53248*1024=54525952
Man bekommt also aus dieser Ausgabe den Parameter für dmsetup. Und wenn
einfach nur LVs nacheinander erzeugt wurden, hat man damit auch den Offset
des nächsten LV:
# dmsetup table test1-test2
0 65536 linear 7:5 106880
Der ergibt sich aus dem Offset des ersten und seiner Größe.
106496+384=106880
Und für die Zukunft: Wenn man keine Ahnung hat, einfach mal die Finger
stillhalten.
CU
Hauke
--
http://www.hauke-laging.de/ideen/
D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
Hauke Laging
> und hat damit die alten Metadaten kaputtgemacht, wenn da schon eine
> Volumestruktur drauf war..
Nein. vgcreate schreibt nicht auf ein PV, auf dem bereits eine VG liegt:
# vgcreate test2 /dev/loop5
Physical volume '/dev/loop5' is already in volume group 'test1'
Unable to add physical volume '/dev/loop5' to volume group 'test2'.
Die Metadaten waren da also schon schrott.
> Und wenn du Pech hast, sind deine Daten im Nirwana.
Dass vgcreate *Daten* überschreibt, schließe ich weitgehend aus. Das dürfte
nur in absurden Sonderfällen passieren. LVM verrät einem dann allerdings
nicht mehr, wo die LVs liegen. Wie ich in meiner Antwort auf den OP
erläutert habe, ist das aber kein großes Problem.
Sogar das Anlegen von Laufwerken exakt derselben Größe in der richtigen
Reihenfolge sollte die Daten erhalten.
Hauke Laging
> Die richtige Lösung wäre gewesen, das vgcreate zu unterlassen (siehe das
> Posting von Diedrich) und ein 'vgscan && vgchange -ay' auszuführen.
Das hätte zu keinem anderen Ergebnis geführt. Wenn vgcreate erkennt, dass
ein PV bereits einer VG zugeordnet ist, dann verweigert es das Anlegen einer
neuen:
# vgcreate test2 /dev/loop5
Physical volume '/dev/loop5' is already in volume group 'test1'
Unable to add physical volume '/dev/loop5' to volume group 'test2'.
Hauke Laging
Ein Nachtrag zur Klarstellung:
> # dmsetup table test1-test
> 0 106496 linear 7:5 384
> dumpe2fs ist die falsche Größe des block device egal, weil es eh nur den
> Superblock liest. Und siehe da, 53248*1024=54525952
Dieses Produkt ist gleich der Größe des block device:
53248*1024 = 54525952 = 106496*512
Die zu wählende Größe des block device ist also
Blockanzahl * Blockgröße (in Byte) / 512
Olaf Meiser
>
> # vgcreate test2 /dev/loop5
> Physical volume '/dev/loop5' is already in volume group 'test1'
> Unable to add physical volume '/dev/loop5' to volume group 'test2'.
>
> Die Metadaten waren da also schon schrott.
Ich bin mir nicht sicher, ob das nicht kam. Die Situation war eher
"Ich versuche mal vgcreate ..." - *denkpause*halt*ob das gut ist?*
"Nein, lass den Quatsch!" - "Zu spät ...".
Im Moment sieht es so aus ...
/home/user# pvscan && vgscan && lvscan
PV /dev/sdc2 VG oldsystem lvm2 [1,09 TiB / 1,09 TiB free]
Total: 1 [1,09 TiB] / in use: 1 [1,09 TiB] / in no VG: 0 [0 ]
Reading all physical volumes. This may take a while...
Found volume group "oldsystem" using metadata type lvm2
Olaf Meiser
Hm ...
/home/user# dmsetup ls
No devices found
Ich weiß nciht, ob ich Dich richtig verstanden habe. Aber alle weiteren
ausführungen verwednen doch den daraus abgeleiteten Wert
> # dmsetup table linux2-rootfs
> 0 25165824 linear 8:8 384
^^^
> Und für die Zukunft: Wenn man keine Ahnung hat, einfach mal die Finger
> stillhalten.
Frag mich mal :) LART steht schon bereit *g*
Diedrich Ehlerding
>> und hat damit die alten Metadaten kaputtgemacht, wenn da schon eine
>> > Volumestruktur drauf war..
> Nein. vgcreate schreibt nicht auf ein PV, auf dem bereits eine VG liegt:
>
> # vgcreate test2 /dev/loop5
> Physical volume '/dev/loop5' is already in volume group 'test1'
> Unable to add physical volume '/dev/loop5' to volume group 'test2'.
>
> Die Metadaten waren da also schon schrott.
Stimmt; hatte ich übersehen - wenn die Platte schon zu einer
VG gehört hätte, dann wäre der Name dieser Volumegruppe auch
angezeigt worden. Hier ein Beispiel (die vg "andreas" ist nicht aktiv,
aber angestöpselt:)
# pvscan
PV /dev/mapper/mpathd VG andreas lvm2 [93.13 GB / 86.37 GB free]
PV /dev/mapper/mpathb VG andreas lvm2 [93.13 GB / 87.25 GB free]
PV /dev/mapper/mpatha VG volker lvm2 [93.13 GB / 0 free]
PV /dev/mapper/mpathc VG volker lvm2 [93.13 GB / 0 free]
Total: 4 [372.52 GB] / in use: 4 [372.52 GB] / in no VG: 0 [0 ]
Beim OP sahs so aus:
PV /dev/sdc2 lvm2 [1,09 TiB]
Total: 1 [1,09 TiB] / in use: 0 [0 ] / in no VG: 1 [1,09 TiB]
d.h. sdc2 gehörte schon vorher zu keiner Volumegruppe. Wenn da also mal
Daten drauf waren, dann waren die in der Tat schon vorher zerstört worden.
|
Diedrich Ehlerding
> Im Moment sieht es so aus ...
> /home/user# pvscan&& vgscan&& lvscan
> PV /dev/sdc2 VG oldsystem lvm2 [1,09 TiB / 1,09 TiB free]
> Total: 1 [1,09 TiB] / in use: 1 [1,09 TiB] / in no VG: 0 [0 ]
> Reading all physical volumes. This may take a while...
> Found volume group "oldsystem" using metadata type lvm2
Jetzt hast du ja schon eine Volumegruppe erzeugt namens "oldsystem".
Wie du siehst, zeigt pvscan dir an, zu welcher Volumegruppe die Platte
gehört.
Im Ausgangszustand, den du uns anfangs gezeigt hast, war sdc2 aber
offenbar zwar für LVM initialisiert, aber da stand keine VG drauf. Das
hatte ich in meiner ersten Antwort übersehen.
Hast du vor dem vgcreate etwa auch noch ein pvcreate durchgeführt? Wenn
ja, warum? Bist du überhaupt sicher, dass da jemals eine LVM-Gruppe
drauf war? Hast du vielleicht die falsche Platte umgebaut?
Mit anderen Worten: entweder hast du eine leere Platte vom alten ins
neue System gestöpselt, oder du hast noch sehr viel mehr kaputtgemacht,
was du uns nicht gesagt hast. ...
Diedrich
Hauke Laging
>> dmsetup ls
>
> Hm ...
> /home/user# dmsetup ls
> No devices found
Klar, Dein LVM ist ja auch derzeit kaputt. Das sollte nur illustrieren, wie
es normalerweise aussieht. Die Herausforderung ist, ohne Hilfe von LVM
diesen Eintrag zu erstellen.
> Ich weiß nciht, ob ich Dich richtig verstanden habe. Aber alle weiteren
> ausführungen verwednen doch den daraus abgeleiteten Wert
>
>> # dmsetup table linux2-rootfs
>> 0 25165824 linear 8:8 384
> ^^^
Ja, und?
8:8 (sda8) müsste bei Dir 8:34 sein (sdc2). Den Rest habe ich doch
ausführlich erklärt.
War das die einzige Platte, die zu der volume group gehörte?
Olaf Meiser
>> ausführungen verwednen doch den daraus abgeleiteten Wert
>>
>>> # dmsetup table linux2-rootfs
>>> 0 25165824 linear 8:8 384
>> ^^^
>
> Ja, und?
>
> 8:8 (sda8) müsste bei Dir 8:34 sein (sdc2). Den Rest habe ich doch
> ausführlich erklärt.
Damit komme ich weiter, die Bezeichnungn sind mir allerdings ebenfalls
unbekannt :) Ohne LVM habe ich die nie gebraucht.
> War das die einzige Platte, die zu der volume group gehörte?
Ja, war es.
Olaf Meiser
> offenbar zwar für LVM initialisiert, aber da stand keine VG drauf. Das
> hatte ich in meiner ersten Antwort übersehen.
> Hast du vor dem vgcreate etwa auch noch ein pvcreate durchgeführt? Wenn
> ja, warum? Bist du überhaupt sicher, dass da jemals eine LVM-Gruppe
> drauf war? Hast du vielleicht die falsche Platte umgebaut?
Habe den Kollegen gefragt und die bash history überprüft. Offenbar kein
pvcreate.
> Mit anderen Worten: entweder hast du eine leere Platte vom alten ins
> neue System gestöpselt, oder du hast noch sehr viel mehr kaputtgemacht,
> was du uns nicht gesagt hast. ...
Die falsche Platte scheint es jedenfalls nicht zu sein.
/home# mount /dev/sdc2 /media/oldsystem/
mount: unbekannter Dateisystemtyp „LVM2_member“
Na, danneibt es wohl beim Stand der Backups. Ist zu verschmerzen, dafür
sind sie ja da.
Hauke Laging
> Damit komme ich weiter, die Bezeichnungn sind mir allerdings ebenfalls
> unbekannt :) Ohne LVM habe ich die nie gebraucht.
Die braucht man auch mit LVM normalerweise nie.
Wenn der Rechner nicht bootet, weil z.B. das Modul für den SATA-Controller
nicht in der initrd ist, dann bekommt man eine Meldung der Art
could not find root filesystem on 8:1
Der Kernel kennt nur diese Nummern, die Namen in /dev interessieren ihn
nicht.
# ls -l /dev/sda*
brw-rw---- 1 root disk 8, 0 26. Jul 11:20 /dev/sda
brw-rw---- 1 root disk 8, 1 4. Aug 02:14 /dev/sda1
brw-rw---- 1 root disk 8, 10 4. Aug 02:14 /dev/sda10
brw-rw---- 1 root disk 8, 11 4. Aug 02:14 /dev/sda11
brw-rw---- 1 root disk 8, 2 4. Aug 02:14 /dev/sda2
brw-rw---- 1 root disk 8, 3 4. Aug 02:14 /dev/sda3
brw-rw---- 1 root disk 8, 4 26. Jul 11:20 /dev/sda4
brw-rw---- 1 root disk 8, 5 4. Aug 02:14 /dev/sda5
brw-rw---- 1 root disk 8, 6 4. Aug 02:14 /dev/sda6
brw-rw---- 1 root disk 8, 7 4. Aug 02:14 /dev/sda7
brw-rw---- 1 root disk 8, 8 4. Aug 02:14 /dev/sda8
brw-rw---- 1 root disk 8, 9 4. Aug 02:14 /dev/sda9
ls zeigt Dir die major und minor numbers von block und character devices.
SCSI- und libata-Platten (also IDE-Platten, die als sd? benannt werden)
können bis zu 15 Partitionen haben bzw. mehr kann der Kernel dann wohl nicht
ansprechen. Deshalb ist sdb 8:16 und sdc 8:32.
>> War das die einzige Platte, die zu der volume group gehörte?
>
> Ja, war es.
Dann ist mir zwar immer noch ein Rätsel, wie die Metadaten geschreddert
werden konnten, aber an die Daten sollte man dann in der von mir
beschriebenen Weise leicht herankommen können. Vorausgesetzt, irgendwas hat
nicht insgesamt wild auf der Platte herumgeschrieben.