I can't believe this is happening!! So my disk1 got full 100% due to incorrect settings or whatever. So i manually moved some stuff around and moved my TV shows to disk 4 to free some space on disk1. Little while later my TV Shows folder showed empty, and then eventually disappeared completely. So all my seasons are gone. Then I started reading some posts for undelete, in case I messed up something, which i dont think I did. Accorging to this thread http://lime-technology.com/forum/index.php?topic=5087.msg47070#msg47070 I ran umount /dev/md1 and reiserfsck --rebuild-tree -S /dev/md1. It only ran for couple minutes and I stopped it. Then I rebooted my server as the drive didnt want to re-mount with this command mount /dev/md1 /mnt/disk1. After reboot my disk1 shows as unformatted and I am about to have a heart attack. 1Tb of movies and TV shows that I have been collecting for years are gone!! Please help if there is anything I can do to save my data! Why is disk1 showing unformatted after the reiserfsck --rebuild-tree -S /dev/md1. HELP HELP  :'( :'( :'( :'(

 

Since disk1 shows as unformatted now, if I format it would it get rebuilt from the parity? I feel that I'm really screwed and don't want to make things any worse.

UnRAID will show as unformatted if it cannot mount your drive, it does not mean the data is necessarily lost.  If you started reiserfsck --rebuild-tree then until it completes you will not normally be able to mount the drive which would explain what you are seeing.

I stopped the reiserfsck after 2 min. Should I start it again and let it finish?

 

I'm not sure about reiserfsck but if the other disks in the array are all green balled, it would be pretty simple to recover all data by letting parity rebuild it.

 

If the data was extremely critical, I would add a fresh new hard drive to the array and let the data be recreated on that one rather than risking rebuilding on a failing drive. That way you also preserve your original disk, and as long as you dont make any changes to any data on the array until you are up and running perfectly with the freshly rebuilt disk, you always have the option of retrying with the failed disk.

 

Please wait for someone more experienced to validate that the above cannot worsen your situation before trying it on my word.

I ran reiserfsck --rebuild-tree -S /dev/md1 again. It took few hours (overnight), but then i was able to mount disk1 again and all my movies were intact. Also there were some of my TV shows in the lost+found folder. Phew, i can breath now. I guess this is a lesson, dont ever run that command and cut it off before it finish . Thank you all for the responses.

I'm not sure about reiserfsck but if the other disks in the array are all green balled, it would be pretty simple to recover all data by letting parity rebuild it.

This is almost never correct. If a drive is online and you make changes to it, the changes are written both to the data drive and the parity drive. If the drive is red balled and you write changes to it, the changes are only written to the parity drive, and the physical red balled drive is unmodified. IF, and ONLY IF, the OP had a red balled drive that was really ok, and fubared the file system on the parity simulated drive, then he could run a new config and rebuild parity from his old data drive. I can't think of an instance where rebuilding from parity would result in data recovery.

 

Unraid is not a backup unless it's the second copy of your data. If you accidentally delete or otherwise clobber data on your unraid, don't expect parity to help you, that's not what it's for.

All my drives showed green ball, even though disk1 had "Unformatted" message. I'm glad the reiserfsck worked. Not sure if i had formatted disk1 that it would have been rebuilt from the parity. Lesson learnt.

All my drives showed green ball, even though disk1 had "Unformatted" message. I'm glad the reiserfsck worked. Not sure if i had formatted disk1 that it would have been rebuilt from the parity. Lesson learnt.

 

No need to not be sure about it. You 100% could not have rebuild and got a good fixed working drive once you ran the incomplete reiserfsck command on your original drive. You would have got back exactly what you had.

I'm not sure about reiserfsck but if the other disks in the array are all green balled, it would be pretty simple to recover all data by letting parity rebuild it.

This is almost never correct. If a drive is online and you make changes to it, the changes are written both to the data drive and the parity drive. If the drive is red balled and you write changes to it, the changes are only written to the parity drive, and the physical red balled drive is unmodified. IF, and ONLY IF, the OP had a red balled drive that was really ok, and fubared the file system on the parity simulated drive, then he could run a new config and rebuild parity from his old data drive. I can't think of an instance where rebuilding from parity would result in data recovery.

 

Ok, my understanding was thus:

 

1. I have a healthy working array

2. Suddenly a disk re-balled

3. Maybe later it said unformatted or just refused to show up in the drive list (bad sata cable, whatever)

4. At this stage I still have a working array but just that it isnt protected

5. So i drop in a new disk or allow unraid to format the unformatted disk, and just let it expand the array by rebuilding data that should have ideally been on the bad disk (a bit like upgrading an existing disk to a larger sized one), and we're back to square one

 

Which part of my understanding of unRAID is wrong here?

The OP did not get a red-balled drive. So, your understandings simply don't make any sense for this case.

 

If the disk was red-balled then it wouldn't get worse by having a bad cable or whatever because it's already removed from the array. Also, you won't get the option to format a red-balled drive.

 

I honestly don't know if a simulated drive could be written to in such a way that it appears as unformatted. I believe you could do something to cause that though.

 

unRAID has a real-time parity. If you screw with the data on any drive it is immediately reflected in the parity and you can't recover from what you did by simply rebuilding the disk.

 

In this case, the OP ran the reiserfsck command on the md1 device and then interrupted it part way through leaving the data on the disk damaged. The parity was updated for each change to the disk and any rebuilt disk will also be broken exactly the same way. During this whole affair the disk was never red-balled.

 

Once the disk is red-balled you can mess with the physical disk all you want without screwing up the array any further, but you wouldn't use use the /dev/mdx devices, you use /dev/sdx1 to access the partition directly.

 

Thanks for the lucid explanation. I was completely ignorant of the reiserfsck implications.