I'm moving from a 9 disk system to a 4 disk system, and while transferring files from a user share to one of the single new disks, two of the old drives started throwing reiserfs io errors and the unraid system hung and required a hard power down (ouch).

 

On restart, a parity check began and very shortly thereafter both disk3 and disk5 redballed. On a restart of the machine, disk3 dropped out completely and disk 5 was redballed.  I mounted the disks on an external enclosure and connected them to a Windows machine and used a ReiserFS GUI utility to see what was on those disks and, possibly, copy the data off. Well, disk5 ran over night and copied off a grand total of about 30GB and was making the familiar "bad sector read click" this morning. I printed out some of the file structure on both disks to see what was on there. Naturally, there are folders upon folders on both drives - some empty or nearly so - from the user share distribution of files.

 

Knowing what was on the drives, I re-installed them and restarted unRaid and brought the array on line in maintenance mode and ran Reiserfsck on both drives. Both fscks claim no corruptions found on either disk.

 

I've got lots of space in the array, as 3 of the 4 new 4TB drives are part of the array (in prep for copying the files over). Any suggestions on how to either bring the array back up in some fault-tolerant/fault-ignoring mode or how to copy the files off those disks with any file errors/failures piped to a log file?

Would it be possible to copy the files from the potentially damaged drives to my warm-spare drive (which is not in the array) by formatting that drive (it's already precleared) and using dd? More specifically, are there options which would allow dd to run, skip or ignore errors, and write any errors encountered to a logfile? something like:

 

dd if=/dev/md3 of=/dev/sdx/disk3.img conv=noerror,sync

 

and would there be any record of the errors encountered (and skipped) that would even be useful in determining which files might be corrupt?

 

edit: Not trusting myself with linux, I'm currently using a synchronization program to copy whatever I can onto one of the new 4TB drives in the array.

 

edit2: weirdness continues. Wife "may have" accidentally hit the surge protector reset button while vacuuming...or the server may have spontaneously rebooted. The result: the 10% of disk 5 that was copied to an empty drive is now the *only* think on disk 5. I guess I'll reboot later and see if anything magically re-appears. disk 3 is now being backed up, and the vacuum cleaner is safely on another floor. At this point I think I'm just to posting to "cry on your shoulders" as I take what I can get. The good news (if there is some) is that all the non-replaceable data is verified to have been backed up 12 hours prior to mayhem occurring, and I'm pretty certain that anything I did yesterday was saved to non-crashed disks.

 

You cannot use the 'dd' program to copy files in the way you describe. Using a file synchronisation program is probably as good an approach as any.

 

One thing you must make sure is that you do not mix user shares and disk shares when copying data (i.e. source and target must either both be disk shares or both be user shares).  Mixing them will almost certainly lead to data loss.

That's a good point. I was using MC to copy from a user share to a single disk when the shit hit the fan. It may not have been the issue since the disc to which I was copying was excluded from the shares. MC didn't really get me the speed boost I'd hoped because I didn't turn off parity beforehand and the machine was (I presume) parity calc bound. The reason from copying from the share, fwiw, was that I'm going to segregate all my data so that movies are on one drive, tv shows/other consumer media are on a second, and everything else is on a third, since HD capacities have finally caught up with my library size.

 

I'll use syncback to do the rest - and only from disk to disk - it's quite robust when used properly, even if the network round trip means a net speed of about 15MB/s

... It may not have been the issue since the disc to which I was copying was excluded from the shares.

 

It doesn't matter if the disc was excluded from the share.  If the destination had the same top-level folder name as the share, then this IS what creates the "user share" copy problem ... and can result in all of the copied files being truncated to zero length (i.e. complete data loss).

 

 

I'll use syncback to do the rest - and only from disk to disk - it's quite robust when used properly, even if the network round trip means a net speed of about 15MB/s

 

Your net speed shouldn't be degraded at all ... or at least not nearly that much.  A Gb network can support duplex transfers far above the 30-40MB/s that your system can write data at.    The fact is that with parity enabled, there's virtually no difference between copying between disks locally (using Linux commands) or doing it across the network (using whatever you want on a PC ... e.g. SyncBack).

 

 

... Personally, however, I'd just reload the new 4-disk array from your backups instead of trying to move all the data around from the old drives.    But if you don't have your data backed up, there's not much you can do except copy what you can access -- with two failed drives, there's no way to rebuild anything, so whatever's lost is simply lost.

 

Thanks, Gary.

 

I'm about ready to do that - just blow away the array, restore the critical files from backup, and then use the offline ReiserFS to copy over everything else (unbacked up content) from the individual disks back to the new server.

 

It means being down for several days, but at this point it's not looking good for getting things back to an even keel (disk5 now shows green, but I don't trust it).  And, to top it off, the server just decided to disconnect itself from the network - no Samba shares, no web access, no telnet. But the terminal is still open and working. I looked at the system log and there are no entries for the last 3 hours. If I unplug and replug the network cable, the log shows the link going down and coming back up. Grrrrr....

System up, parity calculated and being verified, backups copying (everything but movie/tv media).

 

One last question...is there anything non-obvious that would preclude me from mounting the *known good* old drives (which are still installed) and simply cp the movie/tv media (unbacked up stuff) data over? There is no overlap between the backups and un-backed up files - they're in a different top-level folder - and user shares are turned off until I can get all the data back and re-organized on the new server. I have successfully test-mounted one of the old drives, and can't see a problem with a straight cp command to a new folder, but better to ask first.

 

 

That should be fine.

 

The only thing that sometimes bites is that if you are logged in as root and run cp commands the permissions (owner) of files might be changed to root which will mess up access via the network shares.  The answer is to use the -p option on the 'cp' command to preserve owner/permissions, or run the 'newperms' script against the copy target location after doing the copy.

Thanks! Yup, I would have been caught with that and probably wondered what happened.

 

You could also attach the drives to a Windows box; install the free Linux Reader [ http://www.diskinternals.com/linux-reader/ ];  and copy them from there to your array.

 

Copy speed would be the same, since the limitation is the write speed on UnRAID ... not the network.

 

Just depends on which you find most convenient.

 

Yes, and I've started that with one drive before realizing that I could just cp. However, on my Win7 box the LinuxInternals application steals the focus of the system cursor for 3-4 second every 1-2 minutes, so I can't do day-job work at the same time the application is copying files without going batty. It sure beats the interface of the YAReG reader I used a couple of years ago to get a couple of files off of an old drive, though! I may try it on another machine, but I'm running out of "spare" machines that are otherwise idle!

 

 

Yes, and I've started that with one drive before realizing that I could just cp. However, on my Win7 box the LinuxInternals application steals the focus of the system cursor for 3-4 second every 1-2 minutes, so I can't do day-job work at the same time the application is copying files without going batty. It sure beats the interface of the YAReG reader I used a couple of years ago to get a couple of files off of an old drive, though! I may try it on another machine, but I'm running out of "spare" machines that are otherwise idle!

You should be able to get around that by applying the Remote Desktop patcher ( info here https://www.raymond.cc/blog/enable-remote-desktop-connection-in-windows-7-home-premium/ ) that allows multiple users to be logged into a Windows 7 box at the same time.  Then just RDP into the box (could be the box you currently are using I.E. RDPing to itself) and run it from there.  Then you won't have it stealing focus on you.

 

I will confirm this theory of mine tonight and get back home just have to install it on my laptop and do the "hack patch" on it since it is Home Premium.

 

 

Scratch that theory I tried it on my HTPC which already has the modification and even when using different user ID's it didn't work.  Does work great with a console open to watch videos and then RDP in from a different PC (specifically my laptop) to administer it.

 

 

I did find a way to achieve it with what I call RDP chaining.  RDP into another box and setup a RDP session from that remote session back to your original PC.  I did the following:

 

 

Had three computers (laptop, MediaCenter, HDServer) involved in the following connection:

Laptop to MediaCenter,  MediaCenter to HDServer, HDServer back to MediaCenter.  So it would work MediaCenter to HDServer back to MediaCenter.  The second PC could then be another desktop being used for something else by someone else even if the RDP patcher has been run on both PCs.  Then you have two different sessions on your PC to avoid the focus stealing.  Allot more complicated that you probably would want to do but was an interesting experiment for me.