I've lost my data, haven't I?

[ifihaffto]

Hey everyone.

 

I had an array disk that was on REISERFS and I was continually being warned that it was getting deprecated.

I've been avoiding it for ages and thought I should bite the bullet.

 

I was considering how I was going to shuffle all my data around, which was going to end up requiring a larger drive to be bought/installed, when it dawned on me that all I should need to do is just treat it like a disk replacement and the parity drive would take care of it.

 

I think I was a little clumsy with the order of proceedings, which may have caused me to bollocks it up completely.

From dodgy memory...

 

I stopped the array.

Changed the FS on the disk.

Started the array.

 

I figured this is where it would ask me to format the disk, which I would, then it would re-build the array.

I saw that the disk was unmoutable and didn't check down the bottom to format the disk with the new FS.

 

I stopped the array again.

Unassigned the disk.

Started the array.

 

Why? I figured I needed to tell unraid that the disk wasn't being used and to rely on the parity drive.

"I'll get you a new disk in a minute"

 

Stopped the array again.

Assigned the drive back again.

Either started the array or formatted the disk and then restarted the array, which ever way that has to happen.

The disk was formatted.

 

Then I saw that the array or disk was being rebuilt.

 

Huzzah! ... I thought.

 

I confirmed that LOTS of writes to the disk in question were being performed, and I thought I was off to the races.

I monitored it for a few minutes, and I started to get hot all of a sudden when I noticed that although there were lots of writes, the disk wasn't getting any fuller.

 

Be patient, the UI just might not be a proper reflection of things.

 

Next morning... my disk usage is the same as it was when the rebuild started (despite the writes) and I seem to have lost all the data that was on the disk.

 

What did I do wrong?

[ifihaffto]

Parity to Disk 2 read/write would indicate that it should have rebuilt the disk.

Did something I did delete the data from the Parity drive and it rebuilt empty blocks?

Edited August 4 by ifihaffto

[Kilrah]

32 minutes ago, ifihaffto said:

What did I do wrong?

You formatted the drive. This erases everything.

 

Parity is only able to do one thing, rebuild a drive exactly as it last was. You formatted the drive then rebuilt it, which rebuilt the last state i.e. a freshly formatted empty drive. 

 

To change filesystems you have no choice but to copy everything off, format, then copy the data back. You only did the format so all that data is now lost.

 

You might be able to use data recovery software on the drive, don't know about options for reiserfs though.

Edited August 4 by Kilrah

[ifihaffto]

Argh. Bugger.

I figured taking it out of the array would stop the parity in place?
 

Restart array > rebuild.

As though it was a swapped drive?

 

OK. Thanks

 

[JonathanM]

The only good thing reiserfs has going for it is the extreme resiliency for recovery. If you change the file system type back to reiserfs, start the array in maintenance mode, then run the reiserfs check command

 

reiserfsck --check /dev/md2

 

Note that there is a space between --check and /dev/md2

 

Hopefully it will give further instructions, I'd capture that output and post it here before proceeding further.

 

This command may take a long time to analyze the drive since it was formatted with another filesystem, let it finish the check.

[ifihaffto]

Thank you!

 

I will give that a try and report back.

 

Exactly as written, or replace md2 with the disk assignment for Disk2?

 

EDIT: NVM, I did some googling ... md2

Edited August 5 by ifihaffto
I did some research

[ifihaffto]

3 hours ago, JonathanM said:

This command may take a long time to analyze the drive since it was formatted with another filesystem, let it finish the check.

Where will I find evidence of the check taking place?
After running the command I got a message telling me where the log will be (kind of - it just said it will be in sdout but not where to find it), but nothing else to indicate something is actually happening.

[JonathanM]

1 minute ago, ifihaffto said:

After running the command

Where did you run the command?

[ifihaffto]

Unraid console

[JorgeB]

Which Unraid release? If > 6.12.0 it's /dev/md2p1

[Kilrah]

18 hours ago, ifihaffto said:

I figured taking it out of the array would stop the parity in place?
 

Restart array > rebuild.

As though it was a swapped drive?

If you formatted the drive while it's out of the array it'd rebuild, but from what you said you formatted it in the array, so updated parity.

But as mentioned a rebuild can only restore exactly what was there anyway so it'd have rebuilt the original reiserfs disk, not a conversion.

[ifihaffto]

2 hours ago, Kilrah said:

If you formatted the drive while it's out of the array it'd rebuild, but from what you said you formatted it in the array, so updated parity.

But as mentioned a rebuild can only restore exactly what was there anyway so it'd have rebuilt the original reiserfs disk, not a conversion.

Yeah, it appears I didn't quite get it right.

 

 

[ifihaffto]

3 hours ago, JorgeB said:

Which Unraid release? If > 6.12.0 it's /dev/md2p1

6.12.10

 

I ran the amended code you provide and got this:

 

Failed to open the device '/dev/md2p1': Unknown code er3k 127

[JorgeB]

This you use the --rebuild-tree option?

[ifihaffto]

No Sir, I did not.

 

Unfortunately I know barely enough to scrape by (as you have seen  ).

 

Does that get appended to the reiserfsck command or is it run separately?

[JonathanM]

Was the array started in maintenance mode when you ran the check command?

[ifihaffto]

It was. And I've left it that way to reduce the chance of me making anything worse.

[JorgeB]

You will likely need to rebuild the superblock first, then use the rebuild tree option:

 

https://docs.unraid.net/legacy/FAQ/check-disk-filesystems/#rebuilding-the-superblock

 

Don't forget to add p1 to the device, since those instructions were for older released, after rebuilding the superblock run

 

reiserfsck --rebuild-tree /dev/md2p1

 

[ifihaffto]

On 8/6/2024 at 4:00 PM, JorgeB said:

You will likely need to rebuild the superblock first, then use the rebuild tree option:

 

https://docs.unraid.net/legacy/FAQ/check-disk-filesystems/#rebuilding-the-superblock

 

Don't forget to add p1 to the device, since those instructions were for older released, after rebuilding the superblock run

 

reiserfsck --rebuild-tree /dev/md2p1

 

Thanks for your help so far.

 

I get Failed to open the device '/dev/md2p1': Unknown code er3k 127 when I attempt to rebuild the superblock.

 

reiserfsck --rebuild-sb /dev/md2p1

 

Does it need to be an UNASSIGNED disk? It's currently in the array, which was started in maintenance mode.

[JorgeB]

3 hours ago, ifihaffto said:

Does it need to be an UNASSIGNED disk?

Nope, but if the command is failing, only option would be using a file recovery app, like UFS explorer.

[ifihaffto]

Thanks @JorgeB

 

So, stop the array, power down the nas and physically remove the disk.

Use UFS explorer or similar to try and recover any data.

Copy that somewhere (I'll get a replacement disk as it could do with some extra space).

This is where I'm unsure of the order...

 

Replace the disk, fire up the nas and add it back to and start the array (changed file system and formatted).

This is effectively adding a blank disk to the array.

Copy the files back to either the replaced disk or the share.

 

How did I go?

[JorgeB]

That will work.