Re: Linux: Einzelne Festplatte nach RAID1 erweitern? dm-cache? ZFS?

[Raphael Eiselstein <rabe@xxxxxxxxx>]

Hallo Marc,

On Wed, May 29, 2013 at 11:29:20PM +0200, Marc Haber wrote:
> On Wed, May 29, 2013 at 12:56:38AM +0200, Raphael Eiselstein wrote:
> > On Mon, May 27, 2013 at 08:13:57PM +0200, Marc Haber wrote:
> > > On Mon, May 27, 2013 at 07:57:54PM +0200, Raphael Eiselstein wrote:
> > > > Variante 1: Ist es moeglich hier nachtraeglich und verlustfrei ein Mirror 
> > > > draus zu bauen? Falls ja, genaue Vorgehensweise? mdadm? Wie genau?
> > > 
> > > 1 Zweite Platte dazustecken
> > > 2 RAID 1 mit nur einem Member bauen
> > > 3 Daten umkopieren
> > > 4 Erste Platte als zweites Member in das RAID hinzunehmen.
> > 
> > Ich habs jetzt mal in einer VM mit dem "Ich will aber" versucht und bin
> > wohl auch ein Stueck weit gekommen.
> 
> [viel geloescht]
> 
> Das, was Du da gemacht hast, ist nicht das, was ich vorgeschlagen hatte.

Das stimmt. Und ich hatte auch gestern im IRC kurz begruendet, warum ich
die Daten nicht kopieren will sondern die Platte untendrunter clonen,
nochmal hier: Es handelt sich um rund 2TB Daten auf einer 3TB Platte. 
Die Daten liegen in LVM, LVM *auf* dm-crypt

> mein Schritt 2 waere gewesen "RAID 1 mit nur einem Member _auf der
> neuen Platte_ bauen (leer)".

Wuerde ich das RAID1 zunaechst wie von Dir beschrieben mit der neuen Platte
initial aufsetzen, muesste ich 2TB an Daten durch dm-crypt lesen und 2TB
durch dm-crypt wieder schreiben.

Wenn ich allerdings die Partition *unter* dm-crypt nach dem von mir
beschriebenen Verfahren in ein RAID1 "transformiere", dann muss nur "md" 
eine Kopie der Bloecke auf der Platte erzeugen. Das ist dann unverschluesselt
(Rohdaten) und kann mehr oder weniger direkt per DMA (d.h. mehr oder
weniger an der CPU vorbei) von sdb1 auf sdc1 geschoben werden.

Daher war auch meine Frage, ob man verlustfrei eine bestehende Platte
(Partition) in ein RAID umwandeln kann. Zu mindest fuer mein Experiment
 in einer VM mit einem ext4 in der Partition hat das wunderbar geklappt
(mit bisschen nachbessern).

Die noch offene Frage ist, wo dm-crypt seine Metadaten nachher sucht: am
Anfang oder am Ende des Volumes? Wenn am Ende, dann wird die oben
beschriebene Methode dazu fuehren, dass beim Einbau von "md" hinten die
relevanten Bloecke ueberschrieben werden, wo dm-crypt seine Metadaten
vorhaelt. Das waere aergerlich. Muss ich expermentell ermitteln oder
nochmal Doku lesen. Oder jemand kanns mir verraten ;-)
 
> Fuer die Operation am offenen Herzen der bestehenden Daten waere ich nie
> im Leben mutig genug.

Die wirklich wichtigen Daten habe ich ohnehin nochmal auf einem
Backup-Medium. Nicht alle Daten auf dieser Platte sind gleichermassen
wichtig oder sensibel. Insofern ist das mit dem offenen Herz zwar
richtig, aber nicht lebensbedrohlich.
 
> > Wenn ich dm-crypt *in* LogicalVolumes gelegt haette, haette ich den
> > Vorteil, dass ich nicht alle LVs verschluesselt haette aber auch den
> > Nachteil, dass ich beim booten oder mounten dann fuer alle
> > verschluesselten LVs Passwoerter eintippen muss, die ich
> > mir selbstverstaendlich alle merken muss, vor allem welches zu welchem.
> 
> Der kanonische Trick ist, den Schluessel fuer die anderen LVs auf der
> ersten LV abzulegen und ein Keyscript zu verwenden, die andern LVs
> automatisiert aufzuschliessen wenn die erste LV aufgeschlossen ist.
Das mit den Schluesseln statt passphrase ist definitiv eine Option. Werde
ich beim naechsten mal in Erwaegung ziehen.

> Oder man macht dm-crypt mit dem TPM, das auf dem Rechner steckt, dann
> ist es egal dass der Schluessel n-mal ausgelesen wird.

Da hab ich null Erfahrung mit und wueste nichtmal, ob mein n36L das
ueberhaupt hat. Tendenziell will ich die Platten auch in einem anderen 
Rechner wieder entschluesseln koennen. Praxistipps und Erfahrungsberichte 
willkommen.

Viele Gruesse
Raphael
-- 
Raphael Eiselstein <rabe@xxxxxxxxx>               http://rabe.uugrn.org/
xmpp:freibyter@xxxxxx  | https://www.xing.com/profile/Raphael_Eiselstein   
GnuPG:                E7B2 1D66 3AF2 EDC7 9828  6D7A 9CDA 3E7B 10CA 9F2D
.........|.........|.........|.........|.........|.........|.........|..



-- 
UUGRN e.V. http://www.uugrn.org/
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: https://wiki.uugrn.org/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/