Перш за все, не робіть нічого більше на диску (принаймні ніколи не пишіть на ньому). Диск, який не розпізнається (на відміну від "розпізнавання та виявлення порожнім або з нечитабельними даними"), схоже, вказує або на повністю розмитий диск, що chkdskне робити, або щось не так з таблицею розділів або геометрією диска або спосіб роботи з корпусом USB. Також можливий апаратний збій.
Це може статися, коли USB-корпуси намагаються домовитись між диском та комп'ютером, до якого вони підключені. Отже, перше, що потрібно зробити, - сфотографувати диск на (очевидно, більшому) диску на максимально близькому до фізичного рівня, використовуючи ddпід Linux. Тоді ви можете скористатися копією зображення до вмісту серця, не ризикуючи пошкодити реальний диск.
Оновлення: розпізнавання пристрою в Linux
На нашому «зовнішньому диску» у нас не менше трьох сутностей. Обладнання USB-корпусу, виставлене як блоковий пристрій. Фізичний диск всередині корпусу. Фізичний пристрій, тобто послідовність секторів LBA від першого до останнього. І нарешті нульовий або більше розділів даних, розміщення файлових систем. Щоб бути "розпізнаним" і відображеним на робочому столі, всі ланки ланцюгів повинні працювати. Але для зображення фізичного пристрою вам потрібні лише перші два. Якщо ви підключите пристрій і запустите командний рядок dmesg(як root), вам слід побачити щось подібне:
[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
... яка впізнається в корпусі, а потім ідентифікує себе та його вміст:
[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
Далі ви побачите драйвер інформуючи його геометрію, природи, і неявно його вузол пристрою, тут sdd(для SCSI дисків чотири, так як sda, sdbі sdcвже були прийняті):
[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)
Тоді ядро визнає, що є розділ (якщо ви цього не бачите, розділ не існує або недійсний):
[4984944.411497] sdd: sdd1
Тепер у Linux є все необхідне та повідомляє про успішне вкладення:
[4984944.416739] sd 7:0:0:0: [sdd] Attached SCSI disk
[4984944.416739] sd 7:0:0:0: Attached scsi generic sg4 type 0
І ось починається пошук розділу даних, тобто, гаразд, у нас є sdd1, але що там? , і відповідь:
[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.
Це вище було «хорошою» горою. Але тільки знаючи , що пристрій sdd, або , sdcабо sdb, дозволяє мені зробити бінарну копію (за умови , у мене є достатньо вільного місця на /mnt/backupdisk): вхідний файл /dev/sdd, вихідний файл DiskImage.raw, розмір блоку 1 MB :
# dd if=/dev/sdd of=/mnt/backupdisk/DiskImage.raw bs=1M
Зверніть увагу, що вхідний файл є, /dev/sdd а не /dev/sdd1
(або будь-яке інше число). Тепер, якщо я цього хотів, я міг би виявити зміщення розділу даних усередині DiskImage.rawі змонтувати його за допомогою циклічного пристрою. Тут ви знайдете брудні деталі.
Перша спроба відновлення
Друге, що потрібно зробити, - це поставити фізичний диск в інший корпус, забезпечивши таким чином корпус гарним і отримавши шанс нового інтерфейсу правильно інтерпретувати диск. Якщо диск знову з’явиться, можливо, попередній корпус зламаний. На всякий випадок створіть резервну копію всього вмісту нового накопичувача, перевірте резервну копію, обнуліть диск за допомогою утиліти перезапису диска, щоб вона була повністю німою (у вас не може бути два пристрої з різними думками у ланцюжку пристроїв), відформатуйте її вихідно з Windows та відновити дані. Це вдалий знімок, але я бачив, як це сталося; і спроба не надто дорога, хороші корпуси збираються приблизно за 19,99 доларів США.
Якщо початковий корпус був поганим, ви не зможете переформатувати диск, або диск не буде доступний. Ви можете спробувати новий корпус, і якщо він працює, або замініть старий корпус, або продовжуйте використовувати новий (але це варто, якщо новий корпус є набагато кращим, ніж 19,99 дол. США, Ель-Чепао).
Професійне відновлення
Професійні служби відновлення - ті, які ви можете знайти в Google. Не надто чесним способом вирішити це було б пересилання через фізичний диск, і - у випадку, якщо ви отримали "Так, немає апаратного пошкодження, і ми зможемо відновити всі ваші дані всього за $ $$$, $ $$! " відповідь - добре ви б тоді знали, що дані все-таки можна отримати. Таким чином, ви можете спробувати зробити це самостійно безкоштовно за резервну копію зображень, яку ви взяли, і заплатити лише за діагностику та диск S&H. Якщо ви цього не зробили, варіант кашляння запитуваного тіста все одно буде. Якщо є пошкодження обладнання, професійний сервіс - це ваш єдиний варіант. Існує кілька прийомів вуду, які (тимчасово) пожвавлять "мертвий" диск, часто досить довгий, щоб принаймні відновити найважливіші дані,жоден, який гарантовано працює кожен раз (нагріваючи диск, охолоджуючи його, «закручуючи» - я навіть бачив, що пропонував спритно прискорити його до твердої поверхні). Усі вони нанесуть більше шкоди, тобто ви повинні бути впевнені, що використовуєте один трюк, який спрацює в перший раз, або ви назавжди вбили диск. Я щойно додав це, щоб пояснити, чому ви побачите історії успіху щодо відроджених дисків: є такі історії. Але якщо ви хочете бути (в основному) впевнені, що це станеться з вами , добре - найміть професіонала.
Якщо ви впевнені, що з обладнанням все в порядку - крутяться диски, немає гримуть, не виникають сторонні звуки чи гудіння, не відбувається повторне калібрування кліків-чіпких - то "все", що трапилося, - це chkdskзіпсувало деякі дані.
Зробіть собі відновлення
"Домашнє" відновлення зазвичай піде так (в основному те саме, що робитимуть хлопці після скидання апаратного пошкодження), працюючи над копією зображення диска:
перевірте, чи перший сектор зображення диска є дійсною таблицею розділів. Якщо ні, скануйте зображення диска, шукаючи дійсну таблицю розділів або розпізнаваний сектор завантаження NTFS або FAT32, залежно від того, який FS був у пристрої (для блоку на 1 ТБ NTFS видається єдиною логічною можливістю). У будь-якому випадку вам слід знайти щось протягом кількох мегабайт.
якщо таблиця розділів знайдена, перевірте, чи є в розділі даних там, де в таблиці розділів сказано, що вона повинна бути. Якщо це не так, це дуже хороша новина: напевно, таблиця розділів - це все, що не так. Виправити це досить просто (це зробить кілька редакторів розділів Linux), і на диску може бути 100% відновлення. Щоб бути надійним, спробуйте встановити розділ даних в Linux за допомогою циклічного пристрою в режимі лише для читання, щоб побачити, чи читається він. Якщо це так, розгортання розділів підтверджено, і диск може бути проголошений на шляху до впевненого та повного відновлення. Якщо це не так, можливо, розділ правильний, і (частина) розділ даних був переписаний. Це погано; дивіться нижче під "Погіршення речі".
якщо він знайдений і дійсний, перевірте його на геометрії диска, а якщо вони не збігаються, це теж насправді добре , оскільки ви, можливо, знайшли першопричину проблеми. Ви можете примусити фізичну геометрію до ядра (і отримати її при завантаженні Linux ). Подивіться, чи нова геометрія призводить до того, що диск розпізнається в Linux. Якщо це так, створіть резервну копію даних, переконайтесь, що резервна копія правильна, і обнуліть диск dd(достатньо декількох мегабайт нулів на відповідному sdпристрої). Вимкніть комп’ютер (не перезавантажуйте; гаразд, це параноїк, але це коштує мало і може щось досягти), потім завантажте Windows та відформатуйте тепер нечіткий диск у тому, що він вважає найкращим форматом. Це забезпечує відсутність конфліктів з Windows. Відновлення даних на диску. Насолоджуйтесь.
якщо трюк з геометрії не працює, або розділ неможливо знайти, або коли він виявиться порожнім, все погіршиться. Вам потрібен інструмент відновлення, здатний сканувати зображення диска в пошуку областей даних (MFT тощо) втрачених даних. І знайшовши, інтерпретуйте їх, щоб отримати дані. Це важка робота і не завжди може бути повністю автоматизована. На нижчому та відчайдушнішому рівні це передбачає сканування підписів окремих файлів, сподіваючись, що вони будуть лежати у суміжних блоках на диску. Таку операцію я хотів би із задоволенням залишити професіоналам. Я робив це кілька разів, завжди успішно, зі старими дисками FAT. Зробив це ще раз, приблизно на 50% успішно, з новими та більшими та більш фрагментарними дисками FAT32. Я зробив спробу кілька разів, із поганими результатами (але я мав повне резервне копіювання і насправді не давав все це), на набагато складніші файлові системи NTFS та ext4.
Ручне відновлення з Linux
ОК, так що ви намагаєтеся змонтувати розділ в Linux і отримати помилки ( зверніть увагу , що /dev/sdc і різні речі - зображення відноситься до )./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
... це, мабуть, вказує на те, що розділ, як вважає система , є неправильним або сильно пошкодженим. Давайте спочатку перевіримо перший варіант:
# fdisk /dev/sdc
Ви отримуєте щось подібне:
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
Наступним кроком буде перевірка фактичного запуску розділу. Шукаючи файл зображення (або /dev/sdc), ми шукатимемо підпис 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
... з наведеними вище даними ми очікуємо, що завантаження NTFS буде в секторі 63, тому ми встановили skip. Крім того, ми спробуємо з кожним сектором першого (скажімо) мегабайт ...
# dd if=/dev/sdc bs=512 count=2000000 2>/dev/null | hexdump -C | grep "00:EB 52 90 4E 54 46 53"
... просто щоб бути впевненим, що є лише один завантажувальний сектор (у мене це траплялося. На диску FAT32, але все ж ) і що помилок читання ніде немає.
Ваш результат
00007e00 eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00 |.R.NTFS .....|
саме те, що ми очікували: сектор 63 дає зміщення 63 × 512 = 32256 = 7e00 шістнадцяткової. Сектор завантаження NTFS є, і таблиця розділів здається правильною .
Тому ми можемо скопіювати великий фрагмент /dev/sdc1, скажімо, /tmp/mydisk.imgі спробувати виправити це з Linux. Це не призведе до пошкодження фізичного диска, який залишатиметься незмінним для інших спроб. А оскільки тепер ми знаємо, що ПТ є правильним, ми можемо використовувати /dev/sdc1для копіювання та розважати сподіваннями, які раніше не могли:
# dd if=/dev/sdc1 of=/tmp/mydisk.img bs=1G count=10
...after copying 10 gigabytes...
# ntfsfix /tmp/mydisk.img
Якщо NTFSfix не працює, ми маємо проблеми. Однак є більш точні утиліти, які можна спробувати. Якщо вам потрібно відновити файли зображень JPEG, і файлова система не була фрагментована, це можна зробити автоматично, шукаючи заголовки JPEG. Це ж майже стосується документів PDF, TIFF та Office, за винятком того, що я не знаю, як їх розпізнати (для JPEG, я б :-)). Як остаточний варіант, я знайшов цих хлопців - я їх не знаю, не пов’язаний з ними і не буду приймати жодної провини. Однак, як ці речі йдуть, ціна є дуже розумною.
