LVM и клонирование HD

Question

Используя Linux, у меня есть несколько уровней резервного копирования. Одним из них является периодическое копирование сектора (с использованием dd) жесткого диска моего ноутбука на внешний USB-диск. Да, у меня есть и другие резервные копии, например, удаленный rsync.

Этот подход (диск dd) подходит для клонирования жесткого диска без томов LVM, поскольку я могу подключить внешний диск в любое время и смонтировать разделы, просто подключив /dev/sdb* вместо /dev/sda* . Тривиально и удобно.

Сегодня я переместил ВСЕ свой жесткий диск (включая /boot) в LVM. Все отлично работает Я выделю это на пару дней, а затем сделаю копию за сектором на свой внешний жесткий диск.

Теперь у меня есть проблема, я думаю.

Если в будущем я подключу внешний жесткий диск USB для восстановления какого-либо файла, ОС обнаружит дубликат конфигурации LVM с тем же именем и тем же UUID. Даже выполняя vgrename (какой LVM будет переименован, внутренний HDD или внешний HDD?), Клонированный UUID не изменится. Есть ли команда для изменения имени и UUID? В идеале я бы клонировал жесткий диск, а затем изменил имя группы LVM и ее UUID, но я не знаю, как это сделать.

Еще одна связанная с этим проблема будет ...

В прошлом я загружал свой ноутбук, используя внешний диск, используя меню загрузки BIOS и меняя записи GRUB вручную для загрузки из /dev/sdb вместо /dev/sda . Но теперь моя текущая конфигурация GRUB загружается непосредственно с логического тома LVM, что-то вроде: set root='(LVM-root)' в моем grub.cfg . Так... Что будет с дублированными томами?

Любое предложение?

Я думаю, что я мог бы перераспределить свой внешний жесткий диск и изменить стратегию резервного копирования с dd на rsync , но на этом диске также установлены окна, и я действительно хотел бы иметь физическую "настоящую" копию.

Answer 1

Закрытие этой проблемы через год. Я написал ответ на моем личном сайте. Я надеюсь, что это полезно для кого-то еще.

Я использую несколько уровней резервного копирования, от rsync на внешний диск до rsync+ZFS через удаленный компьютер. Одна из резервных копий, которую я делаю, - время от времени - "dd" с жесткого диска моего ноутбука на внешний USB-порт (подключенный только на время процедуры резервного копирования). Я делаю это, например, перед тем, как взять свой ноутбук в поездку.

Эта процедура хорошо работала целую вечность. Пока я не начал использовать LVM на своем ноутбуке.

Если вы используете LVM на своем компьютере, вы копируете свой жесткий диск с помощью dd (загрузка с LiveCD) и подключаете внешний жесткий диск, когда компьютер работает нормально, позже вы ПОЛУЧИТЕ СВОИ ДАННЫЕ, ДАЖЕ ПОТЕРЯЕТЕ ВСЕ ФИЛЬСИСТЕМУ, ЧЕМ ВНЕ РЕМОНТ! !!.

Зачем?. Потому что, когда вы подключите внешний жесткий диск, ОС увидит одинаковую конфигурацию LVM на обоих дисках и наивно предположит, что оба диска одинаковы и доступны по многолучевому каналу связи, поэтому она будет распределять чтение и запись между обоими дисками, что приведет к непоправимому повреждению ОБА. Вы уничтожите и свои живые данные и свою резервную копию !.

Это случилось со мной однажды. Я потерял данные. Несколько дней назад у меня были другие резервные копии, поэтому я не потерял ничего очень важного, но это было довольно раздражающим и выявило недостаток в моей стратегии резервного копирования.

Решение. Убедитесь, что конфигурация LVM на диске резервного копирования отличается. Проблема в... Как это сделать?

Я разместил вопрос на superuser.com (Stack Exchange), но не получил хорошего ответа. Поэтому я разработал свою собственную процедуру и, после более чем года боевых испытаний, я публикую ее здесь и закрываю первоначальный вопрос:

• Убедитесь, что если что-то пойдет не так, ваш компьютер не загрузится автоматически. В моем случае мой ноутбук не загружается автоматически, если питание отключается и снова включается. Кроме того, жесткий диск зашифрован, поэтому он будет запрашивать пароль.

  Это необходимо, потому что вы можете повредить ОБА диски, если перезагрузите компьютер с резервным диском, прикрепленным до завершения процедуры.

• Загрузитесь с Live CD. Вы не можете сделать "dd" из живого раздела, если ожидаете, что сможете восстановить ваши данные :-).

  Что-то, что можно попробовать в будущем, - это использовать моментальные снимки LVM, чтобы иметь возможность делать резервные копии, пока я использую компьютер, но затем у меня возникает проблема с дублированием LVM, которую я пытаюсь здесь избежать. Другой вариант - перенастроить LVM для зеркального отображения данных в реальном времени на внешний жесткий диск и отключить зеркало после завершения синхронизации. Но это звучит рискованно и не создаст резервную копию моего раздела Windows или данных, которые я не храню в томах LVM.

• После загрузки LiveCD подключите внешний жесткий диск USB.

• Войдите в систему как "root" и выполните vgchange -a n . Эта команда отключит LVM на обоих дисках. Я выполняю команду пару раз, чтобы быть уверенным.

• Убедитесь, что /dev/sda является источником (внутренний жесткий диск), а /dev/sdb - местом назначения (внешний жесткий диск USB). Например, выполните dd if=/dev/sdb of=/dev/null и проверьте, какой светодиод жесткого диска мигает.

• Когда вы уверены, какой диск какой, вы делаете копию с помощью dd if=/dev/sda of=/dev/sdb bs=65536 . С моей конфигурацией резервное копирование занимает четыре часа. Мой внутренний жесткий диск составляет 500 ГБ, а мой USB копирует со скоростью 35 МБ / с. Я делаю это ночью, пока сплю.

  Ваш внешний жесткий диск USB, по крайней мере, должен быть таким же большим, как и ваш внутренний жесткий диск. Это очевидно, не так ли?

• После того, как эта копия сделана, у вас есть точный клон вашего внутреннего жесткого диска. Резервное копирование сделано. Но теперь у вас будет проблема, если вы когда-нибудь подключите этот жесткий диск к своему компьютеру, когда вы работаете со своим внутренним жестким диском, как уже описано. Нам нужно изменить конфигурацию LVM.

• Теперь, после того как "dd" завершен, выполните "sync" и отключите внешний жесткий диск UDB.

• Вы выполняете pvchange --uuid /dev/sda* . Эта команда изменит UUID всех физических томов на вашем внутреннем жестком диске. Эта команда безопасна, даже если у вас есть разделы, которые не являются физическими томами для LVM, потому что они будут автоматически и безопасно пропущены.

  Система знает, какие разделы являются физическими томами, потому что тип раздела и потому что вы выполнили "pvcreate" при создании LVM.

• Вы выполняете vgchange -u LVM . Эта команда изменит UUID группы томов LVM. Кстати, моя группа томов называется "LVM".

• Вы выполняете vgscan . Эта команда просканирует внутренний жесткий диск (единственный подключенный в данный момент) и найдет там группу томов LVM.

• Вы выполняете vgrename LVM LVM2 , чтобы изменить имя вашей группы томов.

• Теперь вы подключаете свой внешний жесткий диск USB.

• Вы снова "vgscan", на этот раз, чтобы найти группу томов на внешнем жестком диске USB. Теперь у вас будет две группы томов. Один называется "LVM2" на вашем внутреннем жестком диске, а другой - "LVM" на внешнем жестком диске USB.

• Переименуйте группу томов на внешнем жестком диске USB с помощью vgrename LVM LVM_BACKUP .

• И переименуйте группу томов на внутреннем жестком диске обратно в исходное имя: vgrename LVM2 LVM .

• Вы сделали. Вы можете просмотреть ситуацию с помощью vgdisplay -v .

  Вы увидите, что UUID логических томов одинаковы в обеих группах томов, но, похоже, это не вызывает никаких проблем, и я не знаю, как их изменить.

• Отключите внешний жесткий диск USB, сохраните его в безопасном месте, перезагрузите компьютер, извлеките LiveCD и вернитесь к делу.

Answer 2

Я согласен с одним из предыдущих ответов - запуск dd на весь диск не является хорошим решением. Если причина, по которой вы застряли на dd, связана с резервным копированием другой ОС, то вы можете использовать dd только для этих других разделов ОС и rsync для разделов linux.

Частично проблема заключается в том, что если вы запускаете dd всего диска, когда у вас есть файловые системы, подключенные и смонтированные с него, нет способа обеспечить согласованность резервной копии. Он может работать 9 раз из 10, но при любой нагрузке результирующая резервная копия может быть повреждена. Единственный способ убедиться, что этого не произойдет, - это размонтировать все файловые системы и деактивировать все группы томов на все время работы dd. Не очень удобно, если ваш / смонтирован из LVM.

В любом случае, если вы настаиваете на том, чтобы придерживаться этого подхода, инструмент, который вы ищете для переименования дублированного vg, называется "vgimportclone". Он предназначен для использования со снимками уровня устройства, но он также будет работать и с dd.

Answer 3

Внимательно изучая проблему, я думаю, что правильный подход будет следующим:

1. Подключите внешний HD.

2. Деактивируйте управление LVM второго HD: «vgchange -an /dev /LVM2».

3. Клонируйте жесткий диск с помощью "dd".

4. Для каждого физического тома создайте новые UUID для клонированного диска с помощью «pvchange -u /dev /hdb *».

5. Измените VG UUID с помощью "vgchange -u LVM". Это изменит UUID одного из VG, может быть оригиналом или клоном. Это не важно Быть другим достаточно.

6. Измените имя VG клонированного диска с "LVM" на "LVM2" с помощью "vgrename". Я не знаю, будет ли это работать без предыдущего "vgscan", чтобы "обнаружить" новый VG.

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

Answer 4

Я не думаю, что в большинстве случаев dd является лучшим вариантом для резервного копирования по ряду причин. Один вариант, как кто-то упомянул, - использовать зеркалирование LVM. Вы можете отключить внешний диск, и при повторном подключении он будет синхронизироваться без необходимости копировать 100% всего, включая пустые сектора, как это сделал бы dd. Но лично я думаю, что еще лучше / проще просто использовать rsync для копирования на внешний диск. Faaaaaar не только будет самым быстрым, ваша резервная копия также будет немедленно использована без каких-либо дополнительных действий. Добавьте к этому моментальные снимки LVM на внешнем диске, и вы получите несколько копий на определенный момент времени, которые можно использовать в любое время без каких-либо дополнительных хитростей.