題:
來自故障硬盤的原始副本
Christopher Ferguson
2014-07-01 00:30:36 UTC
view on stackexchange narkive permalink

我有一個Seagate驅動器(ST3400832AS 3.03),該驅動器在沒有警告的情況下嚴重損壞。醒來後發現計算機在深夜醒來並重新啟動。檢查事件日誌,發現其中充滿了NTFS錯誤。由於種種原因,我沒有此特定數據的最新備份,因此我需要用困難的方式進行備份。

我最初設法以大約1kbps的速度從磁盤上獲取了一些文件(千字節,

到目前為止,我已經嘗試了以下操作…:

  • TestDisk-檢測到舊的分區信息,然後掛起。
  • Spinrite-徒勞無功。
  • HDD Regernator-預掃描大約2-3分鐘後,驅動器變為“未就緒”狀態。
  • Seatools-真是個玩笑;所有測試均顯示該驅動器正常。

…以及其他一些原始復製程序。

到目前為止,似乎每當對驅動器加重稅時太久了,它崩潰了。有誰知道可以執行磁盤驅動器可重新啟動原始副本的軟件?我不介意是否必須重新啟動該副本十次,但是到目前為止,我已經嘗試了所有方法,但每次都是從頭開始重新啟動。僅一遍又一遍地獲取前幾GB數據並沒有多大用處。因此,緩慢,持久且具有恢復功能的功能將大有幫助。

我已經成功地凍結了硬盤驅動器,但是我不知道為什麼,所以我不能認真推薦它。
SpinRite有什麼問題?我已經看到它需要運行數天才能修復驅動器。
@Bobson讓我想起了幾年前的一次車禍。坐在冰塊和熱風扇上,成功恢復所有數據,同時關閉磁盤或在磁盤太冷時對其進行預熱#D // //返回主題:開始研究[data-recovery tag-wiki] (http://android.stackexchange.com/tags/data-recovery/info)在Android.SE上,也有許多有用的提示也適用於硬盤。
@DennisS。在不做任何事情之前,它永遠不會進入磁盤中大約十幾個扇區。即使離開12小時以上
讓SpinRite繼續前進。我聽過有關它顯然在3-4天內甚麼都不做的故事,然後驅動器已完全修復。
在Windows下(假設您正在使用NTFS)?還是可以從USB / CD / ...啟動?
@Christopher Ferguson:如果答案對您有幫助,請考慮將其標記為[接受的答案](http://softwarerecs.stackexchange.com/help/accepted-answer),以便將來其他人可以更輕鬆地找到它。這也是感謝回答您問題的人所提供幫助的一種禮貌方式。
那是幾年前的事,但是Spinrite基本上通過嘗試執行製造商認為不可能甚至毫無意義的事情來殺死我的故障磁盤。其他開源工具保存了剩餘的數據(ddrescue和dd_rescue)。別走了,那是瘋子的蛇油。
二 答案:
Andrea Lazzarotto
2016-04-18 00:44:44 UTC
view on stackexchange narkive permalink

Does anyone know of a piece of software that can perform a restartable raw copy of a disk drive?

You are basically describing GNU ddrescue which can be run from a bootable Linux live CD/DVD/USB (I like SystemRescueCD quite a lot).

Cloning the drive

First, you should identify the drives you have connected to your computer with the fdisk -l command. Here is a snippet from my hard drive:

# fdisk -l /dev/sd*Disk /dev/sda: 232,9 GiB, 250059350016 bytes, 488397168 sectorsUnits: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: dosDisk identifier: 0x8185b78cDevice     Boot  Start       End   Sectors   Size Id Type/dev/sda1  *      2048    499711    497664   243M 83 Linux/dev/sda2       501758 488396799 487895042 232,7G  5 Extended/dev/sda5       501760 488396799 487895040 232,7G 83 Linux

The command shall be run as root (as you can tell from the # sign in the terminal) and I filtered on /dev/sd* to avoid showing ramdisks.

Now, assuming that I want to clone /dev/sda (the failing drive) inside /dev/sdb which is mounted as /media/user/External (the drive holding the image I am going to create), I will issue the following command (as root):

ddrescue /dev/sda /media/user/External/copy.img /media/user/External/status.log

The file /media/user/External/status.log is a log file used by the program to keep track of its progress. This way, you can interrupt the tool if you want to, then continue later.

Generally ddrescue won't be bothered by the failing hard drive. It will simply copy the good parts first, going back to the failing sectors later, trying smaller and smaller chunk sizes. This speeds up the copying process and guarantees better results.

You can use ddrescueview to get a real-time graphical representation of the cloning process.

Recovering files from the NTFS partition

Disclaimer: I am the author of RecuperaBit.

You can recover the contents of NTFS partitions using RecuperaBit. In my opinion, it is better than other open source solutions such as Testdisk and Autopsy because it gives good results even in case of heavy corruption. At least you can recover the files which are still intact and most of the directory structure.

RecuperaBit is a Python program that does not require installation. Once you have downloaded it (either via git or by downloading and extracing the ZIP file) you can run it with the following command line (pypy is suggested):

mkdir /media/user/External/recovered_filescd [full path of recuperabit]pypy main.py /media/user/External/copy.img -o /media/user/External/recovered_files -s /media/user/External/savefile.save

Once the scanning process is over, it will start to determine the geometry of any NTFS partitions it found. After that, you can run the command recoverable to see the partitions and then, to restore e.g. partition #2:

restore 2 5restore 2 -1

Where 5 means the Root directory and -1 means the Lost Files directory.

There are a few caveats you need to be aware of:

  • RecuperaBit will try to find any NTFS partition, so it could be slow as there is currently no way to set up a threshold to avoid useless results
  • NTFS compression is not supported, hence some files might not be restored
  • Any deleted file or ghost file will be restored as well, for now you cannot choose to restore only allocated files

Other programs

There are many commercial (and a few open source) programs (especially for Windows) that can deal with NTFS recovery to various extents. I have listed and compared a bunch of them in my MSc thesis and in the accompanying slides. The following table shows my test results related to the accuracy of NTFS reconstruction with respect to 4 different disk images:

Comparison of different NTFS reconstruction programs

Further explanations and notes are given in my thesis. If you'd rather use a commercial GUI program I would recommend using either Restorer Ultimate or DMDE.

我想將gddrescue與kpartx掛載配對-它可以輕鬆處理多分區圖像。最好的還原方式雖然是*從備份*;)
@JourneymanGeek,是否`kpartx`要求分區表實際上是完整且可讀的?另外,我會說建議使用備份“不會”回答“如何執行故障驅動器的位流複製?”。 :)
可以,但是您需要安裝驅動器以取出數據,不是嗎?除非您打算將驅動器重新映像到另一個驅動器,否則這有點麻煩。
僅當分區表和MFT都在工作時才可以安裝驅動器,而損壞的驅動器則不會。這就是問題(關於驅動器克隆)和答案(關於驅動器克隆和法醫NTFS重建)的重點。
@AndreaLazzarotto良好的備份信息,+ 1。 RecuperaBit是否僅適用於NTFS?而且您沒有在測試中包括PhotoRec嗎?比較表(幻燈片21?)是否僅用於目錄樹(如文件路徑和名稱)?實際恢復的文件數據在幻燈片22中-還是該幻燈片僅用於稀疏,壓縮和加密(?)文件?
@Xen2050,當前唯一的模塊是用於NTFS的,是的。但是,可以插入其他模塊(請參見底部第56頁的論文)。 Photorec執行雕刻,而不是文件系統重建,因此根本無法進行比較。 :)有關詳細信息,我建議您閱讀第8章,否則幻燈片22不會顯示“正常”文件,因為所有顯示的工具都可以恢復它們。
@AndreaLazzarotto非常感謝您對該軟件的關注。我花了兩個月的大部分時間來嘗試使用其中的一些分區/數據恢復程序(包括Testdisk和GDB)使用原始文件結構恢復該驅動器,但到目前為止仍未成功。我只是想辭職,用Photorec自行恢復數據,但是我已經讀完了Masters論文的後半部分,這使我對再次嘗試充滿信心。
如果您不介意,我有幾個簡單的問題要澄清-首先,RB的“ Lost Files”文件夾是否包含孤立文件,這些文件無法放置在目錄樹中?其次,我在您的測試中註意到,按照當今的標準,您使用的驅動器相對較小-如果我沒記錯的話,最大驅動器為80GB。我要從中恢復數據的驅動器是2TB。您認為RecuperaBit將能夠在現實的時間內恢復如此大的驅動器嗎?您大概知道該時間範圍是多少?我不想只運行它就花費了一個多星期的時間。提前致謝!
@Hashim,丟失的文件是那些無法確定其父文件的文件。我已經在我自己的NTFS驅動器(500 GB)上使用RecuperaBit,並且最多花費時間來掃描磁盤(尤其是通過USB 3而不是SATA的時候)。如果找到引導扇區,則RecuperaBit無需確定分區從何處開始,因此速度更快。
Mike
2014-07-23 01:05:35 UTC
view on stackexchange narkive permalink

我對不可阻擋的副本感到很幸運。當普通的Windows或DOS副本給我CRC錯誤時,我能夠從具有許多壞扇區的硬盤驅動器中獲取許多文件。大多數文件都是可用的,即使Windows無法複製也是如此。我只丟失了幾張丟失了太多數據的照片。它必須運行大約一個半月才能完成驅動器。我不喜歡這樣,因為通常硬盤驅動器壞了,您希望在情況變得更糟之前迅速將它們拿走。

“計算得出它必須運行大約一個半月”。這可能是基於到目前為止的結果。但是根據我的經驗,損壞的扇區通常位於驅動器的開頭,因此它可能會壓縮磁盤的其他95%。可能不是;-)我也聽說有人讓它修復前幾個百分比,然後停止它,然後能夠複製大多數數據,因為固定的初始扇區導致邏輯磁盤/文件信息再次可讀。
根據我的經驗,Spinrite堅持嘗試讀取“同一天失敗的扇區數天”。幸運的是,我意識到並開始使用開源工具(ddrescue和dd_rescue),這些工具可以在數小時內提取大部分數據,直到硬件完全失效為止。也許如果我早些時候放棄了Spinrite,我將有更多的時間保存數據。遠離。


該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 3.0許可。
Loading...