Jump to content

Need to reuse Parity drive temporarily - Sanity check.


EddieA

Recommended Posts

OK, stupid me deleted the wrong file off one of my shares, and I really need to try and recover it.  The moment I realised what I'd done, I stopped the array, and haven't touched it since.  I know exactly which drive "did" contain the file.

 

After using Google for a while, it appears that there, may, be a way to get this back, but to do it safely, I need another drive of the same, or larger, size.  Yeah, you guessed it, the only one I could possibly use is my parity.  All the drives are identical size/model.  Here's what I was thinking of doing, and just wanted a sanity check, that when I re-start the array, it will correctly start to rebuild the parity.

 

  • 1.  dd the partition with the deleted file, to overwrite the parity partition
  • 2.  On the parity disk, try the recovery using: reiserfsck --rebuild-tree --scan-whole-partition
  • 3.  Cross fingers
  • 4.  Check if the file was recovered on the parity disk
  • 5.  Copy file, hopefully, from parity disk back to it's real home
  • 6.  This is where I'm not 100% sure about what to do
    As I haven't moved any of the drives around, they are all still assigned in the same slots in unRAID, can I just restart the array, and it will recognise that the parity disk is no longer valid, and rebuild.  In which case I am finished.  Or do I:
  • 7.  Select "no device" as my parity
  • 8.  Start and then stop the array, so it "forgets" about the parity
  • 9.  Reassign my parity, and start the array

 

Cheers.

Link to comment

OK, stupid me deleted the wrong file off one of my shares, and I really need to try and recover it.  The moment I realised what I'd done, I stopped the array, and haven't touched it since.  I know exactly which drive "did" contain the file.

 

After using Google for a while, it appears that there, may, be a way to get this back, but to do it safely, I need another drive of the same, or larger, size.  Yeah, you guessed it, the only one I could possibly use is my parity.  All the drives are identical size/model.  Here's what I was thinking of doing, and just wanted a sanity check, that when I re-start the array, it will correctly start to rebuild the parity.

 

  • 1.  dd the partition with the deleted file, to overwrite the parity partition
  • 2.  On the parity disk, try the recovery using: reiserfsck --rebuild-tree --scan-whole-partition
  • 3.  Cross fingers
  • 4.  Check if the file was recovered on the parity disk
  • 5.  Copy file, hopefully, from parity disk back to it's real home
  • 6.  This is where I'm not 100% sure about what to do
    As I haven't moved any of the drives around, they are all still assigned in the same slots in unRAID, can I just restart the array, and it will recognise that the parity disk is no longer valid, and rebuild.  In which case I am finished.  Or do I:
  • 7.  Select "no device" as my parity
  • 8.  Start and then stop the array, so it "forgets" about the parity
  • 9.  Reassign my parity, and start the array

 

Cheers.

You do not need to go through all that, especially if you have not written to the drive since you deleted the file.  You can leave the parity disk assigned.

 

The easiest way to un-erase the file is to

un-mount the specific drive  (as an example, I'll use disk3)

 

umount /mnt/disk3

(yes, it is umount)

The disk will not un-mount if it is currently in use, so you might have to kill any applications accessing files on it, and change directory so you are not in one of its directories with your telnet session.

 

You may need to stop SAMBA with

killall smbd

before the disk can be un-mounted.

 

Once the disk is un-mounted, run the following command:

reiserfsck --rebuild-tree -S /dev/md3

 

It will scan the entire disk rebuilding the file tree and put the deleted files and file-fragments in a lost+found directory it will create at the root of the drive.

 

Once the file-system-check is completed, you can re-mount the drive by typing:

mount /dev/md3 /mnt/disk3

 

you can re-start samba by typing:

/usr/sbin/smbd -D

 

Your deleted file should be there in the lost+found folder.  (You may have to re-name it, as it will be named after the file-node it occupied)

 

People have recovered files even after completely re-formatting the disk.  The odds of you recovering the file is very high.

 

Joe L.

 

Link to comment

K.  Thanks, I'll try that.

 

It was just that all the articles I found, strongly advised you not to run that on your "live" disk, but a copy.

 

And I'll have to read up on the relationship between the /dev/mdn and /dev/diskn when mdadm is running in unRAID.  Or do they both, basically, point at the same device.

 

Cheers.

Link to comment

Well, it looked like it worked.  There was a file in lost+found of the correct size and the right date/time stamp to match the other files in the directory it came from.

 

Problem was, it was all zero's.  Yep, 241GBs of zeros.  Rats.  :o>:(:o

 

Ah well, that'll teach me to fat finger things.

 

Cheers.

Link to comment

K.  Thanks, I'll try that.

 

It was just that all the articles I found, strongly advised you not to run that on your "live" disk, but a copy.

 

And I'll have to read up on the relationship between the /dev/mdn and /dev/diskn when mdadm is running in unRAID.  Or do they both, basically, point at the same device.

 

Cheers.

/dev/md2 is the parity protected device for whatever /dev/sdX1 partition is logically assigned to it using the "devices" assignment.

 

/dev/disk2 is the mount point that the /dev/md2 device is mounted on.

 

if you are running mdadm it sounds like you have something non-standard.  It is not on my server.

 

 

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...