Am 03.02.2017 um 19:22 schrieb Siegfrid Brandstätter: > Hallo Peter, > > Am Freitag, 3. Februar 2017, 09:00:36 schrieb Peter Ludikovsky: > >> Am 03.02.2017 um 00:03 schrieb Thomas Michalka: > >> > Hallo, > >> > > >> > Am 02.02.2017 um 15:57 schrieb Siegfrid Brandstätter: > >> >> Hallo, > >> >> > >> >> Am Freitag, 27. Januar 2017, 22:45:34 schrieb Peter Ludikovsky: > >> >>> Am 26.01.2017 um 22:30 schrieb Siegfrid Brandstätter: > >> >>>> [much snip] > > > >> > >> @Sigfried: > >> Kannst du mal genau auflisten, welche Platten, Partitionen, > >> Crypto-Devices, … du am Anfang hattest, und welche Aktionen du gesetzt > >> hast? Ich habe in dem Thread irgendwann die Übersicht verloren. > >> > > Garantieren kann ich nicht ob ich noch alles genau rekonstruieren kann, > aber ich versuche es mal. > > Am Anfang hatte ich: > > #/dev/mapper/xvt1-Daten /Daten ext4 auf einer HDD, > > > > auf einer neuen SSD ohne LVM: # /n_Daten /dev/sdb8 > UUID=b0569962-ced4-48dd-99b5-07eb7135c4d5 /n_Daten ext4 > > Diese ist nun /Daten weiterhin ohne LVM > > > > Gestern wollte ich versuchen ob dein Vorschlag geht und habe es auf > einer Externen-USB versucht auf der auch kein LVM war. > > > > Die Original Quelle war eine HDD mit LVM > > /dev/mapper/xvt1-Daten, von der hatte ich mit rsync auf eine SSD kopiert. > > Mein Ausgangsposting war deswegen, da ich diese neue /n_Daten wieder auf > den ursprünglichen Namen /Daten bringen wollte. Dann hattest du mir den > Rat gegeben wie das mit vgextend und pvmove ginge. Dazwischen hatte ich > aber schon alles erledigt und auch per fstab umbenannt. Alles ging gut. > > Nun machte ich den Fehler ohne noch mals nachzufragen ob das wirklich > geht, auf eine Platte ohne LVM diese Aktionen durchzuführen. > > > > df -h > > > > /dev/sdb8 20G 3,2G 16G 18% /Daten (die SSD ohne LVM) > > /dev/dm-12 1,8T 735G 1005G 43% /media/sigi/sg2T (luks-USB ohne LVM) > > > > # vgextend xvt1 /dev/dm-12 > > Physical volume "/dev/mapper/luks-b50d4cb0-7c32-4c3d-9f59-d5ddd902df23" > successfully created > > Volume group "xvt1" successfully extended > > root@debian:/home/sigi# pvmove --atomic --name Daten /dev/sdb8 /dev/dm-12 > > Physical volume /dev/sdb8 not found > > Run `pvmove --help' for more information. > > > > Auf jeden Fall war es mein eigener Fehler dies ohne neue nachfrage zu > machen. > > Es ist zwar blöde das ich jetzt einen Haufen Filme verloren habe, aber > was soll`s, es gibt schlimmeres. Meine wichtigen Daten habe ich zum > Glück ja noch extra auf einer Backup Platte. > > -- > > Liebe Grüße > > Sigi > So, ich habe dann mal eine "gute" und eine schlechte Nachricht. Die gute ist, dass durch keine Aktion so weit viel überschrieben wurde. Das vgextend das du gemacht hast hat genau nur die verschlüsselte Platte als ein Physical Volume für LVM markiert, und der Volume Group xvt1 zugewiesen. Diese Markierung passiert in einem Physical Extend am Anfang des Block Device. Da sdb8 kein Teil dieser VG ist wurden dann auch keine Daten verschoben. Und jetzt zur schlechten Nachricht: das PE von dem ich oben rede kann bis zu 32MiB groß sein, und ich vermute dass LUKS auch alle Infos am Anfang der Platte speichert. Wie groß die tatsächlich sind findest du wenn du vgdisplay xvt1 eingibst in der Zeile "PE Size" (ca. 5. von unten) OK, gerade nachgelesen, LUKS speichert sich alle Infos in den ersten 4096 Bytes eines Volumes, und anscheinend ohne diese Infos an anderer Stelle nochmal abzulegen. Ich muss mich noch etwas einlesen, ob man nicht mit den gleichen Parametern zumindest den Header rekonstruieren kann um wieder auf die Daten zugreifen zu können. Lg /peter
Attachment:
signature.asc
Description: OpenPGP digital signature