Re: Altes System auf neue Platte
Mechtilde - 22.05.18, 06:20:
> So oder so ähnlich werde ich es ausprobieren. Eine weitere Recherche
> mit "Suchmaschine" hat mich auch zu Clonezilla geführt.
>
> Ich werde dazu auf jeden Fall eine Dokumentatin veröffentlichen.
Ich habe es bislang so gemacht:
- Festplatte oder SSD in ein externes Gehäuse.
- Via Live CD, in der Regel GRML, gebootet.
- Neues Laufwerk partitioniert und ggf. mit LVM konfiguriert.
- Dateisysteme auf dem neuen Laufwerk angelegt und entsprechend unter /
mnt/install gemountet. Zuerst das neue /, dann darunter Verzeichnisse
für die anderen Mount-Punkte angelegt und die Dateisysteme dafür
gemountet.
- Dateisysteme auf dem alten Laufwerk gemountet, z.B. unterhalb von /
mnt/quelle.
- Via rsync -aAHXS alle Dateien rüber kopiert.
- mount -o bind /dev /mnt/install/dev, das gleiche mit /dev/pts, /proc
und /sys
- chroot /mnt/install
- grub-install
Ich hab das teilweise auch mal via externer Backup-Platte gemacht. Das
Vorgehen ist ganz ähnlich, jedoch sicherer bei etwaigen Fehlern mit den
Befehlen, da es dann 2 Backups gibt :), das alte Laufwerk und auf der
Backup-Platte. Backup erstellen. Altes Laufwerk raus, neues Laufwerk
rein, mit GRML booten. Von Backup-Laufwerk oder altem Laufwerk rüber
kopieren.
Nachteil ist: Es sind so einige Schritte und es ist auch eher nichts für
einen Einsteiger. Vorteil: Ich lerne dabei, wie das funktioniert, und
wenn ich das einmal begriffen habe, dann kann ich Daten quasi von
überall nach überall kopieren. Ich hab dieses Laptop ausnahmsweise mal
neu installiert damals, da ich von 32 auf 64 Bit wechselte. Sonst habe
ich immer nur kopiert. Oder Festplatten umgebaut. Wie schon zu Amiga-
Zeiten.
Bei SSD´s bin ich kein Freund von blockbasierten Ansätzen, weder für die
Verschlüsselung, noch fürs Kopieren. Denn diese schreiben oft auf
sämtliche Blöcke der SSDs. Es gibt Ausnahmen wie Dump/Restore (so ein
Mittelding), xfs_copy, ntfsclone. Dadurch belasten sie den Flashspeicher
stärker. Für eine einmalige Aktion beim Kopieren sehe ich da nicht so
das Thema, da sich via fstrim die nutzlos kopierten unbelegten Blöcke
nachträglich wieder freigeben lassen.
Dauerhaft wie LUKS verschlüsseln, das mache ich immer noch nicht. Ich
denke aber, dass SSDs auch damit zurecht kommen. Es wird aber die Dauer,
die eine SSD performant arbeitet reduzieren, es sei denn ich nutze für
dm-crypt auch Discard / Trimming und offenbare damit, wo die
verschlüsselten Daten liegen und wo nicht.
Eine Möglichkeit ist natürlich, bei Nutzung von LVM, einfach anfänglich
nicht den kompletten Speicherplatz für LUKS zu verwenden. Dann hat die
SSD einfach noch eine zusätzliche Reserve.
Ich nutze derzeit ecryptfs und erwäge einzelne Verzeichnisse mit Plasma
Vault und cryfs zusätzlich nochmal getrennt verschlüsseln. Wie aktiv
ecryptfs weiterentwickelt wird, weiß ich nicht. Hier funktioniert es
gut, ist aber etwas komplex. Das Passwort ändern ist kein Spaß. Ich
würde an sich mit fscrypt gehen, das in Ext4 und F2FS nativ eingebaut
ist. Aber für BTRFS gibt es weder fscrypt noch ein anderes Verfahren.
cryfs ist an sich super, hat aber den Nachteil via FUSE zu
funktionieren. ecryptfs ist hier gefühlt etwa doppelt so schnell wie
EncFS, das ich vorher nutzte und das via FUSE geht. Wie das mit cryfs
ist, weiß ich nicht.
Ciao,
--
Martin
Reply to: