Миграция в LVM


3

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

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

Будет ли этот план работать?

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

Ответы:


4

Если вы уже используете 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.
    • Невозможно изменить размер во время копирования.
    • Сравнительно медленно, если файловая система была не очень полной.

Каковы преимущества использования dump + restore перед dd? Я получу неиспользуемое пространство, если использовать dump + restore на больший диск?
Эван Гиллеспи

дд не совсем подходящий инструмент для этой работы. Я бы просто использовал cp или tar.
Хлипкий
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.