[Solved] [6.5.3] Moving user shares off a failing disk

[Boyturtle]

I have a 5tb WD Red drive on the array that is failing and needs to be returned to the manufacturer for a replacement under warranty. It contains a total of 2.5tb of data, which is too big to move to the other 5tb Red that already contains 2.6tb of data. So while waiting for the disk to come back from WD, I need to get another disk to copy the data across to. Because WD Red 5tb are end of life now and no longer carry the full 3 year warranty that I need, I will most likely be getting a 4tb Red, so I won't be able to just replace the disk into the array for the faulty device and rebuild it from parity. Consequently, I'm going to have to copy the data across to the new disk and I just want to make sure that I go about doing this in the most efficient and data resilient way, so that I don't break my server or lose my data. My parity drive is 6tb btw. My plan is as follows:

• Preclear 4tb disk and then add it to the array (it will now become disk3)
• I need to find a way to stop data being written to the faulty drive while I am copying stuff off of it, would excluding all the user shares from writing to disk2 be sufficient or would I need to do something else?
• Use krusader to copy the content of the disk share from the faulty drive to the new drive (from /unraid/disk2 to /unraid/disk3) 
• Alternatively, use the copy command in terminal (cp -vRap /mnt/disk2 /mnt/disk3)- I feel this to be more robust.
• Delete the contents of disk2
• Delete the faulty drive from the array
• Power down server and remove faulty drive.
• When the replacement drive arrives from WD, preclear it and add it to the array as an altogether new disk.

Would the above work? In moving the contents of the disk shares from disk2 to disk3, will unraid still map and link to the shared folders and keep adding to them as if they were on disk2, or is there some other change I need to make?

Edited May 31, 2019 by Boyturtle

[Boyturtle]

Anybody?

[Jcloud]

Why not pre-clear the 4TB disk (or not); remove the faulting 5TB drive - this puts the array into "error" and emulates the contents of 5TB drive; then add the 4TB drive into place of missing drive in the array and then the array rebuilds the data from parity. 

 

This would keep all of your data and your user shares would remain untouched.

[itimpi]

1 minute ago, Jcloud said:

Why not pre-clear the 4TB disk (or not); remove the faulting 5TB drive - this puts the array into "error" and emulates the contents of 5TB drive; then add the 4TB drive into place of missing drive in the array and then the array rebuilds the data from parity. 

 

This would keep all of your data and your user shares would remain untouched.

This will not work!    You cannot rebuild onto a drive that is smaller than the one it is replacing.    Th

[Boyturtle]

My understanding is that it will not work, which is why I'm looking at alternative ways of doing this. Will the process I outlined above work? My main concern is that unraid will not be able to find the user share if I've moved them to another disk.

[Jcloud]

1 minute ago, itimpi said:

This will not work!    You cannot rebuild onto a drive that is smaller than the one it is replacing.  

My bad, I was thinking it would because the parity is larger, but I guess there's some zero's being calculated. 

Sorry for the bad information - my head is dropped down in shame.

 

[itimpi]

Just now, Jcloud said:

My bad, I was thinking it would because the parity is larger, but I guess there's some zero's being calculated. 

Sorry for the bad information - my head is dropped down in shame.

 

It makes more sense when you realise that parity has no concept of data or files - just of sectors.    The rebuild process just restores sectors on the rebuilt disk to their expected value.    The fact this restores the data is just a by-product of the sectors being restored.    The reason you can also use a larger disk is that at the end of the rebuild process it is easy to expand the file system on the rebuilt disk to use the extra space.    Unfortunately shrinking a file system is a non-trivial process and is not supported.

[remotevisitor]

Adding the failing disk to the exclude list for being in a share (there is a global setting for this, as well as per share settings) will prevent new files from being written to that disk.  But unfortunately it will not prevent writes to files that already exist on the disk.

 

I have a feeling your cp command will create a top level folder (and therefore a data share) called disk2 on disk3 .... this share will then hide the disk share called disk2.   I think your cp command should be using /mnt/disk2/*

Edited October 30, 2018 by remotevisitor