Pull to refresh

Comments 25

Столько телодвижений… В ведь хватило бы простого rsync (+ grub-install), не?
Причем делать rsync можно даже на живой системе, главное в exclude добавить /dev и прочие pseudo- и tmp- fs.
Я не адепт `rsync`, но возможно вы правы. Однако, телодвижений, возможно, пришлось сделать бы даже больше (учитывая то, насколько аккуратно нужно было бы указывать какие директории переносить, а какие нет). А ещё `rsync` ничего не знает о расширенных атрибутах файловой системы `xfs`, которые будут безвозвратно утеряны при переносе.
Атрибуты — возможно, я в свою очередь не адепт «XFS» :)
Пока есть успешный опыт многочисленных переносов EXT4 -> EXT4 и ReiserFS -> EXT4 разных дистров и разных объемов данных.
Аккуратность же сводится к просмотру /etc/mtab и обязательному указанию в exclude директории куда примонтирован новый накопитель (а то получится рекурсивное копирование — занятно потом по директориям пройтись :) ).
rsync знает о расширенных атрибутах и имеет соответтсвующую опцию -X.
Причем делать rsync можно даже на живой системе

Сделать-то можно, но точной консистентности данных не получится. Можно, конечно, остановить все сервисы и сделать remount root'а в read only, но легче ребутнуться и сделать финальный rsync из live окружения и гарантировать консистентность. Ведь все равно сервисы будут недоступны и в первом варианте.
Да, именно. Для десктопов, ИМХО, хватает просто все закрыть. Для серверов — остановить сервисы. Простой будет, но гораздо меньше чем полная остановка. Из практики: 2 Тб писем в Exim4+Cyrus при переносе HW>VIRT (в довесок — ReiserFS > EXT4) — даунтайм 15-25 минут; 300 ГБ MySQL-баз — минут 10 даунтайм.
Если уж это LVM, не легче ли было сделать зеркало всех разделов на новом диске, отключить старый, и вуаля — переключение дисков на лету? Не знаю, правда, про xfs, но ext4 умеет менять размеры смонтированных разделов, так что и с SSD меньшего размера не должно было быть проблем — недавно провел подобное на ноутбуке.
Вот, что сообщает документация Red Hat, например
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? Создается raid через тот же dm-raid и дальше только мониторится процесс синка с заданным интервалом. Мало того, процесс pvmove можно спокойно «прибивать» сразу после запуска, на синк это никак не повлияет (сам процесс синка можно будет мониторить, например, так: dmsetup status|grep mirror). Pvmove только меняет lvm метаданные, создает raid и по окончанию меняет метаданные снова и разваливает raid.
Ext4 не умеет в уменьшение раздела на лету.
Хм, попробовал, действительно так. Видимо переносил таки меньшие разделы.
Кстати, Windows 2008 тоже можно перенести на лету через создание зеркала.
Помню, в давние времена XFS любил при сбое затирать нулями все открытые файлы…

Думаю тот факт, что Red Hat сделали xfs файловой системой по умолчанию в 7-й версии своего основного коммерческого продукта говорит о том, что она (xfs) шагнула далеко вперёд в плане надёжности

Или добавили рекомендацию не допускать сбоев в документацию

На 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 утилит для достижения поставленной цели.

Еще забыл упомянуть: в статье не помечено, но т.к. переезд осуществляется на ssd, то уже на перенесенной системе нужно не забыть включить функционал trim'а (например так: systemctl enable fstrim.timer, для trim'а раз в неделю в рассматриваемом дистрибутиве).

Я не стал об этом писать, т.к. это мой первый опыт использования SSD и как я понял, trim поддерживается совсем не всеми SSD-дисками. Те же способы проверки поддерживается ли эта команда диском или нет, на моём диске не отрабатывали (ADATA SX8000). А рекомендовать то, в чём я не уверен, не в моих правилах.

Руководствуясь вашим советом и статьёй с DigitalOcean, я так понял, что скрипт fstrim сам разберётся поддерживается ли trim для дисков. Поэтому я дополнил статью этой рекомендацией. Ещё раз спасибо за дельное замечание.

Sign up to leave a comment.

Articles