Manual disk1 to disk2 copy. What did I do wrong?

[Jimmeh]

Hi guys, I'm hoping its possible to get out of this corner I've backed myself into, but I'm not particularly hopeful

 

I'll try to give you a bit of background.

 

I have a 4 disk array using the latest version 5 beta:

 

1x 2TB Parity

2x 2TB Data Disks

1x 200GB Cache

 

I setup the array initially with only 1 2TB data disk, configured the shares, and copied my data across. Once this had completed, I added the second 2TB drive, enabled the parity disk, and ran a full parity check which completed without errors.

 

Since all my data was on 1 drive, I wanted to move some of the data to the second disk, since my split levels kept the shares mostly together.

 

From the command line I used rsync (because I like the options) to copy the data from /mnt/disk1/movies to /mnt/disk2/movies, with a mind to deleting the original data on disk1 when the copy had completed. The rsync completed suceessfully and I varified a few of the files on disk2 were fine. I then ran the permissions fix to make sure everything was set correctly.

 

Happy that the data had been moved, I tried to run an rm -rf on the /mnt/disknt -l showed it was mounted rw. A bit confused, I stopped the array and rebooted via the web interface. After the reboot both my data drives are completely empty but mounted successfully in the array. My shares have been removed. Running ls on /mnt/disk1 and /mnt/disk2 show that there are no files or folders on them at all. The parity sync started automatically but I stopped it on the off chance I can salvage the situation.

 

So my questions are;

 

* What the hell could have happened to cause this, as far as I understood it I had shut down the array cleanly?

* Is is possible to recover the data using the parity which was completed before any file copy took place?

* If so how would I go about that?

 

If anyone can shed any light on this it would be greatly appreciated, even if only to confirm recovery is futile

 

Thanks for your time.

[Joe L.]

Parity does not protect you from deleting files.  It protects you from a single failed disk. 

 

you mention "/mnt/disknt"  Since that does not exist, it would be a directory created in memory only, not physically.

 

It sounds as if you copied your files to RAM, then when you rebooted, they were gone.

 

There is a procedure to recover files you deleted, and it has been used with some success.  It involved rebuilding the entire file-tree of the drive involved.

 

See the wiki for specifics: http://lime-technology.com/wiki/index.php?title=FAQ#How_can_I_undelete_files_from_an_unRAID_disk.3F

[Jimmeh]

Thanks for the advice, I'm running the rebuild-tree now so we'll see in a few days what I can get back. Seems to be going very slowly.

 

For future reference, how should I have gone about moving the files?

 

Edit: Looks like I've managed to recover the majority if not all of the data, so thank you very much for that.

 

I've seen reference to users manually copying files to a specific disk, rather than to a share and allowing split level to dictate it's location, which is basically what I was trying to do.

 

/mnt/disk1, /mnt/disk2, etc appear to be mount points for physical drives, so I'm trying to figure out why copying data from disk1 to disk2 could cause such a catastrophic failure after a reboot.

 

I am very keen to get a handle on my mistake so that I don't repeat it. Any insight would be appreciated.

[sacretagent]

use MC (midnight commander)

easy as hell and you see what it is doing

 

Just type MC in a telnet window