Ich versuche ein Root-Dateisystem von ext4 auf einen anderen Partitionstyp (zfs) zu migrieren und begann mit einem einfachen
rsync -a --exclude=/boot --exclude=/mnt --exclude=/media --exclude=/tmp
--exclude=[all zfs pools with default mountpoint]
/ /target/directory/mountpoint/
dann blieb die Übertragung bei einer anderen Datei in hängen /proc, nachdem sie --exclude=/proc rsyncbei einer Datei in hängen geblieben war /sys/devices, was mich dazu brachte, das Ausprobieren aufzugeben. Nachdem ich gelesen man procund über /sys(Wikipedia) Mir ist klar, dass es mehr Recherche erfordert, als eine einfache Lösung erfordert, um sie zu finden. Ich hoffe, jemand kann helfen. Das Root-System ist Ubuntu 14.04 amd64 (das Live-System auch, aber machen Sie gerne Vorschläge, wenn das ein einschränkendes Problem darstellt).
Natürlich ist es einfach, ein Live-System zu booten und die Daten dorthin zu kopieren, aber dies ist lediglich eine Workaround-Lösung für die Frage.
Antwort1
Ich werde mit einem Haftungsausschluss beginnen, da ich kein System habe, mit dem ich testen kann, ob das Booten tatsächlich funktioniert. Diese Antwort basiert auf meinem Verständnis und Sie sollten dies nur auf einem Entwicklungssystem versuchen, bis Sie bestätigt haben, dass es funktioniert.
Da /dev, /sys, /procalle virtuelle Dateisysteme sind, sollte das Betriebssystem meiner Meinung nach deren Inhalt beim Booten erstellen. Wenn dies zutrifft, sollten Sie Folgendes tun können:
rsync -ax / /target/directory/mountpoint
Das -x weist rsync an, Dateisystemgrenzen nicht zu überschreiten. Daher werden virtuelle Dateisysteme übersprungen und die ZFS-Pools müssen nicht angegeben werden. Die Einhängepunkte werden trotzdem erstellt, aber sie sind leer.
Wenn Ihr /tmp keine eigene Partition ist und Sie diese Dateien nicht kopieren möchten, müssen Sie --excludedies trotzdem manuell tun.
Antwort2
Überprüfen Sie, ob Sie LVM ausführen. Wenn ja, können Sie mit LVM Snapshots des Dateisystems erstellen und dann von dort kopieren.
Diese wurden erfunden, weil Backups von einem ruhenden Dateisystem erstellt werden müssen, da das Backup sonst nicht sehr nützlich ist. Snapshots lösen sowohl Ihr geräteübergreifendes Problem als auch das Problem mit vorübergehenden Dateien.
Beachten Sie, dass bei großen aktiven Dateien, wie z. B. Datenbanken, rsync und andere Backups wahrscheinlich inkonsistente Versionen erzeugen, da Teile der Datei vor einer Datenbankänderung kopiert werden und andere danach. Snapshots sind ebenfalls ein Versuch, dieses Problem zu lösen.
Hinweis: btrfs verfügt über eine bessere Form der Dateisystem-Snapshot-Erstellung, wenn Sie jedoch bereits ext4 ausführen, ist es hierfür diesmal zu spät.
Antwort3
Zusatz: Wenn Sie können (Sie können, wenn Sie an der lokalen Konsole sind, Sie können nicht, wenn Sie über SSH verbunden sind oder das System voll am Laufen halten müssen), wechseln Sie zu Runlevel 1 ("Einzelbenutzermodus", der Befehl lautet "init 1"), bevor Sie so etwas tun. Dadurch werden alle nicht wesentlichen Prozesse gestoppt, die Dinge im Dateisystem ändern könnten, während Sie es kopieren.
Denken Sie daran, Ihre fstab anzupassen, insbesondere wenn UUIDs verwendet werden.
Erwägen Sie die Verwendung von „chroot /where/the/new/root/is/mounted /bin/bash“, um Ihr neu repliziertes Dateisystem zu testen und möglicherweise Ihren Bootloader neu zu installieren. Möglicherweise müssen Sie /proc und /sys manuell unter dem Chroot mounten.
Wenn Sie einen Bootloader von chroot neu installieren, stellen Sie sicher, dass /etc/mtab (im chroot-System) keinen Müll enthält, der den Loader-Installer verwirrt. Wenn es sich um Grub 1.x handelt, müssen Sie möglicherweise die (neue) Datei /boot/device.map löschen.
Wenn Sie mit /dev auf Nummer sicher gehen wollen, können Sie es (im neuen Dateisystem) mit „MAKEDEV generic“ füllen – dadurch wird ein Satz Gerätedateien „unter“ dem Udev-Einhängepunkt erstellt, der einen schweren Systemabsturz beim Start verhindert, falls Udev nicht funktioniert.