Clonezilla проверить изображение не удается

Question

У меня есть ноутбук HP Pavillion dv4, который в процессе съедает свой (второй) жесткий диск из-за проблем с теплом (с тех пор он получил его в виде теплового кулера). Я приобрел внешний USB-накопитель емкостью 1,5 ТБ для резервного копирования, чтобы использовать clonezilla для записи файлов изображений на резервный диск, а затем дублирование (основной ОС - Ubuntu) для создания инкрементных резервных копий.

Проблема в том, что когда я загружаю clonezilla live с компакт-диска, он запускается через все, создавая резервную копию различных разделов (включая большой раздел Windows 385 ГБ), но когда он возвращается и пытается проверить образ, он получает CRC ошибка чтения каждый раз на sda1 (раздел Windows). Другие разделы (Windows Rescue, / и Swap) все в порядке.

Итак ... мой вопрос заключается в следующем: каковы мои варианты на данный момент? Я действительно не хочу терять то, что на моем разделе Windows, если я вообще могу избежать этого. Да, у меня есть компакт-диски HP для восстановления системы, но это, вероятно, потребует удаления моей установки Linux и ее восстановления с нуля - что делает недействительным все время, пока я до сих пор проводил запуск clonezilla на этой машине.

Идеи, комментарии, предложения?

Answer 1

Этот вопрос и ответ довольно старый, поэтому я не буду просить больше информации.

Вы заявляете:

У меня есть ноутбук HP Pavillion dv4, который ест второй (второй) жесткий диск

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

Вы также упоминаете, что:

когда он возвращается и пытается проверить образ, он каждый раз получает ошибку чтения CRC на sda1

Когда программа образа диска запускается, она создает точную копию данных, считанных с диска. Процесс проверки, где он снова считывает данные с диска (?) кажется, что он терпит неудачу последовательно. Есть несколько возможных причин, но одна из них заключается в том, что чтение этого раздела исходного (оригинального, неисправного) диска каждый раз дает разные данные. Это объяснение согласуется с первым утверждением, что вы ему не доверяете.

В этом случае я рекомендую следующее:

Если у вас есть свободное место на диске (всегда вопрос), у вас есть несколько вариантов:

• Быстро и грязно: возьмите самый последний образ (с ошибкой CRC) и запустите на нем инструмент восстановления диска. Это, вероятно, даст вам значительную долю исходных данных, и есть неплохой шанс, что это включает все данные, которые вам небезразличны. Проблема в том, что вы автоматически вносите изменения в свою единственную копию данных на надежных носителях.
• Благоразумно: сделайте копию самого последнего образа (который не прошел проверку CRC) и запустите инструмент восстановления диска на копии. Это дает вам все преимущества вышеперечисленного, но вы можете вернуться к осторожному и медленному (ниже), если вы не полностью удовлетворены.
• Осторожно и медленно: используйте инструмент, такой как ddrescue, чтобы внимательно прочитать сбойный диск и попытаться восстановить как можно больше данных в новом месте на диске, возможно, используя существующий образ, чтобы помочь информировать ddrescue.

Answer 2

Я не знаю точно, почему, но иногда жесткий диск или твердотельный накопитель находятся в таком состоянии, что Clonezilla не может правильно клонировать носитель или проверить набор резервных копий (мне это случалось несколько раз с жестким диском и твердотельным накопителем в течение примерно года). Это может быть на Linux EXT FS или Windows NTFS и т.д ... Это выдает что-то вроде этого:

syslinux.d syslinux_fs /dev/....
crc errors block_id = nnn...
...

Для проверки файловых систем ext2, ext3 или ext4

Попробуйте открыть Gparted (GUI), кликните на иконку колеса и выберите ремонт. Если это не помогло, есть второй способ из командной строки - попытаться восстановить поврежденные блоки вручную, используя e2fsck. Например:

ubuntu_linux:> e2fsck -f -p -v -c -c C 0 'dev/nvme0n1p2'

Ключи: -f force, -p проверяют и автоматически исправляют все проблемы, не запрашивая подтверждения, -v подробный, -c -c inode для предотвращения их выделения файлу или каталогу - если эта опция указана дважды, тогда сканирование плохих блоков будет выполнено с использованием неразрушающего теста чтения-записи. Наконец, C 0 означает, что вы можете видеть прогресс. Будьте терпеливы, это займет некоторое время (полный NVME 500GB SSD около 2 часов +). В основном это помогло мне.

Оба метода вы можете использовать несколько раз, но будьте осторожны. Иногда GParted может повредить вашу файловую систему и сделать ее необратимой, а также e2fsck , но, с другой стороны, в этой ситуации, возможно, проблема была только скрыта, поэтому нет выбора, как легко восстановить носитель.

Для проверки файловых систем NTFS, FATXX и т.д ...

Подобную ситуацию я заметил и на Windows10 (снова SSD и снова во время резервного копирования или сразу после). Есть ситуация чуть проще. Windows сразу предлагает что делать - есть уведомление, которое приводит нас на страницу с советами, как исправить ошибку на носителе. Конечно, снова есть возможность использовать командную строку chkdsk как объяснено в комментарии выше.

После лечения плохого блока может случиться, что что-то не будет работать должным образом. Если это не принципиально для ОС, его можно скрыть на время, когда вам нужно будет запустить приложение, открыть картинку и т. Д ... Если это программа или часть какой-либо установки, просто переустановите ее. Если у sytem есть какие-либо проблемы, попробуйте переустановить библиотеку или просто то, где проблема.