3

Так что недавно мой старый SSD (содержащий /root + /home разделы для моей системы) сломался (подробности в этом вопросе), и я пошел, чтобы получить новый. Теперь я хотел клонировать его, но столкнулся со следующими проблемами:

$ pv /dev/sdd > /dev/sda
4.24GiB 0:00:18 [ 234MiB/s] [==>                          ]  7% ETA 0:03:55
pv: /dev/sdd: read failed: Input/output error

$ dd if=/dev/sdd of=/dev/sda bs=1M status=progress
dd: error reading '/dev/sdd': Input/output error
4397+1 records in
4397+1 records out
4611493888 bytes (4.6 GB, 4.3 GiB) copied, 22.0249 s, 209 MB/s

Старый SSD все еще работает. Есть много зависаний системы из-за его повреждения, но я могу разблокировать, смонтировать и использовать его довольно хорошо. Я могу получить доступ ко всем данным (AFAIK), и полное резервное копирование с использованием tar тоже работает хорошо.

Причины, по которым я бы предпочел прямое клонирование, а не копирование файлов за файлами (или tar):

  1. удобство
  2. скорость
  3. Довольно сложное шифрование на диске, которое я бы предпочел не переустанавливать снова

Этот сайт предлагает использовать conv=noerror с dd , но я не уверен, безопасно это или нет. У меня те же проблемы с dd_rescue и clonezilla -rescue .

Вопрос: Как можно безопасно клонировать мой старый SSD на новый, и достаточно ли проверки md5sum после этого, чтобы убедиться, что клон был на 100% успешным?

Сайт, на который я ссылался выше, предлагает использовать gparted для проверки успешности клонирования, но AFAIK gparted не работает с зашифрованными разделами LUKS. (Для усложнения: заголовок LUKS отсоединен.)

Дополнительный вопрос: расшифровка моего диска выполняется при загрузке с использованием grub и идентификатора раздела (не UUID). Достаточно ли мне обновить идентификатор в моей конфигурации crypttab и grub или мне нужно сделать больше?


Редактировать: я только что понял, что md5sum , скорее всего, не сможет прочитать диск, а также. Есть ли другой способ безопасно определить, был ли клон успешным?


ОБНОВЛЕНИЕ: Итак, я попробовал clonezilla с опцией -rescue . Казалось, что это работает, и я могу разблокировать контейнер LUKS, чтобы открыть LVM, но когда я пытаюсь смонтировать корневой раздел, я получаю следующее:

$ sudo mount /dev/mapper/vvg-root /mnt/sda
mount: wrong fs type, bad option, bad superblock on /dev/mapper/vvg-root,
       missing codepage or helper program, or other error

Соответствующие данные из dmesg:

[ 4686.401702] JBD2: no valid journal superblock found
[ 4686.401707] EXT4-fs (dm-3): error loading journal

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


ОБНОВЛЕНИЕ 2: я запустил fsck.ext4 -yv в разделе нового диска. Я был залит ошибками. В миллионах. Теперь я могу его смонтировать, но почти все мои файлы отсутствуют. Каталог /home, среди многих других, полностью отсутствует. На нем должно быть около 30-35 ГБ данных. Теперь это 53 МБ.

Действительно ли мой единственный вариант откатить резервную копию tar я имею? Я думаю, что лучше сделать копию rsync «один на один», так как она будет сообщать о повреждении / нечитаемости определенного файла, верно? Я использовал --verify когда создавал архив tar но он не сообщал об ошибках.

2 ответа2

0

Во-первых, я бы порекомендовал не использовать SSD и не запускать на нем тесты, потому что это может привести к его дальнейшему выходу из строя, у меня когда-то был диск, который я ремонтировал, и после выполнения некоторых проверок целостности он не давал самому себе быть прочитанным вообще. Если вы по-прежнему можете видеть его из отдельной системы, он все равно должен быть сохранен, хотя использование может привести к прекращению чтения чипов, поэтому я попробую выполнить полное клонирование, прежде чем делать что-либо еще. Я рекомендую использовать Clonezilla от USB, чтобы защитить SSD от ненужных операций чтения / записи во время клонирования. когда вы клонировали его, md5sum будет лучшим способом подтвердить, что все это есть, хотя это может быть ненадежно в случае сбоя. Преимущество использования клонирующей ОС или аппаратного клонера заключается в том, что все данные копируются по секторам.

0

Сделав то, что я сказал в своем вопросе, я закончил тем, что сделал следующее:
1) Удалите LVM на новом SSD после неудачной копии CloneZilla.
2) Я не трогал внешний dm-склеп, так как он работал хорошо.
3) Я заново создал новый LVM и изменил размер всего, чтобы соответствовать новому (большему) SSD.

(Это относится только к моему случаю, поэтому шрифт поменьше, см. Вопрос обновления)

Теперь для клонирования:

1) После разблокировки я смонтировал оба корневых раздела SSD в работающей системе:

# unlock the LUKS containers with cryptsetup first
mount /dev/mapper/ovvg-root /mnt/oldssd
mount /dev/mapper/vvg-root /mnt/newssd

2) Я использовал rsync для клонирования файлов:

rsync -ahv --progress /mnt/oldssd /mnt/newssd

3) Подтвердили, что размеры всех папок совпадают:

du -cs /mnt/oldsdd/* && echo " " && du -cs /mnt/newssd/*

4) Подтвердили, что все файлы есть, чтобы перепроверить:

find /mnt/oldssd | cut -d "/" - f 4- | sort > oldssd.txt
find /mnt/newssd | cut -d "/" - f 4- | sort > newssd.txt
diff oldssd.txt newssd.txt

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

5) Удовлетворил мою паранойю, проверив контрольные суммы:

cd /mnt/oldssd && find . -type f -exec md5sum {} \; | sort > /root/oldssd_md5.txt
cd /mnt/newssd && find . -type f -exec md5sum {} \; | sort > /root/newssd_md5.txt
cd /root && diff oldssd_md5.txt newssd_md5.txt

Нет вывода вообще - это означает, что каждый файл одинаков!

Что касается бонусного вопроса:

1) Измените путь к устройству (используя UUID) в /etc/fstab
2) Измените путь к устройству (используя by-id) в /etc/default/grub
3) Поскольку сейчас я не могу войти в систему с помощью chroot, я изменил grub.cfg напрямую, чтобы отразить изменение by-id диска. Однако лучше не делать этого, а вместо этого делать chroot в корневой системе и повторно настроить загрузчик GRUB. Я сразу сделал это после загрузки в систему с нового SSD.

Сложнее, чем хотелось бы, но, по крайней мере, это сработало безопасно.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .