khôi phục phân vùng ext4 sau khi bắt đầu HD


8

Tôi đã vô tình sử dụng ddvà ghi trên 208 MB đầu tiên của đĩa bên ngoài. Những gì tôi đã viết là một phân vùng riêng (Debian Nestinstaller), vì vậy những gì tôi thấy bây giờ không phải là phân vùng ext4 cũ (hiện đã bị hỏng) mà là một phân vùng nhỏ khác. Điều này giới hạn các công cụ và lời khuyên tôi có thể làm theo.

Kế hoạch của tôi là tạo lại bảng phân vùng testdiskvà sau đó sửa mọi thứ với các siêu khóa sao lưu như được mô tả ở đây . Tôi sẽ mất 208 MB đầu tiên nhưng không sao so với 300 GB dữ liệu khác trong đó. Một cái gì đó như sau:

mke2fs -n /dev/sdb1   # doesn't work because sdb1 is the 208MB new partition
testdisk ...          # used this to create new correct partition table
mke2fs -n /dev/sdb1   # now works fine, get backup superblock positions
e2fsck -b backup_position -y /dev/sdb1 # returns many errors hence the -y

Tuy nhiên, tôi đã không thể phục hồi bất cứ điều gì. Tôi đã từng testdiskviết một bảng phân vùng mới phù hợp với những gì tôi có trước đây. Khi tôi chạy e2fsck, tôi gặp nhiều lỗi khác nhau. Tôi nhận được một hệ thống tập tin sau đó nhưng nó hoàn toàn trống rỗng, không có tập tin.

Thư mục bị mất + tìm thấy có đầy đủ các tệp (tôi đã khôi phục) nhưng tôi cần khôi phục cây thư mục, không chỉ các tệp. Tôi cần tên tệp và các thư mục trước để biết các tệp là gì (hình ảnh kính hiển vi, dữ liệu thông số khối, v.v. Nếu không có tên và thư mục nơi chúng ở, chúng không có nghĩa gì).

Tôi đã nhận được một HD khác giống hệt và tạo một bản sao của toàn bộ HD ddđể tôi có thể thử nghiệm phục hồi mà không mất bất cứ thứ gì. Có lời khuyên nào không?


Bạn có biết bao nhiêu phân vùng bạn đã có trước đây?
Cougar

@Cougar có. Tôi đã có một phân vùng chính ext4 duy nhất bao trùm toàn bộ đĩa.
carandraug

2
Đầu tiên tôi sẽ đề nghị tạo lại phân vùng bằng fdisk hoặc bất kỳ công cụ phân vùng cấp thấp nào khác. Cách khôi phục ext4 của bạn sau đó được hiển thị tại đây: link
Cougar

@Cougar đó thực sự là liên kết tôi đã theo dõi để cố gắng khôi phục phân vùng. Sự khác biệt là tôi đã sử dụng testdiskđể tạo lại phân vùng. Tôi sẽ thử với fdisk.
carandraug

@Cougar sử dụng fdiskTôi thậm chí không thể sử dụng e2fsckvì nó sẽ không tìm thấy các bản sao lưu siêu khối. Tôi nghĩ vấn đề là tôi không thể chỉnh sửa CHS (phân vùng mới đặt thành 64 nhưng phải là 255)
carandraug

Câu trả lời:


7

Cuối cùng tôi đã cố gắng khắc phục điều này. Chỉ để ghi lại đây là cách tôi đã làm nó. Một phần của giải pháp tôi tìm thấy ở đây và nó liên quan đến việc biết các cài đặt được sử dụng để tạo hệ thống tệp (tôi khá chắc chắn rằng mình đã không thay đổi mặc định).

Về cơ bản đầu tiên mà tôi đã phải sửa chữa bảng phân vùng để phản ánh những gì tôi thực sự đã có ở đó (tôi đã sử dụng testdiskcho việc này nhưng parted, cfdiskhoặc fdisksẽ làm việc tốt cũng). Tôi chỉ xóa các phân vùng sai và thay thế bằng một phân vùng kiểu ext4 duy nhất bao phủ toàn bộ đĩa với các giá trị CHS chính xác.

Phần còn lại chủ yếu là từ liên kết khi bắt đầu (đọc nó để biết chi tiết) nhưng về cơ bản tôi đã chạy mke2fs -n /dev/xxxđể tìm vị trí cho bản sao lưu superblocks. Sau đó, sử dụng bản sao lưu cuối cùng gần cuối đĩa (chỉ những bản sao ở đầu đĩa đã được ghi đè bằng dd) để chạy fsck. Điều này tạo ra rất nhiều lỗi nhưng fsck có một -ytùy chọn (không giống như -a).

$ sudo e2fsck -a -b backup_block_number /dev/xxx

Tôi nghĩ rằng điều này đã không làm việc bởi vì tôi không thể xem bất kỳ tập tin nào nhưng thực sự tất cả chúng đã được lưu vào lost+foundthư mục.

Vì vậy, cuối cùng tôi đã cứu vãn hầu hết các tệp của mình trong khi vẫn giữ tên tệp và cấu trúc thư mục của chúng. Hy vọng điều này có thể giúp đỡ những người khác trong tương lai.


-1

Ok, điều này hoạt động để phục hồi từ một ổ đĩa vô tình bị mắc kẹt trong một mảng MegaRAID. Bộ điều khiển RAID của tôi đã kích hoạt TẤT CẢ các ổ đĩa trong RAID, không chỉ các ổ cho mảng RAID6 mà tôi đang làm lại. Ôi! Ít nhất tôi đã thực hiện một init nhanh, và không phải là init chậm - init chậm xóa sạch ổ đĩa thành số không.

Khởi động nhanh xóa 10M ở đầu và cuối ổ đĩa. Vì vậy, tôi với một phân vùng ext4 trên toàn bộ ổ đĩa (trong Linux) và một ổ đĩa, RAID0, đã có một số cơ hội. Với ổ đĩa là ổ đĩa 6TB và gần 5TB trên ổ đĩa, tôi đã toát mồ hôi - đó là bản sao lưu của mảng RAID6 mà tôi đang cải tổ!

Nhân tiện, tôi đã không trượt lên - LSI MegaRAID KHÔNG nên có các ổ đĩa trong nhóm ổ đĩa khác của tôi - nhưng nó đã làm. Một lưu ý, những gì tôi nên làm là BỎ L DR R DRNG KHAI THÁC TỪ KHAI THÁC và nhập lại SAU KHI tôi có nhóm ổ RAID6 mới được sắp xếp. Tôi ngớ ngẩn quá. THẬT SỰ ngốc nghếch tôi ....

OK, may mắn thay, LSI MegaRaid không có gì lạ mắt với các ổ RAID0 (nếu có một cái tôi đoán không chắc chắn về nhiều). Đây là những gì tôi đã làm để sửa chữa nó. Hệ điều hành = Fedora F22. Drive = một phân vùng ext4 lớn, được thực hiện với parted. Đầu tiên tôi chụp nhanh ổ đĩa vào một ổ đĩa hoàn toàn mới, chính xác, trong một máy chủ dự phòng có một vài khe cắm dự phòng :: Mười giờ sau nó đã hoàn thành ......

$ dd if=/dev/sdb of=/dev/sdc bs=64M conv=notrunc
89424+1 records in
89424+1 records out
6001175126016 bytes (6.0 TB) copied, 35130.2 s, 171 MB/s

Đó là bản sao lưu vàng của tôi.

LƯU Ý - Ổ đĩa của tôi là /dev/sdb- bạn cần đặt ổ đĩa của mình vào bất kỳ ổ đĩa nào bạn đang cố khôi phục. Đừng làm hỏng các ổ đĩa, nếu không bạn sẽ còn gặp nhiều rắc rối nữa ....

Sau đó, tôi đã làm như sau.

.

(2) khởi động lại máy FC22 với ổ đĩa. Chạy parted, làm lại phân vùng (trong trường hợp của tôi, xóa cái bị hỏng, viết vào phân vùng ext4 mới 0% đến 100%). Bạn phải biết chính xác các phân vùng ban đầu ở đâu và loại chính xác của chúng - bước tiếp theo phụ thuộc vào điều này - nếu không, DỪNG Ở ĐÂY. Bạn sẽ không làm được. sử dụng testdiskphotorechoặc tương tự, hoặc cho một ổ đĩa lớn, nơi nó thực sự quan trọng, gửi nó ra.

(3) chạy mke2fs -n /dev/sdb1(đừng quên -n, hoặc một lần nữa bạn có thể bỏ đi ...)

Đối với tôi, kết quả trông như sau:

$ mke2fs -n /dev/sdb1
$ mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 1464843008 4k blocks and 183107584 inodes
Filesystem UUID: 1ac318a6-7953-42d5-8d7b-0597c54e1935
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848, 512000000, 550731776, 644972544

Có bạn đây, đó là nơi mà tất cả các siêu khóa dự phòng là ...... Chúng tôi biết đầu tiên và cuối cùng là rác, nhưng những cái ở giữa sẽ ổn. (Lưu ý, bạn có thể sử dụng mkfs.ext4 -n /dev/sdb1để cực kỳ thận trọng và nhận được kết quả tương tự).

(4) Chạy e2fsck -y -b 102400000 /dev/sdb1. Bạn sẽ cần -y, vì sẽ có rất nhiều "có" cần thiết để khắc phục tình trạng lộn xộn được tạo ra bởi mặt trước bị thiếu của đĩa .... và chọn bất kỳ siêu khối nào ở giữa bạn thích ... và sau khoảng 30 phút của sự im lặng (sử dụng một thiết bị đầu cuối khác và "trên cùng" để xem tiến trình, hoặc đèn nhấp nháy) trong trường hợp của tôi, một phân vùng có thể gắn kết và khá nhiều thứ còn nguyên vẹn trong /lost+foundthư mục.

Dù sao, tôi hy vọng điều này sẽ giúp - nếu bạn đang đọc kỹ điều này, thì tôi chúc bạn may mắn nhất. Và cảm ơn những người viết ở trên. Bạn đã cứu tôi khỏi một kết thúc thực sự mệt mỏi .....

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.