Làm cách nào để ước tính các vòng lặp / thời gian để hoàn thành GNU ddresTHER (1.18.1) bằng trạng thái hiện tại?


9

Bối cảnh / Bối cảnh:

Tôi hiện đang chạy GNU ddresTHER 1.18.1 để khôi phục dữ liệu từ USB bị ngắt kết nối cáp trong khi tôi đang ghi hình ảnh đĩa ảo lên phân vùng đĩa2s1. Ban đầu tôi đang phục hồi phân vùng thứ hai của mình (đĩa2s2) và nhận thấy rằng tôi đã đạt đến giai đoạn thứ ba (Chia tách). Tôi đang đặt hình ảnh vào một bộ lưu trữ mạng.

Câu hỏi:

Tôi đã nhận thấy rằng vòng lặp giai đoạn này. Có cách nào để tính số vòng lặp mà tôi có khả năng gặp phải, với thông tin trạng thái hiện tại của tôi (tôi chỉ hiển thị hai lỗi)?

Trạng thái:

trạng thái

Cập nhật / Chỉnh sửa:

Vì vậy, tôi vẫn rất quan tâm đến việc người ta có thể ước tính các vòng lặp / thời gian để hoàn thành bằng cách sử dụng công cụ ddresTHER. Theo các bình luận, tôi đang thêm một đánh giá về tệp nhật ký cho phân vùng đĩa2s1 của tôi vì hiện đang chạy (đĩa2s2 đã hoàn thành sau 14,5 giờ, với một người dùng bị gián đoạn trong khoảng 6 giờ).

log1

Nhật ký phân vùng đã hoàn thành

Đối với phân vùng vừa hoàn thành, đây là kết quả của việc kiểm tra nhật ký.

nhật ký ảnh

Tham khảo (ghi chú thuật toán ddresTHER):

4 thuật toán


GNU ddresTHER không phải là một dẫn xuất của dd, cũng không liên quan đến dd theo bất kỳ cách nào ngoại trừ cả hai đều có thể được sử dụng để sao chép dữ liệu từ thiết bị này sang thiết bị khác. Sự khác biệt chính là ddresTHER sử dụng một thuật toán tinh vi để sao chép dữ liệu từ các ổ đĩa bị hỏng khiến chúng càng ít thiệt hại càng tốt.

DdresTHER quản lý hiệu quả tình trạng của cuộc giải cứu đang diễn ra và cố gắng giải cứu những phần tốt trước, lên lịch đọc bên trong các khu vực xấu (hoặc chậm) cho sau này. Điều này tối đa hóa lượng dữ liệu cuối cùng có thể được phục hồi từ một ổ đĩa bị lỗi.

Tiện ích dd tiêu chuẩn có thể được sử dụng để lưu dữ liệu từ ổ đĩa bị lỗi, nhưng nó đọc dữ liệu một cách tuần tự, có thể làm hao mòn ổ đĩa mà không giải cứu được bất cứ điều gì nếu xảy ra lỗi ở đầu ổ đĩa.

Các chương trình khác đọc dữ liệu tuần tự nhưng chuyển sang đọc kích thước nhỏ khi chúng tìm thấy lỗi. Đây là một ý tưởng tồi bởi vì nó có nghĩa là dành nhiều thời gian hơn cho các khu vực lỗi, làm hỏng bề mặt, đầu và cơ học ổ đĩa, thay vì thoát ra khỏi chúng càng nhanh càng tốt. Hành vi này làm giảm cơ hội giải cứu dữ liệu tốt còn lại.

Thuật toán của ddresTHER như sau (người dùng có thể làm gián đoạn quá trình tại bất kỳ thời điểm nào, nhưng lưu ý rằng một ổ đĩa xấu có thể chặn ddresTHER trong một thời gian dài cho đến khi kernel bỏ cuộc):

1) Tùy chọn đọc một logfile mô tả trạng thái của một cuộc giải cứu đa phần hoặc bị gián đoạn trước đó. Nếu không có tệp logfile nào được chỉ định hoặc trống hoặc không tồn tại, hãy đánh dấu tất cả miền giải cứu là không thử.

2) (Giai đoạn đầu tiên; Sao chép) Đọc các phần chưa thử của tệp đầu vào, đánh dấu các khối không thành công là không cắt xén và bỏ qua chúng. Bỏ qua cũng vượt ra ngoài các khu vực chậm. Các khu vực bị bỏ qua được thử sau trong hai lần vượt qua (trước khi cắt), đảo ngược hướng sau mỗi lần vượt qua cho đến khi tất cả các miền giải cứu được thử. Đèo thứ ba là một đường chuyền quét, với bỏ qua vô hiệu hóa. (Mục đích là để phân định các lỗi lớn nhanh, giữ logfile nhỏ và tạo điểm khởi đầu tốt để cắt xén). Chỉ các khu vực không thử được đọc trong các khối lớn. Cắt tỉa, tách và thử lại được thực hiện theo từng lĩnh vực. Mỗi lĩnh vực được thử nhiều nhất hai lần; bước đầu tiên trong bước này (thường là một phần của một khối lớn được đọc, nhưng đôi khi là một lần đọc duy nhất), lần thứ hai trong một trong các bước dưới đây là một lần đọc.

3) (Giai đoạn thứ hai; Cắt xén) Đọc chuyển tiếp một khu vực tại cạnh đầu của khối không cắt nhỏ nhất, cho đến khi tìm thấy một khu vực xấu. Sau đó đọc ngược một khu vực tại một thời điểm từ cạnh cuối của cùng một khối, cho đến khi tìm thấy một khu vực xấu. Đối với mỗi khối không được cắt xén, đánh dấu các khu vực xấu được tìm thấy là khu vực xấu và đánh dấu phần còn lại của khối đó là không phân chia mà không cố đọc nó. Lặp lại cho đến khi không còn khối không cắt. (Các khối không cắt tỉa lớn được tạo ra bằng cách ghép các khối nhỏ hơn và phần dữ liệu tốt của nó ở các cạnh do đó nhỏ hơn).

4) (Giai đoạn thứ ba; Tách) Đọc chuyển tiếp một khu vực tại trung tâm của khối không phân chia lớn nhất, cho đến khi tìm thấy một khu vực xấu. Sau đó, nếu khu vực xấu được tìm thấy không phải là khu vực đầu tiên được thử, hãy đọc ngược lại một khu vực tại trung tâm của cùng một khối, cho đến khi tìm thấy khu vực xấu. Nếu logfile lớn hơn '--logfile-size', hãy đọc tuần tự các khối không phân chia lớn nhất cho đến khi số lượng mục trong logfile giảm xuống dưới '--logfile-size'. Lặp lại cho đến khi tất cả các khối không phân chia còn lại có ít hơn 7 cung. Sau đó đọc các khối không phân chia còn lại một cách tuần tự.

5) (Giai đoạn thứ tư; Thử lại) Tùy chọn thử đọc lại các thành phần xấu cho đến khi đạt được số lần thử lại được chỉ định. Mỗi khu vực xấu chỉ được thử một lần trong mỗi lần vượt qua. DdresTHER không thể biết liệu một khu vực xấu là không thể phục hồi hoặc cuối cùng nó sẽ được đọc sau một số lần thử lại.

6) Tùy chọn viết một logfile để sử dụng sau.

Tổng kích thước lỗi ('errsize') là tổng kích thước của tất cả các khối không được cắt xén, không phân chia và khối xấu. Nó tăng trong giai đoạn sao chép và có thể giảm trong quá trình cắt, tách và thử lại. Lưu ý rằng khi ddresTHER chia các khối không thành công, làm cho chúng nhỏ hơn, tổng kích thước lỗi có thể giảm trong khi số lỗi tăng lên.

Logfile được lưu định kỳ vào đĩa, cũng như khi ddresTHER kết thúc hoặc bị gián đoạn. Vì vậy, trong trường hợp gặp sự cố, bạn có thể tiếp tục giải cứu với một chút ẩn. Khoảng thời gian giữa các lần lưu thay đổi từ 30 giây đến 5 phút tùy thuộc vào kích thước logfile (logfile lớn hơn được lưu ở các khoảng thời gian dài hơn).

Ngoài ra, cùng một logfile có thể được sử dụng cho nhiều lệnh sao chép các khu vực khác nhau của tệp đầu vào và cho nhiều lần thử khôi phục trên các tập hợp con khác nhau. Xem ví dụ này:

Giải cứu phần quan trọng nhất của đĩa đầu tiên. ddresTHER -i0 -s50MiB / dev / hdc hdimage logfile ddresTHER -i0 -s1MiB -d -r3 / dev / hdc hdimage logfile

Sau đó giải cứu một số khu vực đĩa quan trọng. ddresTHER -i30GiB -s10GiB / dev / hdc hdimage logfile ddresTHER -i230GiB -s5GiB / dev / hdc hdimage logfile

Bây giờ giải cứu phần còn lại (không truy xuất những gì đã được thực hiện). ddresTHER / dev / hdc hdimage logfile ddresTHER -d -r3 / dev / hdc hdimage logfile


đĩa vẫn được kết nối dưới cùng một tên thiết bị? Ngoài ra, bạn ddrescuechỉ cần nếu đĩa có các khối xấu, điều này sẽ không xảy ra do "ngắt kết nối cáp". Nếu bạn gặp sự cố về cáp, chỉ cần thử một cáp khác ...
frostschutz

@TommieC. bạn có thể thử ddrescuelog -t YourLog.txttrong một thiết bị đầu cuối khác?
Simply_Me

@Simply_Me Vui lòng xem câu hỏi cập nhật phản ánh hai kết quả.
Tommie C.

@frostschutz Vui lòng xem câu hỏi cập nhật để biết thêm chi tiết. Kết nối cáp bị mất xảy ra trong khi đĩa đang ghi và gây ra sự cố với bảng phân vùng. Bản thân cáp không bị hư hại.
Tommie C.

Ngắt kết nối cáp thường sẽ gây ra lỗi logic (ví dụ: dữ liệu trên đĩa không hợp lệ 100%), nhưng sẽ không gây ra sự cố vật lý với ổ đĩa - trừ khi bạn bỏ nó cùng lúc. ddrescuechỉ có thể cố gắng khôi phục các sự cố vật lý và sẽ không giúp đỡ với các lỗi logic. Đối với phần sau, hãy thử fsckhoặc tương tự ..
Udo G

Câu trả lời:


6

Mặc dù câu hỏi đã được hỏi 10 tháng trước, câu trả lời có thể có liên quan vì chu kỳ phục hồi vẫn có thể chạy tùy thuộc vào một vài yếu tố! Không có ý định chơi chữ.

Lý do là, ước tính thời gian là gần như không thể, tuy nhiên đôi khi bạn có thể có được một ý tưởng sơ bộ như sau. Một trong những lý do rõ ràng nhất là bạn không thể dự đoán được sẽ mất bao lâu để đọc một khu vực xấu và nếu bạn muốn ddresTHER đọc và thử lại từng cái một thì sẽ mất rất nhiều thời gian. Ví dụ: tôi hiện đang chạy phục hồi trên một ổ đĩa nhỏ 500 GB đang diễn ra trong hơn 2 tuần và tôi có thể còn vài ngày nữa. Nhưng tôi là một tình huống phức tạp hơn vì ổ đĩa được mã hóa và để đọc bất cứ thứ gì thành công, tôi đảm bảo có được tất cả các lĩnh vực có bảng phân vùng, thành phần khởi động và các phần quan trọng khác của đĩa. Tôi đang sử dụng các kỹ thuật cùng với ddresTHER để cải thiện cơ hội cho tất cả các thành phần xấu. TÔI,

Theo ước tính "vòng lặp", nếu bạn có nghĩa là số lần thử lại thì đó là thứ bạn xác định bằng các tham số bạn sử dụng. Nếu bạn có nghĩa là "tổng số lần vượt qua", điều đó dễ dàng được xác định bằng cách đọc về thuật toán ở đây .. > man ddresTHER </ Thuật toán: Làm thế nào ddresTHER phục hồi dữ liệu

Tôi sẽ đặc biệt nói về những con số trong màn hình chụp bạn cung cấp. Các tình huống khác có thể có các yếu tố khác được áp dụng, vì vậy hãy lấy thông tin này làm hướng dẫn chung.

Trong mẫu bạn đã cung cấp, hãy xem màn hình trạng thái đang chạy của ddresTHER. Chúng tôi nhận được tổng số "ước tính" của vấn đề (miền giải cứu) bằng cách "errsize". Đây là lượng dữ liệu "chưa được đọc". Trong mẫu là 345GB. Dòng tiếp theo bên dưới là "tỷ lệ trung bình". Trong mẫu là 583kb / s

Nếu "tỷ lệ trung bình" vẫn ở gần mức ổn định, điều này có nghĩa là bạn còn 7 ngày nữa để đi. 345 GB / (583 kb * 60 * 60 * 24) = 7.18 Tuy nhiên, vấn đề là bạn không thể dựa vào 583kb / s. Trong thực tế, bạn càng đi sâu vào phục hồi, ổ đĩa càng chậm vì nó đọc các khu vực ngày càng khó khăn hơn và đang thử lại nhiều hơn. Vì vậy, thời gian để kết thúc tăng theo cấp số nhân. Tất cả điều này phụ thuộc vào mức độ hư hỏng của ổ đĩa.

Mẫu bạn đã cung cấp cho thấy "đọc thành công" đã hơn 10 giờ trước. Điều đó nói rằng nó không thực sự nhận được bất cứ thứ gì từ ổ đĩa trong hơn 10 giờ. Điều này cho thấy ổ đĩa của bạn có thể có giá trị 345 GB (hoặc một phần) dữ liệu được chụp. Đây là tin rất xấu cho bạn.

Ngược lại, ổ đĩa 500 GB thứ hai của tôi vừa bắt đầu gặp lỗi "SMART", đã được sao chép đĩa sang đĩa (với tệp nhật ký trên ổ đĩa khác) và toàn bộ hoạt động mất khoảng 8-9 giờ. Phần cuối cùng của nó chậm lại. Nhưng điều đó vẫn có thể chịu được. Trong khi ổ đĩa rất tệ, như đã lưu ý ở trên là 2 tuần qua hoạt động trên 500GB và vẫn còn khoảng 4-5% để khôi phục.

HTH và YMMV

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.