Я пытаюсь перенести корневую файловую систему из 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и о /sys(Википедия) Я понимаю, что для того, чтобы найти простое решение, мне нужно провести больше исследований, чем требуется для его поиска. Надеюсь, кто-нибудь сможет помочь. Корневая система — Ubuntu 14.04 amd64 (также и живая система, но не стесняйтесь предлагать варианты, если это ограничивающая проблема).
Конечно, легко загрузить работающую систему и скопировать данные туда, но это всего лишь обходной путь решения вопроса.
решение1
Я собираюсь начать с отказа от ответственности по этому поводу, поскольку у меня нет системы, которую я мог бы использовать, чтобы проверить, будет ли загрузка работать. Этот ответ основан на моем понимании, и вы должны пробовать это только на системе разработки, пока не убедитесь, что это работает.
Поскольку /dev, /sys, /procвсе являются виртуальными файловыми системами, я думаю, что ОС должна создавать их содержимое при загрузке. Если это правда, вы должны иметь возможность сделать:
rsync -ax / /target/directory/mountpoint
-x сообщает rsync не пересекать границы файловых систем, поэтому он пропустит виртуальные файловые системы, и нет необходимости указывать пулы zfs. Он все равно создаст точки монтирования, но они будут пустыми.
Если ваш /tmp не является отдельным разделом и вы не хотите копировать эти файлы, вам все равно придется сделать --excludeэто вручную.
решение2
Проверьте, используете ли вы LVM. Если да, то вы можете делать снимки файловой системы с помощью LVM, а затем копировать оттуда.
Они были изобретены, потому что резервные копии должны создаваться из неподвижной файловой системы, иначе резервная копия не очень полезна. Снимки решат как проблему кросс-устройства, так и проблему временных файлов.
Обратите внимание, что если у вас есть какие-либо большие файлы, такие как базы данных, которые активны, rsync и другие резервные копии, скорее всего, создадут несогласованные версии, поскольку части файла будут скопированы до изменения базы данных, а другие — после. Снимки — это также попытка решить эту проблему.
Примечание: btrfs имеет улучшенную форму создания снимков файловой системы, но если вы уже используете ext4, то на этот раз уже слишком поздно это делать.
решение3
Дополнение: Если вы можете (можете, если вы находитесь в локальной консоли, не можете, если вы подключены через ssh или вам нужно, чтобы система работала полностью), измените уровень выполнения на 1 ("однопользовательский режим", команда - "init 1"), прежде чем делать что-то подобное. Это остановит все несущественные процессы, которые могут что-то изменить в файловой системе, пока вы ее копируете.
Не забудьте настроить fstab, особенно если используются UUID.
Рассмотрите возможность использования "chroot /where/the/new/root/is/mounted /bin/bash" для проверки вашей новой реплицированной файловой системы и, возможно, для переустановки вашего загрузчика. Возможно, вам придется вручную смонтировать /proc и /sys под chroot.
При переустановке загрузчика из chroot убедитесь, что /etc/mtab (в chrooted-системе) не содержит мусора, который сбивает с толку установщик загрузчика. Если это grub 1.x, вам, возможно, придется удалить (новый) файл /boot/device.map.
Если вы хотите перестраховаться с /dev, вы можете заполнить его (в новой файловой системе) «MAKEDEV generic» — это создаст набор файлов устройств «под» точкой монтирования udev, что предотвратит сбой вашей системы при запуске в случае, если udev неработоспособен.