Re: Umzug von Daten
Hallo Sigi,
Am 03.02.2017 um 01:29 schrieb Siegfrid Brandstätter:
> Hallo Tom,
> Am Freitag, 3. Februar 2017, 00:03:29 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:
>>>>> Hallo,
>>>>> nach dem Kauf einer SSD möchte ich gerne teilweise die alten Daten
>>>>> dorthin
>>>>> verschieben.
>>
>> Halten wir fest: das Zieldateisystem befindet sich auf der SSD (nur,
>> damit wir das nachher nicht vergessen).
>>
> Nein das war früher so, nun war dass die Quelle. Siehe die andere Mail von
> mir.
Habe leider nicht mitbekommen, dass Du sozusagen einen zweiten
Anwendungsfall gepostet hast.
>>>>> Dies ist mir auch gelungen
>>
>> Halten wir auch fest: alle Daten sind erfolgreich kopiert bzw.
>> verschoben, und zwar von irgendwoher auf die SSD.
>>
> Ja das ist Richtig!
>
>>>>> , aber mein Problem ist folgendes.
>>>>>
>>>>> Anfangs hatte ich eine LVM mit dem Namen /Daten /dev/mapper/xvt1-Daten
>>>>> /Daten
>>
>> Wir müssen mal die Sprache präzisieren. Verstehe ich es richtig, dass Du
>> das Dateisystem auf dem Logical Volume namens "Daten" (Gerät bzw.
>> Symlink "/dev/mapper/xvt1-Daten" auf "/dev/dm-ij" in der Volume Group
>> "xvt1") am Mountpoint /Daten eingehängt hast?
>>
> Ja. Was bedeutet das (ij) nach “/dev/dm-”? Diese Angaben ändern sich ja je
> nach dem wie viele Devices vorhanden sind. Daher “ij” ?
Sorry, sind nur Platzhalter, weil ich ja nicht weiß, welche Ziffern bei
Dir dort stehen. Einmal war es 12, glaube ich.
>>>>> Wie gehe ich da richtig vor? Danke schon im voraus!
>>>>
>>>> Indem du LVM richtig nutzt:
>>>> 1) Mit vgextend die alte Volume Group erweitern
>>>>
>>>> vgextend xvt1 /dev/<ssd>
>>>>
>>>> 2) Mit pvmove die Daten auf die SSD schieben
>>>>
>>>> pvmove --atomic --name Daten /dev/sdb8 /dev/<ssd>
>>
>> Ist "Daten" alleine ein gültiger Pfad zum LV? Ist "--name xvt1/Daten"
>> nicht die richtige Angabe?
>
> #/dev/mapper/xvt1-Daten /Daten war die Bezeichnung vor dem ich auf der SSD die
> neuen Partitonen anlegte.
Hast mich falsch verstanden. Ich meinte, dass der Parameter hinter der
Option --name "xvt1/Daten" lauten müsste, denn das ist der _Pfad_ zum LV
"Daten". LV in verschiedenen VGs können den gleichen Namen haben,
weshalb ich meine, dass der Parameter hinter --name eindeutig sein muss.
Kann mich jedenfalls erinnern, dass ich häufiger so Meldungen, wie
"Volume Daten not found" erhalten habe. Meist konnte dann der Pfad zum
Volume helfen.
>>> # vgextend xvt1 /dev/dm-12
>>>
>>> Physical volume "/dev/mapper/luks-b50d4cb0-7c32-4c3d-9f59-33ddd902df23"
>>>
>>> successfully created
>>
>> Offenbar war Dein LUKS-Gerät auf /dev/dm-12 abgebildet. Jetzt hat LVM
>> dieses LUKS-Gerät als Physical Volume initialisiert ...
>>
> Ja.
>>> Volume group "xvt1" successfully extended
>>
>> ... und dessen Physical Extents (PEs) der Volume Group "xvt1"
>> hinzugefügt. Aber hattest Du nicht schon ein Dateisystem auf der
>> (verschlüsselten) Partition angelegt und Daten dahin kopiert?
>>
> Da waren keine Partitionen und kein LVM vorhanden aber es wurde ein ext4 beim
> verschlüsseln angelegt.
Hast Du das nicht in der Shell gemacht, sondern mit Hilfe einer
Admin-Software? Würde erklären, warum auch gleich ein ext4 drauf war.
Aber wenn Du noch keine Daten dorthin kopiert hast, dann ist durch
vgextend nicht wirklich etwas verloren gegangen, bis auf die Einrichtung
der Verschlüsselung und das Dateisystem ext4, weil vgextend das
/dev/dm-12 als Gerät zu impliziten Initialisierung eines PVs angesehen hat.
>> NB:
>> Verschlüsselst Du jedes einzelne Logical Volume bzw. jedes einzelnen
>> Dateisystem für sich?
>
> Nein, ich habe die ganze Externe-USB verschlüsselt.
Gut, aber da diese für Backups und zum An- und Abstecken ist, braucht es
hier ja kein LVM. Das Dateisystem legst Du dann direkt auf der
LUKS-Gerätedatei an.
Wen Du LUKS mit "man cryptsetup" genauer studierst, dann kommst du schon
auf die Sache mit dem Keyfile und mit dem zusätzlichen Passwort in einem
weiteren Slot (bis zu 8 gehen, so dass bis zu 8 Leute mit
unterschiedlichen Passwörtern das Gerät entsperren können).
>> Wenn ja, könnte das eines Tages bei mehr und mehr Volumes recht viel
>> Verwaltungsarbeit machen. Einfacher wäre es, die meistens wenigen PVs,
>> also deren Gerätedateien zu verschlüsseln, dann die entsperrten PVs in
>> die Volume Group(s) aufzunehmen. Dann musst Du Dir bei dem Erzeugen
>> eines neuen LVs und dem Anlegen eines Dateisystems darauf keine Gedanken
>> um die Verschlüsselung machen.
>> Schon beim Anlegen der PVs wäre auch eine klare Trennung zwischen
>> einerseits reinen Systemdaten und andererseits den eigenen und den
>> temporären Daten (die ja oft auch eigene Daten sind!) sinnvoll, damit
>> man ein Passwort nur einmal und nicht für jedes verschlüsselte PV
>> eingeben muss.
>> Beispiel: Eine Passwortabfrage für die Systemdaten, die z.T. schon zum
>> Booten gebraucht werden. In /etc oder einem anderen Verzeichnis
>> innerhalb der Systemdaten ein Keyfile mit einem anderen Passwort
>> (vielleicht besser mit /dev/urandom erzeugen lassen) für die eigenen,
>> nicht systemrelevanten Daten anlegen. LUKS holt sich dann von dort das
>> Passwort für diese Daten selber. Also braucht es nur das eine Passwort
>> für die Systemdaten. Guter Rat: zweiten Slot auf jedem PV mit einem
>> guten, aber merkbaren Zweitpasswort anlegen, falls mal das Keyfile
>> verloren gehen sollte. Außerdem Backups der LUKS-Header machen, denn
>> falls die mal kaputt sind, nützt Dir kein Passwort etwas! Und die
>> Wiederherstellung der LUKS-Header proben.
>>
>> :NB-Ende
> Wie ich das machen muss frage ich lieber erst mal nicht solange ich gar keinen
> Zugriff mehr auf diese Platte habe.
Ja klar, aber jedenfalls solltest Du Dich zuerst damit vertraut machen,
um entscheiden zu können, _was_ Du machen willst (z.B. _welche_ bzw.
_wie viele_ Geräte will ich verschlüsseln?). Im zweiten Schritt kannst
Du nachlesen, _wie_ das geht mit den Kommandos in der Shell. Ich würde
nicht empfehlen, die Admin-Software zu verwenden, bevor Du nicht genau
verstehst, was die macht -- habe den Verdacht, dass sie Verschlüsselung
anbietet, sobald man ein Dateisystem anlegen will; dann bekommt man die
Verschlüsselung für jedes Dateisystem einzeln :-(
Auf der Kommandozeile kannst Du genau verfolgen, was passiert, wenn du
dieses oder jenes kommandierst. Außerdem kannst Du die Befehlzeilen hier
posten.
>>> Daher anscheinend diese Meldung:
>>> # pvmove --atomic --name Daten /dev/sdb8 /dev/dm-12
>>
>> Aha: anscheinend ist /dev/sdb8 doch die Datenquelle. Und /dev/dm-12 das
>> (verschlüsselte) Ziel auf der SSD. Aber Du hattest doch geschrieben,
>> dass Du auf der SSD eine normale (verschlüsselte) Partition angelegt
>> hast, ich nehme an, das ist /dev/dm-12.
>
> Ja und nein /dev/sdb8 ist die Datenquelle und ist die SSD.
... für das Ziel USB-HDD -- weiß ich jetzt :-)
Beim ersten Kopieren war die SSD das Ziel und die Quelle ein Dateisystem
auf einem Logical Volume.
>> Sollen sowohl Quell- als auch Ziel-Datenträger PVs in einer VG sein?
>> Oder soll eins von beiden eine normale Partition mit einem Dateisystem
>> direkt darauf sein/bleiben?
>>
> Ich wollte alles auf LVM ändern, aber nun lasse ich es wie es ist.
Ist vielleicht vernünftiger, bis Du LVM eines Tages wirklich brauchst.
>> Ich hoffe, Deine Daten sind noch alle da.
>
> Da sind sie möglicherweise, aber derzeit nicht erreichbar. Zum Glück sind es
> nicht die Systemdaten. Ich könnte mich in den Hintern beißen das ich nicht
> eine andere Externe-USB versucht hatte die leer hier liegt und auch nicht
> verschlüsselt ist. Aber aus Schaden wird man klug, normalerweise zumindest ;-)
Nun ja, Du hast ja noch die "andere HDD", wo die Daten, zumindest
teilweise, noch vorhanden sein sollten.
> Ich hoffe du verstehst meine Antworten zu deinen Fragen, danke für deine Hilfe!
Gerne! Deine Antworten habe ich jetzt auch verstanden, und Du hast genug
Infos, wo Du Dich erst mal durchwühlen musst.
Gruß, Tom
Reply to: