how do i rebuild a disk from parity?

[spl147]

so i precleared a new disk, then i used mc to MOVE the data from the old disk to the new disk, so the data was deleted from the old disk. i then swapped the old for new, when i started the array parity started a rebuild, so i clicked cancel quick, now the new disk cannot be mounted and data is gone!

 

is it possible to force a parity rebuild of a specific disk from the command line?

[tdallen]

I wouldn't do anything at all until we get a better idea what is going on here.  No rebuilds, formats, syncs, etc.

 

Can you lay out what you did, and the order you did it in?  You should also post a diagnostics (Tools->Diagnostics).

 

Is your data backed up?  Do you see the data from the old disk on the array (I assume not, but asking anyway...)?

[spl147]

12 minutes ago, tdallen said:

I wouldn't do anything at all until we get a better idea what is going on here.  No rebuilds, formats, syncs, etc.

 

Can you lay out what you did, and the order you did it in?  You should also post a diagnostics (Tools->Diagnostics).

 

Is your data backed up?  Do you see the data from the old disk on the array (I assume not, but asking anyway...)?

explination above is the order i did it in.

 

it's on the parity drive, thats why im trying to figure out how to force a rebuild of the replaced drive

 

the old drive is empty as explained above!

[tdallen]

Parity is *not* a backup.  If you "moved" the data off the old disk while it was part of the array, then you moved it off of parity as well.  There were more steps that you followed than what you listed above - in order to begin using the new disk you either added it to the array or mounted it using unAssigned Devices.  Then, when you swapped it, what did you do?  Just swap cables, or assign the disk to the slot in unRAID?  Details matter at this point.

 

Is your data backed up?

[spl147]

1 minute ago, tdallen said:

Parity is *not* a backup.  If you "moved" the data off the old disk while it was part of the array, then you moved it off of parity as well.  There were more steps that you followed than what you listed above - in order to begin using the new disk you either added it to the array or mounted it using unAssigned Devices.  Then, when you swapped it, what did you do?  Just swap cables, or assign the disk to the slot in unRAID?  Details matter at this point.

 

Is your data backed up?

new drive was put in a empty slot, cleared, then i used mc to move the old disk to the new disk while the old disk was part of the array, the new disk was assigned using unassigned devices, after all was moved the old disk was empty, i then removed the old disk and put the new disk in it's slot, i assigned it to the array, then started the array, a parity sync/rebuild started, i canceled it, now the new disk is unmountable, old disk is empty, and no it is not backed up

[garycase]

The process you followed resulted in losing all of your data, and there's no way to recover it at this point.

 

After you pre-cleared the new disk, if you had simply replaced the old disk with the new one, then the system would have rebuilt the contents of the old disk onto the new one.   Basically this is what you eventually did -- but you first emptied the old disk ... so parity was updated to reflect those changes ==> and when you then replaced the old disk with the new one, the system dutifully did exactly what it's designed to do ... it started to rebuild the contents of the old disk onto the new one you just replaced it with.    Unfortunately, the contents of the old disk were nothing ... since you had already removed all of the data from it.

 

You can NOT add a new disk that contains data to an existing array.    What you should have done, since you wanted to replaced a disk, was simply do exactly that -- replace the disk -- and UnRAID would have rebuilt the contents of the old disk onto the new one.    But after you had already moved all of the data to the new disk, what you needed to do to preserve the data on that disk was to do a "New Config" ... and let the system then rebuild parity.

 

Unfortunately, at this point you've lost all of that data.    You'll need to recopy it to the array from your backups (if you have backups), or re-acquire the data if you don't have backups.

 

[tdallen]

Would xfsrepair or another tool have any chance of repairing the file system on the new disk?  Assuming the rebuild was cancelled very quickly there might still be data on it if the file system could be restored.

[spl147]

28 minutes ago, tdallen said:

Would xfsrepair or another tool have any chance of repairing the file system on the new disk?  Assuming the rebuild was cancelled very quickly there might still be data on it if the file system could be restored.

running now

[garycase]

If the rebuild was stopped VERY quickly there's a chance some of the data could be recovered with xfsrepair -- but remember that the array is in an unstable state at this point -- it "thinks" there's a disk that needs rebuilt.    I would do a New Config with all of the disk EXCEPT this disk, and let parity build.   Then try xfsrepair on the new disk -- and if you DO manage to recover some files, then copy them to the array or, if you don't have space, do yet another New Config to add that disk and let it do another parity sync.

 

 

[SSD]

19 hours ago, spl147 said:

so i precleared a new disk, then i used mc to MOVE the data from the old disk to the new disk, so the data was deleted from the old disk. i then swapped the old for new, when i started the array parity started a rebuild, so i clicked cancel quick, now the new disk cannot be mounted and data is gone!

 

is it possible to force a parity rebuild of a specific disk from the command line?

 

You seem to have a rather fundamentally flawed understanding of how unRaid disk replacement works. Were you following some guide or referencing some material that lead you to believe this was the right process?

 

What you did was move all your data to a non array disk, so it did not exist in the array any more, and then rebuild a now empty disk with a disk containing your data. UnRaid did what you asked - it replaced the disk moving all of the data from the empty disk to the new disk. Copying to a replacement disk (so long as unRaid partitioned and formatted it.initially) is valid, but you then need to do a new config to rebuild parity. Rebuilding is also valid. But you can't mix the two.

 

I say your disk was empty but in a real sense no disk is empty. A disk has a certain number of sectors, and unRaid copied each and every sector to the new disk. When a file is deleted its data is not blanked out. Instead the space is marked as available for reuse. So all or most of your data is on the disk, it is just in an unorganized set of sectors with no way to make sense of it. And this same situation exists on both the original disk as well as the rebuilt disk - as they are clones.

 

The repair tool may be able too put Humpty Dumpty back together again, but experience using it to undelete is very limited, and frankly not terribly good.

 

Best of luck in the repair. If you have questions, even basic ones, don't hesitate to ask. We'd rather answer 100s of simple questions than see something like this happen to one of our own.

[JonathanM]

1 hour ago, bjp999 said:

Copying to a replacement disk (so long as unRaid partitioned and formatted it.initially) is valid,

But not Unassigned Devices. Unless things have changed, the partition layout put in place by UD is NOT directly array compatible. Temporarily assigning a disk to a SINGLE slot cache layout and formatting with XFS will work, and you can then mount the disk with UD and copy data to it.

[JonathanM]

15 hours ago, spl147 said:

i used mc to MOVE the data from the old disk to the new disk

Copying instead of moving is always quicker and safer. Copy is 1 read from source and 1 write to destination, move adds a delete after copy, which requires a write to the source as well. Unraid array writes involve at least 2 disks, so writing is quite a bit slower than a plain read. Much better to copy, verify, then after the operation is totally settled and complete you can make the choice to leave the copy as a backup in another location, or delete it if it's no longer needed.

 

I know you've been beat up on enough, but I wanted to help you and anyone else that finds this thread for the future.

[spl147]

1 minute ago, jonathanm said:

Copying instead of moving is always quicker and safer. Copy is 1 read from source and 1 write to destination, move adds a delete after copy, which requires a write to the source as well. Unraid array writes involve at least 2 disks, so writing is quite a bit slower than a plain read. Much better to copy, verify, then after the operation is totally settled and complete you can make the choice to leave the copy as a backup in another location, or delete it if it's no longer needed.

 

I know you've been beat up on enough, but I wanted to help you and anyone else that finds this thread for the future.

yea, i usually use copy, but was in a rush...lesson learned.....3tb of movies gone as a result (80+ blurays)

[garycase]

You can always recopy them from your original discs ... but in the future you might want to start keeping backups as well, which are far more convenient to recover from.