Re: Umzug von Daten
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.
> >>> 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” ?
> >>> Auf der SSD habe ich mir beim Partionieren nur eine normale
> >>> Partiton angelegt
>
> Ist das die /dev/sdb8, die Du weiter unten erwähnst?
>
Ja.
> >>>, 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?
>
Ja, aber nun ist das /n_Daten nur mehr ein /Daten. Das ist mir gelungen.
Zumindest was.
> 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 :-)
>
Ja genau.
> >>> aber es gelingt mir nicht die neue umzubenennen auf /Daten.
>
Das ist überholt, Es ist bereits geändert 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.
>
Das stimmt, es geht so.
> >>> # /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?
>
Nein, dass war ein Eintrag der durch die Änderung in der fstab von /n_Daten
auf /Daten blieb.
> 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.
Es ist von /dev/sdb8 /Daten auf der SSD.
>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
> >>>
Befindet sich auf /dev/sdb8 /Daten auf der SSD
> >>> 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.
>
> 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.
>
Das dürfte leider passiert sein.
> 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.
Ja.
>
> > 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 ...
>
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. Diese Platte habe ich erst vor ca. 3 Wochen erstanden.
> NB:
> Verschlüsselst Du jedes einzelne Logical Volume bzw. jedes einzelnen
> Dateisystem für sich?
Nein, ich habe die ganze Externe-USB verschlüsselt.
> 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.
:
> > 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. Die verschlüsselte
ist eine Externe-USB - /dev/dm-1x
>
> Also was ist jetzt die Quelle und was das Ziel?
Siehe oben.
> Ist das Quell-Dateisystem in dem LV "Daten" in der VG "xvt1"?
War mal so. Jetzt nicht mehr.
> 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.
> > 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.
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 ;-)
Ich hoffe du verstehst meine Antworten zu deinen Fragen, danke für deine Hilfe!
--
Liebe Grüße
Sigi
Reply to: