Миграция на LVM

Question

Диск на моем Ubuntu media server почти заполнен. Я надеюсь добавить еще 2 ТБ емкости к машине и предпочел бы, чтобы все 3,5 ТБ распознавались как один диск. Чтобы усложнить ситуацию, я не хочу потерять какие-либо данные на диске или перенастраивать какие-либо программы.

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

Сработает ли этот план?

Мои самые большие вопросы: - Сможет ли dd скопировать мою установку на другой диск без проблем? Даже если это группа томов? - Сможет ли dd скопировать диск объемом 1,5 ТБ на диск объемом 2 ТБ и оставить оставшееся место свободным.

Answer 1

Если вы уже используете LVM:

• Убедитесь, что новый диск смонтирован и разбит на разделы для LVM (переключите бит LVM)
• Создайте PV на новом диске ( pvcreate /dev/your-new-disk)
• Расширьте свой VG, включив в него новый PV ( vgextend your-volume-group /dev/your-new-disk)
• pvmoveваши данные со старого диска на новый. Нет необходимости в dd. ( pvmove /dev/your-old-diskзаставит LVM переместить данные со старого диска на любой другой доступный диск.)

Если вы еще не используете LVM:

• Создайте PV и VG на новом диске.
• Скопируйте ваши данные на новый LV в новой VG.
  Я бы использовал dump+ restore, если это доступно для вашей файловой системы, но вы можете использовать cpioили tarили даже dd, если хотите.
• Отформатируйте старый диск, превратите его в PV, добавьте его в VG.

---

^{Нижеследующее является несколько субъективным и не имеет никакого отношения к LVM.}

• ^{dump+ restore:}
  • ^{Работайте с необработанным блочным устройством, чтобы источник atimeи т. д. не были затронуты, а пункт назначения ctimeи т. д. могли быть установлены правильно.}
  • ^{Сохраняет все жесткие ссылки и должен достаточно хорошо понимать внутреннюю структуру файловой системы, чтобы сохранять все расширенные атрибуты, политики безопасности и другие метаданные, специфичные для файловой системы.}
  • ^{Источник и место назначения могут иметь разные размеры; копирует только используемые данные.}
  • ^{Должен быть самый быстрый метод.}
• ^{cpio/ tar/ rsync/ cp:}
  • ^{Работа с смонтированной файловой системой, поэтому источник atimeизменен, назначение ctimeне может быть сохранено, номера инодов изменены и т. д.}
  • ^{Сохранение жестких ссылок требует сохранения всех известных inode в памяти и может быть выполнено правильно, а может и нет. Инструмент может понимать файловую систему достаточно хорошо или иметь привилегии для сохранения расширенных атрибутов, политик безопасности и других метаданных, специфичных для файловой системы.
    (Например, ext4 поддерживает временные метки с точностью до миллисекунды, но, насколько мне известно, ни один из этих инструментов их не сохраняет.)}
  • ^{Источник и место назначения могут иметь разные размеры; копирует только указанные данные.}
  • ^{Проводит много времени в системных вызовах ( stat, opendir, readdir, closedir, mkdir, open, read, write, close, …).}
• ^dd:
  • ^{Является точной копией необработанного блочного устройства.}
  • ^{Копирует все блоки, независимо от того, используются они или нет.}
  • ^{Дублирует все структуры файловой системы, включая то, что должно быть уникальным (например, UUID).
    Невозможно смонтировать оба (по умолчанию) одновременно в одной системе, если они XFS.}
  • ^{Невозможно изменить размер во время копирования.}
  • ^{Сравнительно медленно, если файловая система не очень заполнена.}