When I built my new server back in December, I was planning to buy all new drives. But I got ahead of myself. Put all my old drives in to check out the performance of it. Then just thought I've already set it all up, and that was that. My first build was back in 2012 I think? So I've had these 3TB HDDs for awhile now.

Since then, I've had four drives the orange triangle pre warning. But I've not really been in a position to buy any new HDDs these past couple of months. And now a drive just failed on me.

I'm almost out of data too. So I need to purchase another HDD, and it make sense now to replace all of the failing drives along with the failed drive.

My parity is one of the failing drives.

A data disc was the one that failed.

When I replace these drives, what's the best way to do it? Obviously replace the failed drive first. Then would you suggest replacing the parity drive? Then the other failing drives one by one?

First time I've had to replace a failed drive, so I'm not wanting to mess this up.

 

Parity: Reported uncorrect: 1

Data 1(failed drive): Reallocated Sector Count: 1224, reported uncorrect: 2310, Command Timeout: 5

Data 2: Fine

Data 3: Reallocated sector count: 2152, reported uncorrect: 200, currect pending sector 8, Offline Uncorrectable: 8

Data 4: Reported Uncorrect: 23

Data 6: Fine

Data 7: Fine

 

It looks like Data 3 is probably on it's last legs now. Which order would you replace them?

Going to turn my server off now until I can get these HDDs delivered.

If I were you, I would do this:

• Buy a 2nd USB, get unRAID 6.2 beta license.
  
• Record / take screenshot / be 100% sure the slot of each of the old drives (just in case) - then unplug all of them to reduce any chance of further data loss
  
• Plug the new drives in and boot using the 2nd USB
  
• Run preclear on all the new drives to be sure they are not faulty
  
• Add the new drives to array and format them - no need a parity disk for now
  
• Plug in the old disks, one-by-one, mount using Unassigned Devices (xfs partition should mount pretty straight-forward - that's the beauty of unRAID, each data disk is a disk on its own) and manually copy over data from each old disk to the array
  
• Verify that copying is done correctly and there's no further SMART error or issue etc.
  
• Boot back into the old USB unRAID stick with the old license (and new drives), start a new config, add parity drive, build parity. Done.
  

The above might be a little long-winded but I tried to add (perhaps excessive) safeguards along the way (e.g. using a 2nd USB stick with beta license to protect against accidentally messing up your existing config). By manually copying data from each disk, you (hopefully) can at least recover SOME data on the failed drives.

 

PS: don't do anything yet. Wait for the experts here to provide their recommendations. 

If disk3 is as bad as it looks you won't be able to rebuild the failed disk without getting some corrupted files, you can still try it but would be good to have complete checksums so you could verify the rebuild.

You can't replace disk1 with a drive bigger than your parity drive. So... if you want the data that's currently accessible on disk1, you don't have too many options.

 

How much of your array is backed up elsewhere?

 

What size drives were you planning on getting?

 

If you don't have the contents of disk1 backed up, can you scrape together enough free space to back it up from the emulated copy?

 

I'm afraid you are going to lose the contents of disk1 and 3.

They're all 3TB Seagates and I'm planning to replace them with 3TB WD reds. I could probably just about a back up from the emulated drive, got enough PCs and HDDs to scatter the 3TB across multiple drives.

 

None of it is backed up elsewhere. I've nothing massively important on there. It's being used as a media server so I can get the content back. It'd just take awhile.

Quick update. My server currently has 6x3TB HDDs + 1x3TB parity.

Initially I was thinking about getting 10x3TBs this month. Then I wouldn't need to think about expanding it again. But the 6TBs aren't that much more than 2x3TBs. So I guess it'd make sense to do that, and I've still room for another 5 HDDs then.

Anyway. I'm also going to replace the cache, with a large SSD. I've got a 1TB in my PC which I will be upgrading soon anyway, so it just makes sense to throw it in the server now.

So, new cache, new drives. I'd have to set everything back up again. I've figured this is going to make more sense just to start Unraid from scratch.

 

So, I don't believe Windows can read reiserfs? Unless anyone can correct me on that. So I think I'm going to put Ubuntu or something on a laptop, use a HDD dock, and just copy the data back over once I've set the HDDs up (not got them yet, payday tomorrow so I'm doing it then). Is this possible? Pull all HDDs from Unraid, throw it in a HDD dock along with Ubuntu and copy it all back to the pool?

 

Still not sorted this HDD out yet. I've had the server turned off since this drive failed on me. Need to do that some point soon. Unsure on whether to throw a 3TB in and let it rebuild. Or copy all the data across from the pool to other HDDs.

 

So, I don't believe Windows can read reiserfs?

Not without additional software.  ReiserFS is a dead end.  After you get your problems sorted out, switch over to XFS

It seems that I lied...

I presumed Unraid was still only RFS.

I've just gone on my server, and underneath 'Main', it tells me FS (I presume File System), and they're all XFS.

Is this any different though? XFS is a Linix file system right? So will I still have problems reading them with Windows. Or, will the same apply. Download Ubuntu to a PC/Laptop and then I can mount each individual drive and transfer the files back on to the server over the network?

You would still at least have to install software to read the disks, but at least that software would be current and not 10 years old

 

Sent from my LG-D852 using Tapatalk

 

 

AFAIK there's no software to read XFS on windows, there is for reiser, for XFS you can use for example a live ubuntu flash drive.

Just found this one for windows that reports to read XFS drives: http://www.pavitrasoft.com/crossmeta.html  Have no clue if it really works or not however.

 

 

Here is another one that sounds better to me if it really doesn't install a driver to read the disks: http://nadrin.github.io/fsproxy/wikka8979.html?wakka=HomePage&show_comments=1

Just found this one for windows that reports to read XFS drives: http://www.pavitrasoft.com/crossmeta.html  Have no clue if it really works or not however.

 

 

Here is another one that sounds better to me if it really doesn't install a driver to read the disks: http://nadrin.github.io/fsproxy/wikka8979.html?wakka=HomePage&show_comments=1

I guess something is better than nothing, but for the crossmeta stuff, no 64 bit windows support. Really? Looks like a dead end there.

 

The fsproxy thing looks pretty nifty, I like how they use a linux base, too bad it doesn't look like it's been kept up to date.

 

With either option, I'd be scared to use it on data that is at risk. Much better to use a live linux boot media that at least is marginally up to date and should have needed file system patches applied.

 

IMHO, if you are trusting your data to a linux based server, you would be much better off using linux based recovery tools if you get in a jam rather than trying to force a recovery in windows. There are lots of good recovery centric tools available for linux, much better than windows stuff. So much so that I use ddrescue and testdisk to deal with dodgy windows disks.

Maybe I missed something, but why are we talking about mounting the drives on another system instead of using Unassigned Devices?

Maybe I missed something, but why are we talking about mounting the drives on another system instead of using Unassigned Devices?

Internet tangents run amok.

 

The OP still has a running server with only 1 fully failed drive. OP isn't really screaming about losing data, seems pretty sanguine about it. Hasn't technically lost data yet, but will soon if he doesn't tread carefully. Failed drive was still emulated successfully as of last boot, so full recovery should be possible, especially if he buys new drives that can be mounted in the server along with the existing drives.

 

Assuming OP wants to buy 2 new 6TB drives, my plan would be...

 

Test new drives with preclear or other means

Mount a new 6TB hard drive with UD

Copy the emulated contents of the failed drive and the contents of the suspect drive to the new drive,

Set up a new config with a second 6TB drive as drive 1 and all the remaining good drives as data (no parity yet)

Copy the UD mounted drive to new 6TB drive 1

Add UD 6TB as parity.

 

End result, 3TB added free space (old parity repurposed as data), and 6TB parity in place for next planned drive replacement.

First, assuming you want to at least TRY to recover the data from the failed drive; I'd replace the failed drive with a new 3TB drive (WD Reds are a good choice) and initiate the rebuild.

 

Assuming that completes successfully, you then have a couple of choices ...

 

(1)  Replace your parity drive with a new, larger drive (e.g. a 6TB WD Red); and then replace your next-most-likely-to-fail drive (#3) with another 6TB Red.    If those both rebuild okay, you're pretty much home free.    I'd then replace one more drive (#4) with another 6TB Red, and you'll then have all of your failing drives out of the system, and a good bit of extra space.

 

or

 

(2)  Instead of rebuilding any other drives after you've replaced the failed one, you could do an entirely new config with 3 6TB Reds (one as parity) plus the new 3TB drive you used to rebuild #1, and the drives that aren't giving you any issues (#2, 6, & 7).  This would give you 12TB of available space in the array.    You could then, using the Unassigned Devices plugin, copy the data from drives 3 and 4 to the array, and you'd still have 6TB of additional free space.

 

I prefer approach #1, since you don't lose the ability to at least try a rebuild in case any of the not-yet-failed-but-clearly-failing drives happen to fail;  but #2 will put a bit less stress on those drives, since they won't be used except for copying the data from them, so it's up to you.

 

 

One last question. I had a spare 3TB drive around. And I've managed to copy all the data from the failed drive.

I've bought 7 new 4TB drives which are due tomorrow.

My intentions are to pull all the drives out, put the new drives, put the new cache in, and start from scratch.

 

I just want to be 100% sure, that if I install Ubuntu on a PC, I will be able to put my HDDs in a dock, and then copy all my data from them, to my new array.

Why not just use Unassigned Devices plugin to copy them directly on your unRAID server instead of getting another computer and the network involved?

I've bought bigger drives than the ones that are in already.

I'd have to replace the parity drive before I could replace the failed drive, and because I'm adding a new cache/appdata I've figured easiest way to do this is to start again.

I just want to make sure pulling a drive from unRaid, sticking it in a HDD dock using Ubuntu on another PC and copying everything back will work.

 

I guess other ways might have made sense, replace with a new HDD and rebuild, but my parity is failing, and I've got another HDD which has worse stats than the one that has failed.

If you install the Unassigned Devices plugin.  You can still have all of your new drives in your array all by themselves alone.  It allows you to MOUNT each old drive individually for access directly on unRAID.  I do this and use MidnightCommander (MC) which is built in to unRAID to copy my data from the Unassigned Devices mounted drive to my array.  There are also Dockers that give you a GUI rather than a text based UI like MC if you want to use them instead.

 

 

Really think you need to read about Unassigned Devices here: http://lime-technology.com/forum/index.php?topic=45807.0

What you are proposing should work fine, but what everyone is trying to tell you is that as long as you have the physical space, license and connections to keep all the drives both old and new attached to the server, it would be quicker to define the new array with only the new drives, and copy from the old array drives to the new array drives faster and with less hassle using the UD plugin and either console commands or one of the file manager type dockers. Just because the drive is still physically in the tower doesn't mean it has to be assigned to the array.

 

TLDR: Yes, you can mount array drives in a linux PC and read the contents.

What you are proposing should work fine, but what everyone is trying to tell you is that as long as you have the physical space, license and connections to keep all the drives both old and new attached to the server, it would be quicker to define the new array with only the new drives, and copy from the old array drives to the new array drives faster and with less hassle using the UD plugin and either console commands or one of the file manager type dockers. Just because the drive is still physically in the tower doesn't mean it has to be assigned to the array.

And it doesn't have to actually be in the server. It can be in a USB dock and connected that way. And since you can do this one disk at a time you only need a single USB port and a license that allows you to have one drive more than you would have anyway.

 

See the link BobPhoenix posted. I use Unassigned Devices all the time to create backups of my critical user shares on a drive outside my case and then take that backup offsite. You can use Unassigned Devices to copy files from a disk outside your case in a similar fashion. No need to get another computer booted up into some other OS just so you can read drives in a USB dock, and then copy those files across the network to your server.