Hey all,

 

I was doing housekeeping last night and accidentally deleted a folder. Yes, just one folder...

 

In my attempt to recover the folder that contains valuable files., I ran the reiserfsck  command following instructions from http://lime-technology.com/forum/index.php?action=printpage;topic=619.0. Well, I ran the command from a telnet session but the connection got disconnected when my PC crashed.

 

I rebooted the server this morning and could only see files residing in other disks in share. I thought this can't be right so went to the web interface to check status of disks.  All disks flashing green and disk1 showing as unformatted.  Damn, I zapped over 1TB worth of data just to save 1 folder worth of data.  :'( :-X :o  What a bummer.

 

I've stopped using Unraid to prevent doing further damage.  Sorry, I don't have a syslog to post because I had rebooted the server twice. I'm new to Linux but can follow any instructions that would help salvage my files.

 

Joe, I hope you're reading this.

 

I should have backup my files........ :'( :'(

 

There should be a recycling bin though.

Joe (or some of the other great "masters" on here my have a better solution) but I would likely start by putting in a NEW (blank drive) for DISK1 and have it rebuild.  Keep the "old" Disk1 where you had/have your important files and keep searching for ways to recover deleted reiserfs files/folders (Joe or someone will likely tell you how to do that).

 

At least this way you can get back the other files from DISK1 while you try to figure out how to reclaim the deleted files.

on another note... yes you should keep at least 2 copies of important files.  I myself have 4 copies (PC, auto sync with versioning every 5min to UnRaid, and two offsite backups - daily and weekly).  Perhaps a bit overkill but with programs that support both rsync/scp and versioning I also have older versions of files to recover from; in the event I do other "dumb" things like save over a file by mistake.

 

Joe (or some of the other great "masters" on here my have a better solution) but I would likely start by putting in a NEW (blank drive) for DISK1 and have it rebuild.  Keep the "old" Disk1 where you had/have your important files and keep searching for ways to recover deleted reiserfs files/folders (Joe or someone will likely tell you how to do that).

 

At least this way you can get back the other files from DISK1 while you try to figure out how to reclaim the deleted files.

 

This is a good idea. Rebuilding the disk will also include the deleted files as long as they have not been overwritten.

First off lets get you started.

http://lime-technology.com/forum/index.php?topic=9880.0

I just reviewed the procedure you followed and rebuilding the disk will have no effect. The result of the rebuild will be identical to the disk you have: unformatted.

 

Follow the instructions in kiser's post and you will get more help.

I suppose the message or lack of is - no syslog no help.

 

Ok, the attached syslog is extracted from the fourth boot after the unfortunate incident.  If it helps, I got nothing to lose...

 

Marcusone, I thought your recommendation was a great idea until another member said it most likely wouldn't work.

 

From what I understand, Unraid should be able to rebuild array from parity.  I did a parity check with 0 error just a couple days before the incident.  I'll try replacing disk1 and rebuild array if there's no other solution. Hmmm... I think it should work otherwise I would need to reevaluate Unraid.

 

If I had known, everything in Disk1 might get lost, I could have live with the lost of one folder with its 10s GB data. Well...

 

Thanks to all who contributed to this thread.

 

Regards,

syslog-2011-03-09.txt

I believe you need to format the disk using the interface and then follow these instructions to repair the file system again. Make sure you get the right disk - Disk 1 is /dev/md1.

 

http://www.lime-technology.com/wiki/index.php?title=Check_Disk_Filesystems

 

If your PC is crash prone then don't use it for these checks or don't be doing whatever caused the crash again...

 

Peter

Hmmm... I think it should work otherwise I would need to reevaluate Unraid.

 

I don't believe anything that has happened here is the fault of unraid.  Good luck.

From what I understand, Unraid should be able to rebuild array from parity.  I did a parity check with 0 error just a couple days before the incident.  I'll try replacing disk1 and rebuild array if there's no other solution. Hmmm... I think it should work otherwise I would need to reevaluate Unraid.

 

Whatever was written by the failed reiserfsck to /dev/md1 was also reflected in parity in real time. The abrupt stopping of the reiserfsck due to the crash is what has caused the problem, not unRAID. The instructions were clear that you should have a backup of the existing data before proceeding.

I know. My current situation clearly shown I should have made a backup.  The question now is what can I do salvage the situation. Any suggestion besides not following the instruction to backup?

 

Thanks anyway.

I know. My current situation clearly shown I should have made a backup.  The question now is what can I do salvage the situation. Any suggestion besides not following the instruction to backup?

 

Thanks anyway.

The only solution will be by the use of reiserfsck to repair the file system.  the complication is it no longer "mounts" (and is therefore showing as unformatted because your PC crashed in the middle and terminated the file system repair abruptly.

Don't give up. I believe your chances of recovering a large percentage of your data are still good. You will need to run Reiserfsck, which I know is not your favorite tool right now, but it is your only option.

 

Rebuilding your disk would result in an exact copy of the disk in its current state. Parity is maintained in real time and does not have a "roll back the clock" feature. An exact copy would only help you to get back to where you are right now, which might not be that helpful since the next steps are pretty clear. It's not like you have 2 options, and if option 1 doesn't work you'd like to go back and try option 2.

 

You should click on the Best of the Forums link and search for "Data Recovery Experience" and read about a similar nightmare I had in my early days of unRaid usage. It also explains in detail how to run Reiserfsck to rebuild the RFS format.

 

Make sure you run it from the unRaid console!

I noticed the failure to mount error message too. I suppose disk1 too FUBAR to mount properly.  I rebooted server constantly hoping the disk will miraculously mount itself.

 

I was afraid of parity being real time. It makes sense since parity is updated whenever files are added or deleted.  I'll try running Reiserfsck command again.

 

Let me be clear what I need to do:

 

1. Follow instructions in http://lime-technology.com/forum/index.php?action=printpage;topic=619.0

 

2. Specifically run the "reiserfsck  --rebuild-tree --scan-whole-partition  /dev/md1" command. Right?

 

3. Do I need to format the disk? Doesn't sound try so better confirm

 

4 Run telnet from a Mac which is infinitely more stable or from console

 

5. Don't rush the recovery process or do anything stupid

 

Thank you all.

 

Regards,

 

Let me be clear what I need to do:

 

4 Run telnet from a Mac which is infinitely more stable or from console

 

5. Don't rush the recovery process or do anything stupid

 

I think the instructions were to run from your UnRAID server, not from a telnet session... the telnet session is half the reason you're where you are now.  So #4 is simply "from console"

 

I noticed the failure to mount error message too. I suppose disk1 too FUBAR to mount properly.  I rebooted server constantly hoping the disk will miraculously mount itself.

 

I was afraid of parity being real time. It makes sense since parity is updated whenever files are added or deleted.  I'll try running Reiserfsck command again.

 

Let me be clear what I need to do:

 

1. Follow instructions in http://lime-technology.com/forum/index.php?action=printpage;topic=619.0

 

2. Specifically run the "reiserfsck  --rebuild-tree --scan-whole-partition  /dev/md1" command. Right?

The first thing is to run

reiserfsck --check /dev/md1

and let it tell you what needs to be run next.   You prior interrupted reiserfsck command left the file system in some un-determined state.  Before you can rebuild the file tree you need to resolve other problems it may detect.

 

You'll probably need to run "--fix-fixable" first, but again, only if that is what the --check suggests next.  Each time you run reiserfsck it will tell you want is needed next.

3. Do I need to format the disk? Doesn't sound try so better confirm

No... DO NOT format the disk.  Not at this point.

4 Run telnet from a Mac which is infinitely more stable or from console

The console is best, but harder to document output of commands since cut/paste is not available.  Just do not let the MAC go to sleep or disconnect.  The reiserfsck to scan the entire disk will run for 5 or 6 hours at the very least for a large disk.

5. Don't rush the recovery process or do anything stupid

Good advice to anybody.

Look at this thread for instructions on how to reconstruct your drive format with reiserfsck.  I think this is more relevant than the how to recover deleted files wiki.

 

Data Recovery Experience

Look at this thread for instructions on how to reconstruct your drive format with reiserfsck.  I think this is more relevant than the how to recover deleted files wiki.

 

Data Recovery Experience

Initially relevant yes, but he did delete all his files and will need to rebuild the file-tree scanning the entire drive once he gets it back to a sane state where it can be mounted.

 

Joe L.

Look at this thread for instructions on how to reconstruct your drive format with reiserfsck.  I think this is more relevant than the how to recover deleted files wiki.

 

Data Recovery Experience

Initially relevant yes, but he did delete all his files and will need to rebuild the file-tree scanning the entire drive once he gets it back to a sane state where it can be mounted.

 

Joe L.

 

The instructions in that thread include doing that as well!

Ran "df", couldn't see disk1. PANIC!!!! Of course, it wasn't mounted.

 

Calmed down and started "reiserfsck --check /dev/md1"

 

Wait a minute - I'm not running from console. Once bitten should be twice shy. well, I've physical disability so carrying the "production" server to the screen is out of the question. Can't risk getting hurt otherwise I might get stuck at home for god knows how long. So, took the chance with necessary precautions. Perhaps I should shop for a small used screen.

 

I pre clear from the Mac so I know it should be good for running reiserfsck for 30+ hours, if necessary. Double check energy saving preference and Mac plugged into UPS. Hmmm... I better go disable energy saving from battery too.

 

For now I'm keeping fingers crossed.

 

Will update progress later.

 

Thanks all especially Joe!

Should be fine from a Mac. I keep mine up for weeks between reboots.

Hey, I' back.

 

This is the result I got from reiserfsck:

 

reiserfsck --check started at Thu Mar 10 15:19:49 2011

###########

Replaying journal: Done.

Reiserfs journal '/dev/md1' in blocks [18..8211]: 0 transactions replayed

Checking internal tree.. 

 

Bad root block 0. (--rebuild-tree did not complete)

 

Aborted

 

 

I didn't abort anything. It seems the process abort itself.  Running same command again yield same result.  reiserfsck didn't state next action.

 

What should I do next?  Please provide the full command if there's another command I need to run.

 

Oh dear, it's not looking good...

 

Thanks again.

 

Hey, I' back.

 

This is the result I got from reiserfsck:

 

reiserfsck --check started at Thu Mar 10 15:19:49 2011

###########

Replaying journal: Done.

Reiserfs journal '/dev/md1' in blocks [18..8211]: 0 transactions replayed

Checking internal tree.. 

 

Bad root block 0. (--rebuild-tree did not complete)

 

Aborted

 

 

I didn't abort anything. It seems the process abort itself.  Running same command again yield same result.  reiserfsck didn't state next action.

 

What should I do next?  Please provide the full command if there's another command I need to run.

 

Oh dear, it's not looking good...

 

Thanks again.

 

Yes, you did abort the rebuild-tree when the PC you were using disconnected.

 

Simply re-run the --rebuild-tree again.

 

Joe L.

Should be fine from a Mac. I keep mine up for weeks between reboots.

 

I find it odd that a Windows machine is considered so crash prone. I only reboot my W7 computer for updates, otherwise it is either just put to sleep or left running. And, I will often hold-off on installing updates so I don't have to rebooting it. I can't recall that machine ever crashing in the 1.25 years I've been using it.

 

Peter

Wouldn't running these commands in a 'screen' session work well in this case?  This is how I preclear my drives from my laptop since I am always putting it to sleep and taking it to work.