Re: Umzug von Daten
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).
>>> Dies ist mir auch gelungen
Halten wir auch fest: alle Daten sind erfolgreich kopiert bzw.
verschoben, und zwar von irgendwoher auf die SSD.
>>>, 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?
(Tipp: Würde der Volume Group immer ein "VG" und einem Logical Volume
ein "LV" voranstellen, um Verwechslungen mit den Namen von
Verzeichnissen bzw. Mountpoints zu vermeiden)
>>> Auf der SSD habe ich mir beim Partionieren nur eine normale
>>> Partiton angelegt
Ist das die /dev/sdb8, die Du weiter unten erwähnst?
>>>, damit sich diese aber nicht mit der alten /Daten
>>> gestört hat habe ich diese neue /n_Daten benannt.
Auch hier eine kleine Präzisierung: Du hast ein Dateisystem (ext4) auf
der Partition /dev/sdb8 (?) angelegt und dieses in das mittels "mkdir
/n_Daten" erzeugte Verzeichnis gemountet.
Habe ich das so richtig verstanden?
Was Du _nicht_ getan hast: Die _Partition_ hast Du nicht benannt, denn
die wird vom System benannt, d.h.
- beim Booten das ganze Gerät buchstabiert (dev/sd<Buchstabe> /1/) bzw.
- beim Partitionieren die Partition nummeriert (/dev/sdb<Nummer> /2/).
/1/ Je nach Reihenfolge der Erkennung des Geräts beim Booten!
Daher Buchstaben je nach System/BIOS/EFI evtl. unterschiedlich!
/2/ Nummer je nach Zahl der vorher angelegten Partitionen!
Eindeutig sind die Gerätedateien /dev/disk/by-*
Mir sind am liebsten die /dev/disk/by-id, weil ich daran den Hersteller
des Massenspeichers und oft die Größe ablesen kann, und somit leichter
eine Zuordnung vor dem inneren Auge habe. Aber die /dev/disk/by-label/*
bleiben beim Wechsel des Massenspeichers in einen anderen Rechner auch
erhalten, weil die Label fest zu den Dateisystemen auf den Partitionen
gehören. Bei mir ist z.B. das Root-Dateisystem mit "ROOT_FS" gelabelt.
jedoch sind die Label nicht zwingend eindeutig (!) in einem Rechner,
weil die Namen selbstgewählt sind.
Aber all dies nützt einem nichts, wenn man ein LVM-System haben will,
weil LVM ja gerade die Partitionen von den LVs logisch entkoppelt. Die
LV-Gerätedateien werden dann halt vom Device Mapper erzeugt.
>>> Nun habe ich zwar die Daten in beiden Partitionen
Also kopiert und nicht verschoben. Dann ist das schon mal gelungen :-)
>>> aber es gelingt mir nicht die neue umzubenennen auf /Daten.
Willst Du mit "mv /n_Daten /Daten" das Verzeichnis, das als Mountpoint
dient, umbenennen?
Und das, während eines oder beide Dateisysteme noch eingehängt sind?
1) Ich würde kein Verzeichnis, das als Mountpoint dient, umbenennen,
während ein Dateisystem eingehängt ist (man müsste spaßeshalber mal
ausprobieren, was das für Nebeneffekte zeitigt; hängt vielleicht
davon ab, woran das Mounten eigentlich erfolgt, am Verzeichnisnamen
oder an der Inode-Nr)
2) Ich würde nach dem Kopieren von /Daten auf /n_Daten erst beide
Dateisysteme aushängen: "umount /Daten /n_Daten"
3) Dann würde ich das vorige Zieldateisystem unter /Daten einhängen:
"mount /dev/sdb8 /Daten"
4) Dann würde ich in der /etc/fstab die Gerätedatei ändern. Aus den
oben genannten Gründen würde ich nicht /dev/sdb8 nehmen, sondern die
entsprechende Geräte-ID oder die Dateisystem-UUID, weil sdb8 nicht
unbedingt so erhalten bleibt und Du die heutigen Umstände vergessen
haben wirst, wenn Du eines Tages den Massenspeicher an ein neues
Mainboard anschließen wirst.
>>> In der fstab alleine reicht ja leider nicht aus.
Doch, jedenfalls, was das künftige Mounten beim Systemstart und den
Befehlt "mount /Daten" (zugehöriger Gerätename wird automatisch in der
fstab gesucht) angeht.
>>> # /Daten was on /dev/sdb8 during installation
Seltsam, ich dachte nach Deiner obigen Darstellung, dass unter /Daten
das Dateisystem des LVs gemountet war, nicht das auf der Partition
/dev/sdb8. Oder ist /dev/sdb8 ein Physical Volume, das in der VG
/dev/mapper/xvt1 ist?
Allerdings kann ich natürlich nicht sagen, welches Gerät die unten
stehende UUID hat -- kann das LV-Gerät /dev/mapper/xvt1-Daten sein, aber
auch die UUID von /dev/sdb8. Ob und zu welchem Blockgeräte sie gehört,
kannst Du mit "blkid | grep b0569962" herausfinden.
>>> UUID=b0569962-ced4-48dd-99b5-07eb7135c4d5 /Daten ext4
>>> defaults,discard,relatime, 0 2
>>>
>>> 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?
Er hatte doch auf der SSD gar kein Physical Volume angelegt, sondern ein
Dateisystem direkt auf der Partition. Dein Rat ist nur dann nützlich,
wenn er als Speicherziel auch ein LVM-Gerät (LV) hätte haben wollen. Da
vgextend auf dem Device ein Physical Volume implizit einrichtet, ist
Dein Rat vielleicht sogar gefährlich, weil dadurch das Dateisystem
mitsamt der schon kopierten Daten vielleicht zerstört wird.
Außerdem geht pvmove nur zwischen Physical Volumes:
$ pvmove --atomic --name xvt1/Daten /dev/<pvname> /dev/sdb8
falls /dev/sdb8 wirklich die Partition auf der SSD ist. Aber es war ja
die Absicht, die Daten des ursprünglichen LVs/Dateisystems auf die
Partition der SSD zu bekommen, nicht umgekehrt.
> Heute habe ich endlich dafür genügend Zeit um dies durchzuführen. Dabei ergibt
> sich aber nun folgendes Problem. Die /Daten auf /dev/sdb8 sind ja derzeit in
> keinem PV sondern auf einer normalen Partition.
Wenn Du die Daten doch in dem LV xvt1/Daten haben wolltest, dann hättest
Du _anstatt_ der Kopieraktion entweder mit "pvcreate /dev/sdb8" und mit
"vgextend xvt1 /dev/sdb8" oder gleich nur mit dem zweiten Befehl (Grund
siehe oben) das Physical Volume erzeugen und damit die Volume Group
erweitern sollen. Danach verschiebt Dir ein pvmove die Physical Extents
vom Quell-PV auf das Ziel-PV, ohne dass Du auf der Ebene des
Dateisystems etwas kopieren musst.
Wenn Du trotz LVM lieber zwischen Dateisystemen kopierst und Du
gleichzeitig die Daten vollständig auf die SSD übertragen willst, dann
musst Du sicherstellen, dass keine Physical Extents des Quellmediums (es
könnte ja freie PEs geben) dem Ziel-LV zugeordnet sein können. Das geht
m.E. nur, indem Du das Ziel-LV in einer neuen VG erzeugst, weil nur dann
die PVs und damit deren PEs sicher voneinander getrennt sind. Nach dem
Erzeugen und Mounten des Ziel-Dateisystems kannst Du die Daten auf der
Dateisystemebene kopieren. Freilich ist das viel umständlicher.
> # 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 ...
> 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?
NB:
Verschlüsselst Du jedes einzelne Logical Volume bzw. jedes einzelnen
Dateisystem für sich?
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
> 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.
Also was ist jetzt die Quelle und was das Ziel?
Ist das Quell-Dateisystem in dem LV "Daten" in der VG "xvt1"?
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?
> Physical volume /dev/sdb8 not found
Vielleicht ist der Pfad zum LV hinter "--name" nicht richtig und müsste
"xvt1/Daten" lauten, wie ich weiter oben schon vermutet habe.
Ich rate dir dringend, die LVM-Doku zu lesen, bevor Du irgendwelche
zusammenhanglos gegebenen Kommandos als Tipps ungeprüft übernimmst.
Immerhin manipulierst Du hier als Admin sehr tiefgreifend das System,
was zum totalen Datenverlust führen kann. Ich rate deswegen auch
dringend zu einem umfassenden Backup der Daten. Und experimentiere
lieber erst mal mit Versuchsdaten, nicht mit den richtigen und wichtigen.
>> Damit werden die Daten innerhalb der Volume Group auf die SSD verschoben
>> ohne dass du sonst irgendwelche Änderungen machen musst, oder irgendwas
>> außer Betrieb nehmen.
Ich müsste erst mal nachlesen, ob das auch mit einem gemounteten
Dateisystem funktioniert, denn was passiert, wenn während der
Verschiebung der PEs auf das Ziel-PV Dateisystemzugriffe passieren? Kann
LVM dynamisch LEs auf neue PEs mappen während der Dateisystemtreiber auf
ein Blockdevice zugreift, oder blockiert LVM den Zugriff auf ein
LV-Blockdevice während pvmove, oder wird nur mit temporären Mirror-LVs
gearbeitet bis die Inhalte aller PEs in das neue PV transferiert sind?
Im letzteren Fall müsste ein Dateisystem-Zugriff nur sehr kurz blockiert
werden.
Trotzdem:
Vorsichtshalber das Dateisystem des Quell-Mediums vor pvmove aushängen!
Oder mal ausprobieren, was passiert, wenn man pvmove aufruft während
eine größere Datei gelesen oder geschrieben wird, oder während viele
kleinere Dateien gelesen oder geschrieben werden.
> Gilt dies also nur wenn die Daten auch schon auf einer Festplatte mit LVM
> liegen?
So ist es. Das pvmove ist nur sinnvoll für die Verschiebung von Daten
von einem Quell-LVM-PV auf ein [oder mehrere] Ziel-LVM-PV[s].
Sollen die frei gewordenen PEs auf dem Quell-Speichermedium nicht mehr
nutzbar sein, dann solltest Du es mit "vgreduce xvt1 <pvname>" aus der
VG entfernen, bevor Du z.B. LVs erweiterst oder weitere LVs erzeugst.
Ich würde Dir generell raten, die recht guten Manpages der LVM-Befehle
zu lesen, bevor Du Operationen durchführst, die Du (noch) nicht richtig
verstehst.
Oder mit Versuchsdaten bzw. Kopien auf eigenen Medien experimentieren.
Dann bleiben nicht mehr viele Fragen offen :-)
Ich hoffe, Deine Daten sind noch alle da.
Gruß, Tom
Reply to: