Комментарии 25
Причем делать rsync можно даже на живой системе, главное в exclude добавить /dev и прочие pseudo- и tmp- fs.
Пока есть успешный опыт многочисленных переносов EXT4 -> EXT4 и ReiserFS -> EXT4 разных дистров и разных объемов данных.
Аккуратность же сводится к просмотру /etc/mtab и обязательному указанию в exclude директории куда примонтирован новый накопитель (а то получится рекурсивное копирование — занятно потом по директориям пройтись :) ).
-X.Причем делать rsync можно даже на живой системе
Сделать-то можно, но точной консистентности данных не получится. Можно, конечно, остановить все сервисы и сделать remount root'а в read only, но легче ребутнуться и сделать финальный rsync из live окружения и гарантировать консистентность. Ведь все равно сервисы будут недоступны и в первом варианте.
After an XFS file system is created, its size cannot be reduced. However, it can still be enlarged using the xfs_growfs command
То, что вы предлагаете сделать, невозможно с xfs (и да, я об этом написал в статье). А на ext4 вы правы, можно было бы shrink'ануть раздел и выполнить pvmove, но это совсем другая история.
Да даже не с pvmove, с lvconvert -m 1, а потом lvconvert -m 0
pvmove? Создается raid через тот же dm-raid и дальше только мониторится процесс синка с заданным интервалом. Мало того, процесс pvmove можно спокойно «прибивать» сразу после запуска, на синк это никак не повлияет (сам процесс синка можно будет мониторить, например, так: dmsetup status|grep mirror). Pvmove только меняет lvm метаданные, создает raid и по окончанию меняет метаданные снова и разваливает raid.
vladimir-stupin.blogspot.ru/2013/10/debian-raid-1.html
На FreeBSD в файловой системе UFS2 давно пользуются dump/restore для точного переноса данных из одной ФС в новую безотносительно размеров — главное чтобы объём данных помещался в новую ФС. Снапшотинг ZFS — то же самое.
Для того, чтобы разрешить удалённый доступ, необходимо задать пароль для пользователя root и запустить SSH демон
Если говорить о redhat-производных дистрибитивах, то можно на этапе загрузки добавить опции в commandline ядра:
inst.sshd inst.vnc inst.vncpassword=pass. Ssh, правда, будет беспарольный, и если сеть недоверенная, то после первого захода лучше установить пароль. Этот способ удобней, если используется не livecd, а какой-нибудь minimal/netinstall и не будет подготовленных конфигов для запуска ssh с помощью systemd/init сервиса + есть vnc, если хочется графики.задача могла бы быть ещё проще — в логический том добавляется новый диск, после чего с использованием команды pvmove данные переносятся на другой физический носитель внутри логического тома
Тут небольшая путаница. Новый диск (его раздел) добавляется в физичесий том, физический том в логическую группу томов (расширяется существующая), и затем логический том переносится внутри логической группы на другий физический носитель (физичесий том).
Единственное, что осталось сделать, это переустановить загрузчик. Это необходимо делать с использованием chrootМожно и без
chroot, у grub2-install есть опция --boot-directory. В том числе актуально, если под рукой есть только x86 live, а препарируемая система — x86_64 и chrot'нуться не получится. Ну и как говорили выше, намного универсальней будет использовать rsync, например с опциями
--delete --numeric-ids -aHAXS (сохраняем все возможные атрибуты в неизменном виде), тогда мы не зависим от фс между которыми перенос. Если сервер выключен, то ничего exclud'ить не надо. А если нужно минимизировать время простоя, то обычно делают 3ой rsync (в live режиме с exclud'ами, еще раз, чтобы синхронизировать разницу, которая накопилась во время первого прогона и 3ий раз после выключения).Спасибо, действительно дельные дополнения. Особенно про опцию --boot-directory для grub2-install. Странно, что в интернете нигде таких рекомендаций не дают, а напротив, зачем-то предлагают использовать grub-install, потому что, якобы, с Grub2 у них возникала масса проблем.
По поводу rsync повторюсь — с ним подход будет, бесспорно, универсальнее, но на мой взгляд ничуть не проще. Плюс в данной статье я намеренно хотел показать использование именно характерных для xfs утилит для достижения поставленной цели.
systemctl enable fstrim.timer, для trim'а раз в неделю в рассматриваемом дистрибутиве).Я не стал об этом писать, т.к. это мой первый опыт использования SSD и как я понял, trim поддерживается совсем не всеми SSD-дисками. Те же способы проверки поддерживается ли эта команда диском или нет, на моём диске не отрабатывали (ADATA SX8000). А рекомендовать то, в чём я не уверен, не в моих правилах.
Руководствуясь вашим советом и статьёй с DigitalOcean, я так понял, что скрипт fstrim сам разберётся поддерживается ли trim для дисков. Поэтому я дополнил статью этой рекомендацией. Ещё раз спасибо за дельное замечание.
Перенос работающей Linux системы на XFS с HDD на SSD меньшего размера