Hello,

 

I had a failed drive that showed up with the red icon.  So I used MC to copy all the files over from /mnt/disk3 to /mnt/user .

I stopped the array, I unassigned the drive and restarted the array

Once that finished I looked at the files I copied over and they are all 0 Byte files ALL OF THEM .

Is there any way to recover this data?

 

I haven't ran the New config command or anything yet?

 

I have stopped and started the array.  I'm assuming all is lost?

Not entirely clear what you did or what your current situation is.

 

Do you have a parity drive? Is drive3 the failing drive? Is the array running now without drive3 assigned?

 

/mnt/user is the mount point for the user shares, and not the user shares themselves. Not sure what unRAID would do with the files if you copied them to /mnt/user. Did you copy them or did you move them?

 

If you have parity then you should still be able to access the files. They would be simulated by using parity and the other drives to reconstruct the data. If you haven't messed things up then you should be able to rebuild to a new disk or maybe even to the old disk if we can determine that it is OK.

 

Post a screenshot.

 

Sorry.

 

Yes I do have a parity drive.

Drive 3 was the failing Drive.

 

Drive 3 is no longer assigned.

 

I followed the instructions here.

http://lime-technology.com/wiki/index.php/FAQ_remove_drive

 

1. I excluded Disk 3 from all of my shares.

2. Used MC to copy the folders from /mnt/disk3 to /mnt/user

3. I stopped and started the array

4. I looked at the files in /mnt/user that were copied from disk3 and they are ALL zero bytes in size

 

 

OK. Didn't realize that you had decided to remove the failing drive instead of rebuilding it.

 

I don't really understand that wiki article. It would make sense if you had enough room to copy them all to cache, and it would make sense to copy them to /mnt/user if you first set all user shares to exclude disk3, but it doesn't seem like it would really do anything if disk3 was still a possible destination for the copy which it would be if disk3 was still included in the user shares.

 

What are you seeing that makes you say that they are all zero bytes? What do you get with

ls -al /mnt/user

 

You should still be able to access the (simulated) data on drive 3 even though it is not assigned. Can you still see the files on disk3 in mc?

 

 

When I access /mnt/user I still see all the folders and files listed however when I go into any folder that I copied from /mnt/disk3 the files are all 0 bytes in size.

Would I have better luck trying to put in a replacement drive?

When I access /mnt/user I still see all the folders and files listed however when I go into any folder that I copied from /mnt/disk3 the files are all 0 bytes in size.

Would I have better luck trying to put in a replacement drive?

 

I am confused as to what you did. For the record, I do not recommend new users to enable user shares until their server is up and running and all data transferred. There have been lots of users confused by split levels and wind up copying files all over the place. I personally don't use user shares at all.

 

But no one has reported anything similar to this, and unfortunately I am not confident you are going to be able to recover easily if at all. But my experience in some bleak experiences is that data recovery is possible most of the time, so there is definitely hope.

 

First and most important advice. Don't do anything else until you have a strategy. When you do something bad, there is usually a right way to recover. Try doing it the wrong way and you can never go back, even if you discover what you should have done. Do no harm.

 

If you want help you need to post a lot of details about what you did and whAt you've done to try and fix the problem. 2 or 3 sentence posts are not going to cut it. To get you started ...

 

1. What were the symptoms leading you to believe disk3 was bad? Posting a picture of the unRaid management page would help. Smart report would also be helpful.

 

2. Can you confidently say the files showing zero length now were there and functioning before the MC copy?

 

3. When you used MC to copy the files, how long did it take? What option did you select?

 

4. Did you rebuild disk 3 on top of itself?

 

5. Post a syslog

 

Copying files to /mnt/user should not corrupt a disk, but as a non-user share user I can't say that it doesn't. But I believe this is just a container for the user shares and, if you copied files there, you would use up your root filesystem which is just a ramdisk. My guess is the server would crash as you consumed all memory.

 

I do not know what would happen if you copied files from an array disk to a user share, and the user share was trying to write the file right back to the same array disk. I could see a possible outcome of 0 length files. But I doubt it. We'd have seen it before. And Linux plays much nicer than Windows with these sorts of things, so I don't know for sure.

 

But if the files were attempted to be copied and they went to a near full cache drive, and created zero length files, the mover could try to move the zero length files and clobber the real ones. Wondering if something like this happened. I know you say you removed disk3 from the share but not totally trusting you did that correctly. Or there may be a bug. This is the closest thing to a rationalization of what happened I can come up with.

 

User shares combine files into a single logical share, so it is possible that two disks contain the same file. UnRaid would pick one and the other would be, in essence, hidden. So if we saw a zero length file we might still find the real file on a different disk. But your little screenshot is a directory from disk3 mount not the user share, so this it is not on disk3. You might look on other disks.

 

If the files are truly gone, but were there before, the only recovery option I can think of, and this is an extreme one, is to run Reiserfsck to recover deleted file or rebuild the drive tree. Been quite a while since I used it so you would need to research the options. Might create quite a mess to sort out but maybe it would be better than what you have now. If you want to do this. I would strongly recommend copying the disk (using dd not file copies) to a new disk, and run this on the copy. Because if this doesn't work it can leave you in worse shape and prevent you from trying something else.

 

Only other thought is finding the files on your workstation where you copied them from. I once deleted a recently added file and had luck finding the file in my Windows recycle bin.

 

Post back with your story and addressing my questions above and maybe me or someone else here can provide more guidance, but this is my brain dump for now. Best of luck!

 

 

 

Copying files from a disk share to a user share in effect causes the file to try and overwrite itself - thus resulting in the 0 byte files that you see.  You should have copied the files to another disk share to avoid this.

 

If you still have the original 'failed' disk then there is an excellent chance that the vast majority of the data is intact.  If that is the case then I suggest you report back here and get some suggestions on how to proceed.

Seems like he was led astray by a wiki article. Not good.

Seems like he was led astray by a wiki article. Not good.

Yeah but that wiki article states that is to be done on a working drive that you are removing, not one that redballed and you decide to remove.

How do I remove a hard disk that I do not plan on replacing?

 

There are a few reasons you'd want to do this: you want to repurpose the drive for some other reason, or the drive has failed or is failing.

First I'll go over repurposing a working drive.

 

The wiki article never covers what to do if the drve has already failed or is failing.

Seems like he was led astray by a wiki article. Not good.

Yeah but that wiki article states that is to be done on a working drive that you are removing, not one that redballed and you decide to remove.

How do I remove a hard disk that I do not plan on replacing?

 

There are a few reasons you'd want to do this: you want to repurpose the drive for some other reason, or the drive has failed or is failing.

First I'll go over repurposing a working drive.

 

The wiki article never covers what to do if the drve has already failed or is failing.

 

Nevertheless, it should say to copy to the disk shares and not user shares. Because exactly the same thing could happen with a perfectly fine disk.

 

It is unlikely but still possible that the physical disk still has good versions of the files.

 

That is the first place to check. I would put the array in maintenance mode and install it in the cache slot and have a look.

bjp999,

Sorry for the short answers in the previous postings I was in full panic mode.  If I start the array in maintenance mode and assign the 'failed' drive to cache slot, what do I then do to take a 'look' ?

 

 

1. What were the symptoms leading you to believe disk3 was bad? Posting a picture of the unRaid management page would help. Smart report would also be helpful.

 

The drive showed up with the red ball next to it.

 

2. Can you confidently say the files showing zero length now were there and functioning before the MC copy?

 

Yes the files were there and functioning.  I can confidently say that because I was viewing pictures the other day that are now 0 byte in size

 

3. When you used MC to copy the files, how long did it take? What option did you select?

It took a couple of hours to transfer, unfortunately I do not have a screen shot of the options I selected.

 

4. Did you rebuild disk 3 on top of itself?

Not exactly sure what is meant by this??  I excluded disk 3 from all user shares

 

 

 

itimpi ,

I do still have the drive that was 'failed'  , could you point me on how to proceed.

 

 

 

 

Here is another screen shot of some 0 byte files

The red ball is a beautiful thing for you at this point.

 

What that means is unRaid kicked the drive out of the array and went into a mode where it simulated disk3. So any updates made to disk 3 were made to the simulated disk and not to the real disk.

 

If you mount the real drive 3 in the cache slot, it should be available at /mnt/cache, or over the network as //tower/cache.

 

If all you say is true, that disk should be exactly the way if was before it red balled.

 

It is possible the drive really failed, but red balls are more typical of loose cables then drive failures.

 

You could then copy its contents to a DISK share (e.g., disk4).

 

Let's stop there for now, and I can advise you further.

 

Update: Can someone confirm maintenance mode disables the mover script? If not elm, hold off. We need to disable it before starting the array with disk3 in the cache slot.

Hey Turns out the drive itself isn't bad.  It was a bad SATA cable all along.

 

1. Changed the SATA Cable

2. Assigned the drive to the cache drive just in case.

3. Moved data from the drive to another disk

 

 

Thanks for all the help, and sorry about the panic! 

Very happy for you. That was a close one.

 

You still have the red ball? You know how to recover?