Xác minh hình ảnh Clonezilla không thành công

Tôi có một máy tính xách tay HP Pavillion dv4 đang trong quá trình ăn ổ cứng (thứ hai) do vấn đề về nhiệt (từ đó đã nhận được một miếng đệm làm mát nhiệt). Tôi đã mua một ổ đĩa USB ngoài 1,5TB để sao lưu, với ý định sử dụng clonezilla để ghi các tệp hình ảnh vào ổ đĩa sao lưu, sau đó sao chép (hệ điều hành chính là Ubuntu) để thực hiện sao lưu gia tăng.

Vấn đề là khi tôi khởi động clonezilla trực tiếp từ đĩa CD, nó chạy mọi thứ, tạo hình ảnh sao lưu của các phân vùng khác nhau (bao gồm cả phân vùng Windows 385GB lớn) nhưng khi quay lại và cố gắng xác minh hình ảnh, nó sẽ bị CRC đọc lỗi mỗi lần trên sda1 (phân vùng Windows). Các phân vùng khác (cứu Windows và / và trao đổi) đều xác minh tốt.

Vì vậy, ... câu hỏi của tôi là: lựa chọn của tôi tại thời điểm này là gì? Tôi thực sự không muốn mất những gì trên phân vùng Windows của mình nếu tôi hoàn toàn có thể tránh nó. Có, tôi có sẵn đĩa CD cứu hộ hệ thống HP, nhưng điều đó có thể sẽ liên quan đến việc xóa cài đặt Linux của tôi và khôi phục lại từ đầu - loại nào vô hiệu hóa tất cả thời gian tôi đã chạy clonezilla trên máy này cho đến nay.

Ý tưởng, ý kiến, đề xuất?

Tôi không biết chính xác lý do tại sao, nhưng đôi khi, ổ cứng hoặc SSD ở trạng thái đó, Clonezilla không thể sao chép chính xác phương tiện hoặc xác minh bộ sao lưu (tôi rất vui khi nhận được ổ cứng cũng như SSD vài lần trong khoảng 10 lần năm). Nó có thể có trên Linux EXT FS hoặc Windows NTFS, v.v ... Nó phát hành một cái gì đó như thế này:

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

Để kiểm tra hệ thống tập tin ext2, ext3 hoặc ext4

Hãy thử mở Gparted (GUI), nhấp vào biểu tượng bánh xe và chọn sửa chữa. Nếu không được giúp đỡ, có cách thứ hai từ dòng lệnh là thử sửa chữa các khối bị hỏng bằng tay bằng cách sử dụng e2fsck. Ví dụ:

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

Các công tắc: -f buộc, -p kiểm tra và tự động sửa chữa tất cả các vấn đề mà không nhắc bạn xác nhận, -v verbose, -c -c inode để ngăn chúng được phân bổ vào một tệp hoặc thư mục - nếu tùy chọn này được chỉ định hai lần, thì quét khối xấu sẽ được thực hiện bằng cách sử dụng kiểm tra đọc ghi không phá hủy. Cuối cùng, C 0 có nghĩa là bạn có thể thấy sự tiến bộ. Hãy kiên nhẫn mất một thời gian (SSD NVME 500GB đầy đủ khoảng 2 giờ +). Chủ yếu, nó đã giúp tôi.

Cả hai phương pháp bạn có thể sử dụng nhiều lần, nhưng hãy sẵn sàng. GParted đôi khi có thể làm hỏng hệ thống tập tin của bạn nhiều hơn và không thể khắc phục được e2fsck, nhưng mặt khác, trong tình huống đó, có thể vấn đề chỉ bị ẩn, vì vậy không có lựa chọn nào để dễ dàng sửa chữa phương tiện.

Để kiểm tra hệ thống tập tin NTFS, FATXX, v.v ...

Tình huống tương tự tôi cũng nhận thấy trên Windows10 (một lần nữa là SSD và một lần nữa trong thời gian sao lưu hoặc ngay sau đó). Có tình hình hơi dễ hơn. Windows ngay lập tức cung cấp những việc cần làm - có thông báo, dẫn chúng tôi đến trang với lời khuyên, cách sửa lỗi trên phương tiện. Tất nhiên, một lần nữa khả năng sử dụng dòng lệnh chkdsknhư được giải thích trong phần bình luận ở trên.

Sau khi chữa lành khối xấu nó có thể xảy ra, một cái gì đó sẽ không hoạt động đúng. Nếu nó không phải là nền tảng cho hệ điều hành, nó có thể bị ẩn theo thời gian, khi bạn cần khởi động ứng dụng, hãy mở hình ảnh, v.v ... Nếu đó là chương trình hoặc một phần của một số cài đặt, chỉ cần cài đặt lại. Nếu sytem có bất kỳ vấn đề nào, hãy thử cài đặt lại thư viện hoặc đơn giản là đó là vấn đề.

Câu hỏi và câu trả lời này khá cũ, vì vậy tôi sẽ không hỏi thêm thông tin.

Bạn nói:

Tôi có một máy tính xách tay HP Pavillion dv4 đang trong quá trình ăn ổ cứng (thứ hai) của nó

Điều này khiến tôi nghi ngờ ổ cứng trong câu hỏi bị hư hỏng về mặt vật lý. Do đó, bất kỳ dữ liệu nào bạn thu thập từ nó cũng sẽ bị nghi ngờ.

Bạn cũng đề cập rằng:

khi quay lại và cố gắng xác minh hình ảnh, nó sẽ gặp lỗi đọc CRC mỗi lần trên sda1

Khi một chương trình hình ảnh đĩa chạy, nó tạo ra một bản sao chính xác của dữ liệu đọc từ đĩa. Quá trình xác minh, nơi nó đọc lại dữ liệu từ đĩa (?) Dường như nó thất bại một cách nhất quán. Có một vài lý do có thể, nhưng một lý do là việc đọc phần đó của đĩa nguồn (ban đầu, không thành công) mỗi lần tạo ra dữ liệu khác nhau. Lời giải thích đó phù hợp với tuyên bố đầu tiên mà bạn không tin tưởng.

Trong trường hợp đó, tôi khuyên bạn nên như sau:

Giả sử bạn có dung lượng đĩa dự phòng (luôn là câu hỏi), bạn có một số tùy chọn:

• Nhanh và bẩn: Chụp ảnh gần đây nhất (CRC thất bại) và chạy một công cụ sửa chữa đĩa trên đó. Điều này có thể sẽ giúp bạn có được một phần tốt của dữ liệu gốc và rất có thể điều này bao gồm tất cả dữ liệu bạn quan tâm. Thách thức là bạn đang thực hiện các thay đổi tự động đối với bản sao dữ liệu duy nhất của bạn trên phương tiện đáng tin cậy.
• Thận trọng: Tạo một bản sao của hình ảnh gần đây nhất (thất bại CRC) và chạy một công cụ sửa chữa đĩa trên bản sao. Điều này mang lại cho bạn tất cả những lợi ích của những điều trên, nhưng sau đó bạn có thể quay lại thận trọng và chậm chạp (bên dưới) nếu bạn không hoàn toàn hài lòng.
• Thận trọng và chậm chạp: Sử dụng một công cụ như ddresTHER để đọc kỹ đĩa bị hỏng và cố gắng khôi phục càng nhiều dữ liệu càng tốt đến một vị trí mới trên đĩa, có thể sử dụng hình ảnh hiện có để giúp thông báo cho ddresTHER.