These are awesome directions and I definitely learned some new tricks. Thanks for the effort in the extensive write up.
Data Recovery Project
- Thread starter TuxDude
- Start date
Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
So will sacrificing a chicken, which will be about as useful.
SpinRite made sense eons ago (I'm talking ST506) for non-technical users. Back in those days, a program could actually control the raw operation of a drive (head select, stepper motor position, etc.). Modern drives have much more intelligence in them and there's no way to "wiggle" the head and the various other things that SpinRite tries to do. The best you're going to get on a modern drive is "Read Long", and even that probably won't give you relevant data in the buffer. And that's assuming that the drive is attached to a controller that SpinRite knows about. Many advanced controllers provide a bare-bones INT 13 service which is enough to get an operating system booted, but not enough for SpinRite to accomplish everything it wants to do (see the SpinRite FAQ).
An announced minor update to SpinRite (6.0 to 6.1) has apparently been "in the works" for nearly 12 years. One of the things announced for 6.1 is "... a comprehensive system hardware enumerator that will roam across the PCI buss of any system, PC or Mac, to find, identify and characterize all mass storage devices and other devices of interest -- such as keyboards and mice -- on the system." Sounds a lot like what Linux, FreeBSD, etc. have been doing for decades.
Nice write-up @TuxDude ! I have sadly had to do the same type of thing in the past few years with Windows and Linux hosts that had drives die in the wrong order, or failures showed up in drives during the rebuild and took the array offline (damn 3TB Seagates dying faster than they can be swapped out).
Basically the same procedure as you had above, with live USB booting into the dying box, ddrescue the images off to USB external drive(s) and moving over to a bigger box with enough free space to work on.
My extra twist for the Linux situation was an mdadm array with LVM on top of it, but in the end the same type of loopback mounting the PVs will let you bring the VG online and then hopefully recover the filesystems in the LVs. If a LV was extended and a span of the LV starts/ends in the damaged area it can go pear-shaped quick. I was able to get most of the filesystems back, and by some scripted experimental pasting of the LV fragments together into a single image and attempting filesystem repair I was able to align the fragments and recover about 80% of the files.
Basically the same procedure as you had above, with live USB booting into the dying box, ddrescue the images off to USB external drive(s) and moving over to a bigger box with enough free space to work on.
My extra twist for the Linux situation was an mdadm array with LVM on top of it, but in the end the same type of loopback mounting the PVs will let you bring the VG online and then hopefully recover the filesystems in the LVs. If a LV was extended and a span of the LV starts/ends in the damaged area it can go pear-shaped quick. I was able to get most of the filesystems back, and by some scripted experimental pasting of the LV fragments together into a single image and attempting filesystem repair I was able to align the fragments and recover about 80% of the files.
Great write up @TuxDude
Coincidentally, here was my lesson for today...
I had been moving some media files and data around on the server Zvols today. For speed I just took down iSCSI on the DC and fired up the initiator on my laptop instead. All went well with the moves and changes until...I then decided that I needed a bootable USB for another machine. I killed the iscsi connections, plugged in my USB and dropped into Diskpart...you know where this is heading by now I'm sure...
Anyway, the long and the short of it, iSCSI did not dismount all of the Zvols, it left one little sneaky one connected. At the same time, as Murphy's law would have it, the USB pen drive I just inserted did not load it's driver properly and did not come up and I didn't notice. The pen drive was 4GB, the iSCSI Zvol was 4TB. Guess who failed to see past the number 4, selected disk 3, typed "clean" and hit enter...
400 odd GB of data...poof, gone...now using GetDataBack to move my damned files again
The lesson for today is...more coffee needed
Coincidentally, here was my lesson for today...
I had been moving some media files and data around on the server Zvols today. For speed I just took down iSCSI on the DC and fired up the initiator on my laptop instead. All went well with the moves and changes until...I then decided that I needed a bootable USB for another machine. I killed the iscsi connections, plugged in my USB and dropped into Diskpart...you know where this is heading by now I'm sure...
Anyway, the long and the short of it, iSCSI did not dismount all of the Zvols, it left one little sneaky one connected. At the same time, as Murphy's law would have it, the USB pen drive I just inserted did not load it's driver properly and did not come up and I didn't notice. The pen drive was 4GB, the iSCSI Zvol was 4TB. Guess who failed to see past the number 4, selected disk 3, typed "clean" and hit enter...
400 odd GB of data...poof, gone...now using GetDataBack to move my damned files again
The lesson for today is...more coffee needed