Как перенести корневую файловую систему в другой раздел из работающей системы?

Question

Я пытаюсь перенести корневую файловую систему из ext4 в другой тип раздела (zfs) и начал с простого

rsync -a --exclude=/boot --exclude=/mnt --exclude=/media --exclude=/tmp 
--exclude=[all zfs pools with default mountpoint] 
/ /target/directory/mountpoint/

затем передача застряла в других файлах в /proc , после добавления --exclude=/proc rsync застряла в файле в /sys/devices , что привело меня к отказу от проб и ошибок. Прочитав man proc и about /sys (Wikipedia), я понимаю, что для его поиска требуется больше исследований, чем для простого решения. Я надеюсь, что кто-то может помочь. Корневой системой является Ubuntu 14.04 amd64 (также действующая система, но не стесняйтесь вносить предложения, если это ограничивает проблему).

Конечно, легко загружаться в работающую систему и копировать туда данные, но это обходное решение только для вопроса.

Answer 1

Я собираюсь начать с заявления об отказе от ответственности, поскольку у меня нет системы, которую я мог бы использовать, чтобы проверить, действительно ли загрузка будет работать. Этот ответ основан на моем понимании, и вы должны пробовать его только в системе разработки, пока не подтвердите, что он работает.

Поскольку /dev , /sys , /proc - все виртуальные файловые системы, я думаю, ОС должна создавать их содержимое при загрузке. Если это правда, вы должны быть в состоянии сделать:

rsync -ax / /target/directory/mountpoint

-X указывает rsync не пересекать границы файловой системы, поэтому он пропускает виртуальные файловые системы и не требует указания пулов zfs. Это все еще создаст точки монтирования, но они будут пусты.

Если ваш /tmp не является собственным разделом и вы не хотите копировать эти файлы, вам все равно придется вручную - --exclude его.

Answer 2

Проверьте, используете ли вы LVM. Если это так, вы можете делать снимки файловой системы, используя LVM, а затем копировать оттуда.

Они были изобретены, потому что резервные копии должны быть созданы из неподвижной файловой системы, или резервная копия не очень полезна. Снимки решат как проблему с несколькими устройствами, так и проблему с временными файлами.

Обратите внимание, что если у вас есть какие-либо большие файлы, например активные базы данных, rsync и другие резервные копии могут создавать несовместимые версии, поскольку части файла будут скопированы до изменения базы данных, а другие скопированы после. Снимки - это тоже попытка решить эту проблему.

Примечание: btrfs имеет превосходную форму моментального снимка файловой системы, но если вы уже используете ext4, на этот раз уже слишком поздно.

Answer 3

Адъюнкт: если вы можете (вы можете, если вы находитесь на локальной консоли, вы не можете, если вы подключены через ssh или вам нужно поддерживать систему полностью работающей), перейдите на уровень запуска 1 ("однопользовательский режим", команда "init 1"), прежде чем делать такую вещь. Это остановит все несущественные процессы, которые могут изменить вещи в файловой системе, пока вы копируете ее.

Обращайте внимание на настройку вашего fstab, особенно если используются UUID.

Подумайте об использовании «chroot /where /the /new /root /is /mount /bin /bash» для проверки вашей новой реплицированной файловой системы и, возможно, для переустановки загрузчика. Возможно, вам придется вручную смонтировать /proc и /sys под chroot.

Если переустановите загрузчик из chroot, убедитесь, что /etc /mtab (в системе chrooted) не содержит мусора, который может сбить установщик загрузчика. Если это grub 1.x, возможно, вам придется удалить (новый) файл /boot/device.map.

Если вы хотите обезопасить себя с /dev, вы можете заполнить его (в новой файловой системе) "MAKEDEV generic" - это создаст набор файлов устройств "под" точкой монтирования udev, что предотвратит серьезную поломку вашей системы. при запуске, если Udev не работает.