2

well i issued the following command: shred -v /dev/sdb.

However I wanted to shred /dev/sda. I realized my mistake after about 2gb had been shredded (out of 2.7tb raid volume). what is the recommended action to recover these files?

  • When using a big gun don't point it at your foot. What raid system are you using? – hildred Jun 9 '15 at 2:15
  • 2
    Restore from backups. That's about your best hope. – lcd047 Jun 9 '15 at 3:51
  • Do you know what shred is for? It is to avoid recovery of your data, so either you have backups as sugested by lcd047 or you won't be able to recover your data, at least not the first 2GB. – YoMismo Jun 9 '15 at 8:09
1

Depends what was on it.

If it was LUKS encrypted, the LUKS header is gone and so is your data (unless it is still in luksOpened state in which case you should grab the output of dmsetup table --showkeys).

Unencrypted, photorec might carve some things for you. It finds unfragmented files of known types, not just photos.

If there were partitions that started beyond the dead zone, testdisk might find them for you.

If the filesystem you used has backup metadata beyond the dead zone, and you remember the exact starting offset of your partition (or maybe you used GPT which has a backup of the partitions at the end of the disk so you did not lose the starting offset in the first place).

Create an overlay as described here:

https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID#Making_the_harddisks_read-only_using_an_overlay_file

Then experiment with the overlay, for example utilizing fsck and mount options using backup superblocks (-o sb=n or whatever). You will have to google how to do these things specifically for the filesystem you used.

Since you mention raid, if the disk was part of a RAID array with redundancy on other disks (e.g. a RAID5 of /dev/sdbY, /dev/sdcY, /dev/sddY), you should simply fail it and have the data restored by redundancy information.

mdadm /dev/mdX --fail /dev/sdbY
mdadm /dev/mdX --remove /dev/sdbY
parted /dev/sdb
mdadm /dev/mdX --add /dev/sdbY
  • thanks @frostshutz! here are some responses to the issues you brought up: The volume was not encrypted. There was only one partition that started within the dead zone. The array was RAID5 but the the raid controller presented the whole thing as a single device (/dev/sdb) and within the OS I created a single partition on that device (/dev/sdb1). are you suggesting that i would be able to rebuild the array within the raid controller bios and get all my data back? thanks – mkk Jun 9 '15 at 13:46
  • No, if sdb is the raid then shred got the redundancy too. – frostschutz Jun 9 '15 at 13:48
  • thats what i figured. so i checked out imagerec, but it looks like the filenames and directory structure cannot be recovered that way. is this correct? – mkk Jun 9 '15 at 14:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.