Trước hết, đừng làm gì thêm trên đĩa (ít nhất là không bao giờ ghi vào nó). Đĩa không được nhận dạng (trái ngược với "được nhận ra và tìm thấy trống hoặc với dữ liệu không thể đọc được") dường như chỉ ra một đĩa bị nổ hoàn toàn, chkdskkhông phải là không làm được, hoặc có gì đó không đúng với bảng phân vùng hoặc hình học của đĩa hoặc cách bao vây USB xử lý nó. Một lỗi phần cứng cũng có thể.
Điều này có thể và sẽ xảy ra khi các vỏ USB cố gắng thương lượng giữa đĩa và máy tính mà chúng được kết nối. Vì vậy, điều đầu tiên cần làm là chụp ảnh đĩa trên đĩa (rõ ràng là lớn hơn) ở mức gần nhất với vật lý có thể, sử dụng ddtrong Linux. Sau đó, bạn có thể nghịch ngợm với một bản sao hình ảnh vào nội dung trái tim của bạn, mà không có nguy cơ làm hỏng thêm đĩa thực.
Cập nhật: nhận dạng thiết bị trong Linux
Chúng tôi có không ít hơn ba thực thể trong "đĩa ngoài" của chúng tôi. Phần cứng bao vây USB, lộ ra như một thiết bị khối. Các đĩa vật lý bên trong bao vây. Thiết bị vật lý, nghĩa là chuỗi các lĩnh vực LBA từ đầu đến cuối. Và cuối cùng là không hoặc nhiều phân vùng dữ liệu, lưu trữ các hệ thống tệp. Để được "nhận diện" và hiển thị trong máy tính để bàn, tất cả các liên kết của chuỗi cần phải hoạt động. Nhưng để chụp ảnh thiết bị vật lý, bạn chỉ cần hai cái đầu tiên. Nếu bạn cắm thiết bị và chạy dòng lệnh dmesg(với quyền root), bạn sẽ thấy một cái gì đó như thế này:
[4984939.028491] usb 8-6: new high speed USB device using ehci_hcd and address 3
[4984939.166658] usb 8-6: configuration #1 chosen from 1 choice
[4984939.170660] scsi7 : SCSI emulation for USB Mass Storage devices
[4984939.172003] usb-storage: device found at 3
[4984939.172005] usb-storage: waiting for device to settle before scanning
... đó là bao vây được công nhận, và sau đó xác định chính nó và nội dung của nó:
[4984939.170660] usb 8-6: New USB device found, idVendor=1058, idProduct=1021
[4984939.170660] usb 8-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[4984939.170660] usb 8-6: Product: Ext HDD 1021
[4984939.170660] usb 8-6: Manufacturer: Western Digital
[4984939.170660] usb 8-6: SerialNumber: 574D43305431303831303734
[4984944.400970] usb-storage: device scan complete
Tiếp theo, bạn sẽ thấy trình điều khiển thông báo về hình dạng, bản chất và ngầm định nút thiết bị của nó, tại đây sdd(đối với SCSI Disk Four, kể từ đó sda, sdbvà sdcđã được thực hiện):
[4984944.404739] scsi 7:0:0:0: Direct-Access WD Ext HDD 1021 2021 PQ: 0 ANSI: 4
[4984944.404739] sd 7:0:0:0: [sdd] 1953519616 512-byte hardware sectors (1000202 MB)
[4984944.407367] sd 7:0:0:0: [sdd] Write Protect is off
[4984944.407369] sd 7:0:0:0: [sdd] Mode Sense: 17 00 10 08
[4984944.407371] sd 7:0:0:0: [sdd] Assuming drive cache: write through
[4984944.408741] sd 7:0:0:0: [sdd] 1953519616 512-byte hardware sectors (1000202 MB)
Sau đó, kernel nhận ra rằng có một phân vùng (nếu bạn không thấy điều này, phân vùng không có ở đó hoặc không hợp lệ):
[4984944.411497] sdd: sdd1
Bây giờ Linux có mọi thứ nó cần và báo cáo tệp đính kèm thành công:
[4984944.416739] sd 7:0:0:0: [sdd] Attached SCSI disk
[4984944.416739] sd 7:0:0:0: Attached scsi generic sg4 type 0
Và vì vậy, việc tìm kiếm phân vùng dữ liệu bắt đầu, tức là OK, chúng ta có sdd1, nhưng cái gì ở đó? và câu trả lời là:
[4984997.498613] NTFS driver 2.1.29 [Flags: R/W MODULE].
[4984997.554613] NTFS volume version 3.1.
[4984997.568859] NTFS-fs error (device sdd1): load_system_files(): $LogFile is not clean. Mounting read-only. Mount in Windows.
[4985390.027808] NTFS-fs error (device sdd1): ntfs_remount(): Volume has errors and is read-only. Cannot remount read-write.
[4985442.423299] NTFS volume version 3.1.
[4985442.425032] NTFS-fs error (device sdd1): load_system_files(): $LogFile is not clean. Mounting read-only. Mount in Windows.
Đây là một gắn kết "tốt". Nhưng chỉ biết rằng thiết bị đang sdd, hay sdchay sdb, cho phép tôi để tạo một bản sao nhị phân (giả sử tôi có đủ không gian trống trên /mnt/backupdisk): tập tin đầu vào /dev/sdd, tập tin đầu ra DiskImage.raw, khối kích thước 1 MB :
# dd if=/dev/sdd of=/mnt/backupdisk/DiskImage.raw bs=1M
Lưu ý rằng tệp đầu vào là /dev/sdd và không /dev/sdd1
(hoặc bất kỳ số nào khác). Bây giờ nếu tôi muốn, tôi có thể tìm ra phần bù của phân vùng dữ liệu bên trong DiskImage.rawvà gắn kết nó với sự trợ giúp của một thiết bị lặp. Ở đây bạn sẽ tìm thấy các chi tiết bẩn.
Nỗ lực phục hồi đầu tiên
Điều thứ hai cần làm là đặt đĩa vật lý vào một vỏ bọc khác, do đó đảm bảo vỏ bọc được tốt và có cơ hội bao vây mới diễn giải chính xác đĩa. Nếu đĩa xuất hiện trở lại, nó có thể là bao vây trước đó đã bị hỏng. Trong trường hợp, hãy sao lưu tất cả nội dung của ổ đĩa mới, xác minh bản sao lưu, zero đĩa với tiện ích ghi đè lên đĩa để nó hoàn toàn bị câm (bạn không thể có hai thiết bị có ý kiến khác nhau trong chuỗi thiết bị), định dạng lại tự nhiên từ Windows và khôi phục dữ liệu. Đó là một phát súng may mắn, nhưng tôi đã thấy nó xảy ra; và nỗ lực này không quá tốn kém, các vỏ bọc tốt sẽ có giá khoảng 19,99 đô la Mỹ mới.
Trong trường hợp bao vây ban đầu là xấu, bạn sẽ không thể định dạng lại đĩa, hoặc đĩa sẽ không thể truy cập được. Bạn có thể thử lại vỏ bọc mới và nếu nó hoạt động, hãy thay thế vỏ bọc cũ hoặc tiếp tục sử dụng vỏ bọc mới (nhưng điều này đáng giá nếu vỏ bọc mới khá tốt hơn El Cheapo 19,99 đô la Mỹ).
Phục hồi chuyên nghiệp
Dịch vụ khôi phục chuyên nghiệp, những dịch vụ bạn có thể tìm thấy với Google. Một cách không quá trung thực sẽ là gửi qua đĩa vật lý và - trong trường hợp bạn nhận được "Có, không có thiệt hại về phần cứng và chúng tôi có thể khôi phục tất cả dữ liệu của bạn chỉ với US $ $$$, $ $$! " Trả lời - sau đó bạn sẽ biết rằng dữ liệu vẫn có thể cứu được. Vì vậy, bạn có thể cố gắng tự làm miễn phí trên bản sao lưu ảnh bạn đã chụp và chỉ trả tiền cho chẩn đoán và S & H trên đĩa. Nếu bạn thất bại, tùy chọn ho ra bột yêu cầu vẫn sẽ ở đó. Nếu có là hư hỏng phần cứng, dịch vụ chuyên nghiệp về cơ bản là bạn chỉ lựa chọn. Có một số thủ thuật voodoo sẽ (tạm thời) hồi sinh đĩa "chết", thường đủ lâu để khôi phục dữ liệu quan trọng nhất ít nhất,không cái nào được đảm bảo hoạt động mỗi lần (làm nóng đĩa, làm mát nó, "xoay" nó - tôi thậm chí còn thấy đề nghị rap thông minh trên bề mặt cứng). Tất cả chúng sẽ gây sát thương nhiều hơn, tức là bạn phải chắc chắn sử dụng một thủ thuật sẽ hoạt động lần đầu tiên, hoặc bạn sẽ giết đĩa vĩnh viễn. Tôi chỉ cần thêm này để giải thích lý do tại sao bạn sẽ thấy câu chuyện thành công về đĩa phục hồi: có những câu chuyện như vậy. Nhưng nếu bạn muốn (hầu hết) chắc chắn điều đó sẽ xảy ra với bạn , hãy thuê một chuyên gia.
Nếu bạn chắc chắn phần cứng vẫn ổn - quay đĩa, không có tiếng lục lạc, không có âm thanh hoặc tiếng ồn lạ, không có sự hiệu chỉnh lại nhấp chuột - thì "tất cả" đã xảy ra là chkdsklàm rối tung một số dữ liệu.
Tự phục hồi
Phục hồi "tại nhà" thường sẽ diễn ra như thế này (về cơ bản giống như những người chuyên nghiệp sẽ làm khi giảm giá phần cứng), hoạt động trên bản sao ảnh đĩa:
kiểm tra xem khu vực đầu tiên của hình ảnh đĩa là một bảng phân vùng hợp lệ. Nếu không, hãy quét hình ảnh đĩa để tìm bảng phân vùng hợp lệ hoặc khu vực khởi động NTFS hoặc FAT32 có thể nhận biết, tùy thuộc vào FS trên thiết bị (đối với đơn vị 1 TB, NTFS dường như là khả năng logic duy nhất). Dù bằng cách nào bạn cũng phải tìm thứ gì đó trong vài megabyte đầu tiên.
nếu bảng phân vùng được tìm thấy, hãy xác minh rằng phân vùng dữ liệu là nơi bảng phân vùng cho biết. Nếu không, đây là một tin rất tốt: có lẽ bảng phân vùng là tất cả đều sai. Việc sửa nó rất dễ dàng (một số trình soạn thảo phân vùng Linux sẽ làm điều đó) và đĩa có thể được phục hồi 100%. Để đảm bảo an toàn, hãy thử gắn phân vùng dữ liệu trong Linux bằng thiết bị lặp ở chế độ chỉ đọc để xem nó có đọc được không. Nếu đúng như vậy, phân vùng borking được xác nhận và đĩa có thể được phát âm theo cách của nó để chắc chắn và phục hồi hoàn toàn. Nếu không, có thể phân vùng là đúng và (một phần) phân vùng dữ liệu đã được viết lại. Thật tệ; xem bên dưới "mọi thứ trở nên tồi tệ".
nếu nó được tìm thấy và hợp lệ, hãy kiểm tra nó dựa trên hình học ổ đĩa và, nếu chúng không khớp, đó thực sự là một điều tốt , vì bạn có thể đã tìm ra nguyên nhân gốc rễ của vấn đề. Bạn có thể buộc hình học vật lý vào kernel (và lấy nó khi khởi động Linux ). Xem nếu hình học mới dẫn đến đĩa được nhận dạng trong Linux. Nếu có, hãy sao lưu dữ liệu, xác minh sao lưu là chính xác và không cần đĩa với dd(một vài megabyte số 0 cho sdthiết bị phù hợp là đủ). Tắt nguồn máy tính (không chỉ khởi động lại; OK, nó hoang tưởng, nhưng chi phí thấp và có thể hoàn thành một cái gì đó), sau đó khởi động Windows và định dạng đĩa bây giờ thành định dạng tốt nhất. Điều này đảm bảo không có xung đột với Windows. Khôi phục dữ liệu trên đĩa. Thưởng thức.
nếu thủ thuật hình học không hoạt động, hoặc phân vùng không thể được tìm thấy, hoặc một khi tìm thấy nó dường như trống rỗng, mọi thứ trở nên tồi tệ. Bạn cần một số công cụ khôi phục có khả năng quét hình ảnh đĩa để tìm kiếm các vùng dữ liệu (MFT, v.v.) của dữ liệu bị mất. Và một khi tìm thấy, giải thích chúng để có được dữ liệu. Đây là một công việc khó khăn và không thể luôn luôn hoàn toàn tự động. Ở mức độ thấp hơn và tuyệt vọng hơn, điều này liên quan đến việc quét chữ ký của các tệp riêng lẻ , hy vọng rằng chúng sẽ nằm trong các khối liền kề trong đĩa. Mặc dù vậy, loại hoạt động này tôi sẵn sàng để lại cho các chuyên gia. Tôi đã làm điều đó nhiều lần, luôn luôn thành công, với các đĩa FAT cũ. Tôi đã làm lại, khoảng 50% thành công, với các đĩa FAT32 mới hơn và lớn hơn và phân mảnh hơn. Tôi đã cố gắng một vài lần, với kết quả kém (nhưng tôi đã sao lưu đầy đủ và không thực sự mang lại tất cả cho mình), trên các hệ thống tệp NTFS và ext4 phức tạp hơn nhiều.
Phục hồi thủ công từ Linux
OK, vì vậy bạn cố gắng gắn kết phân vùng trong Linux và gặp lỗi ( lưu ý rằng /dev/sdc và đó là những thứ khác nhau - hình ảnh đề cập đến )./dev/sdcN /dev/sdc
# mount -t ntfs /dev/sdc1 /mnt/recovery
ntfs_mst_post_read_fixup_warn: magic: 0x00000000 size: 1024 usa_ofs: 0 usa_count: 65535: Invalid argument
Record 1 has no FILE magic (0x0)
Failed to open inode $MFTMirr: Input/output error
... điều này dường như chỉ ra rằng phân vùng, như hệ thống tin rằng nó bị sai hoặc bị hư hỏng nặng. Trước tiên, hãy kiểm tra tùy chọn đầu tiên:
# fdisk /dev/sdc
Bạn nhận được một cái gì đó như thế này:
Disk /dev/sdc: 1000.2 GB, 1000204885504 bytes
1 heads, 63 sectors/track, 31008335 cylinders, total 1953525167 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x9d2b7596
Device Boot Start End Blocks Id System
/dev/sdc1 63 1953520127 976760032+ 7 HPFS/NTFS/exFAT
Bước tiếp theo sẽ là kiểm tra phân vùng thực sự bắt đầu. Bằng cách tìm kiếm vào tệp hình ảnh (hoặc /dev/sdc), chúng tôi sẽ tìm kiếm chữ ký NTFS:
00000000:EB 52 90 4E 54 46 53 20 -20 20 20 00 02 08 00 00 .R.NTFS ........
00000010:00 00 00 00 00 F8 00 00 -3F 00 FF 00 3F 00 00 00 ........?...?...
00000020:00 00 00 00 80 00 80 00 -4A F5 7F 00 00 00 00 00 ........J.......
# dd if=/dev/sdc bs=512 count=1 skip=63 2>/dev/null | hexdump -C | head -n 1
... Với dữ liệu ở trên, chúng tôi hy vọng NTFS boot sẽ ở khu vực 63, đó là lý do chúng tôi đặt skip. Ngoài ra, chúng tôi sẽ thử với mọi lĩnh vực trong megabyte (giả sử) đầu tiên ...
# dd if=/dev/sdc bs=512 count=2000000 2>/dev/null | hexdump -C | grep "00:EB 52 90 4E 54 46 53"
... chỉ để chắc chắn rằng chỉ có một khu vực khởi động (tôi đã xảy ra điều này với tôi. Trên đĩa FAT32, nhưng vẫn không có ) và không có lỗi đọc ở bất cứ đâu.
Kết quả của bạn
00007e00 eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00 |.R.NTFS .....|
là chính xác những gì chúng ta mong đợi: sector 63 cho độ lệch 63 × 512 = 32256 = 7e00 thập lục phân. Khu vực khởi động NTFS có ở đó và bảng phân vùng có vẻ đúng .
Vì vậy, bây giờ chúng ta có thể sao chép một đoạn lớn /dev/sdc1lên, nói /tmp/mydisk.imgvà cố gắng sửa nó từ Linux. Điều này sẽ không làm hỏng đĩa vật lý, vẫn sẽ không thay đổi cho các lần thử khác. Và vì bây giờ chúng tôi biết PT là chính xác, chúng tôi có thể sử dụng /dev/sdc1cho bản sao và hy vọng giải trí mà trước đây chúng tôi không thể:
# dd if=/dev/sdc1 of=/tmp/mydisk.img bs=1G count=10
...after copying 10 gigabytes...
# ntfsfix /tmp/mydisk.img
Nếu NTFSfix không hoạt động, tốt, chúng tôi sẽ gặp rắc rối. Có nhiều tiện ích chính xác hơn có thể được thử, mặc dù. Và nếu bạn cần khôi phục các tệp hình ảnh JPEG và hệ thống tệp không bị phân mảnh, điều này có thể được thực hiện tự động bằng cách tìm kiếm các tiêu đề JPEG. Tương tự, hầu như, dành cho các tài liệu PDF, TIFF và Office, ngoại trừ việc tôi không biết cách nhận ra chúng (đối với JPEG, tôi sẽ :-)). Như một lựa chọn cuối cùng tôi đã tìm thấy những người này - tôi không biết họ, không liên quan đến họ và sẽ không chấp nhận bất kỳ sự đổ lỗi nào. Tuy nhiên, khi những điều này đi, giá cả rất hợp lý.
