![]() ![]() and reducing the size of reads until they succeed.ĭdrescue is also restartable, picking up state from its map file.direct disk I/O (skipping the kernel block cache).reading the disk both forwards and backwards.You use ddrescue like: ddrescue /dev/sda ~/sda.img ~/sda.map.ĭdrescue uses many strategies, including: These tools work, however, there’s a better tool for imaging near-death hard drives: ddrescue, which reads the drive, keeping track of which segments were read successfully and which need to be revisited in an auxiliary “map file”. I haven't seen differences in speed leaving it off.Ĭat will fail the first time they get an I/O error.ĭd will fail by default, but it has a parameter conv=sync,noerror instructing to ignore read errors and output zeroes for that chunk instead. Presumably, at one point, setting block size made a difference to the transfer speed? I’m fairly sure kernels today do the appropriate read-ahead though. Unix has a culture of using dd, a funny tool with roots in other operating systems, with a funny command-line-flag convention differing from other Unix tools: usually people use dd if=/dev/sda of=~/sda.img, optionally setting a magic bs=xxx block size parameter, copy/pasted from the last time you did the job. Or pv /dev/sda > ~/sda.img if I’m feeling fancy and want a progress bar. Usually I use cat /dev/sda > ~/sda.img to image a disk. Synology’s OS is Linux with a stripped-down set of userland binaries. I’d like to recover the data from this machine, to a disk image file on the other disks. I have three drives in it, and a spare slot. It’s been handy during these data recovery jobs. I have a Synology Network Attached Storage device at home. I want to copy the disk to another computer. But I don’t think I want to write to this disk again: too many I/O errors. Maybe even try to repair the filesystem again. So now I have a disk, and I want to get the data off it. ![]() I suppose my attempted filesystem repair + I/O write errors = corrupted file system. Sometimes it would come up as ‘Uninitialised’. Most of the time the drive would spin up, then spin down. They tried plugging in the drive to many other iMacs, but none of them would boot it. My local mac repair shop was thankfully able to extract the hard drive from the iMac, by pulling off the screen (which is held in with magnets) using suction cups, undoing screws of rare shape, and fishing out the SATA drive. It mounted once, but then I foolishly tried to ‘repair’ the disk in Disk Utility. The drive has many I/O errors reading it, and won’t boot into macOS. I’m currently trying to recover data from a 2009 iMac with a bad 250GB hard drive. Most of this post should work for imaging a disk on a regular non-Synology Linux system. This is what I learned, trying to recover data from a bad drive. ![]()
0 Comments
Leave a Reply. |