Миграция в LVM

Question

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

Я планировал использовать LVM для создания группы томов на новом диске и использовать 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 не может быть сохранена, изменение числа индексных дескрипторов файлов и т.д.}
  • ^{Сохранение жестких ссылок требует хранения всех известных инодов в памяти, и может быть или не быть сделано правильно. Инструмент может понимать или не понимать файловую систему достаточно хорошо или иметь привилегии для сохранения расширенных атрибутов, политик безопасности и других специфических для файловой системы метаданных.
    (Например, ext4 поддерживает временные метки с точностью до миллисекунды, но, насколько мне известно, ни один из этих инструментов не сохраняет их.)}
  • ^{Источник и пункт назначения могут быть разных размеров; копирует только указанные данные.}
  • ^{Проводит много времени в системных вызовах (stat , opendir , readdir , closedir , mkdir , open , read , write , close ,…).}
• ^dd:
  • ^{Является точной копией необработанного блочного устройства.}
  • ^{Копирует все блоки, независимо от того, используются они или нет.}
  • ^{Дублирует все структуры файловой системы, включая вещи, которые должны быть уникальными (например, UUID).
    Невозможно смонтировать оба (по умолчанию) одновременно в одной системе, если они XFS.}
  • ^{Невозможно изменить размер во время копирования.}
  • ^{Сравнительно медленный, если файловая система была не очень полной.}