I have 6 data disks and 2 parity, under Windows 10 Pro, connected to an Areca HBA in JBOD mode.
My previous sync failed due to bad sectors on the first parity drive, and data has changed since last successful sync. I attempted to repair with chkdsk /F /R, but it returned insufficient space to replace bad clusters.
I'm not clear on what the recovery procedure is with the new replacement disk.
it suggests first running a sync, which is not possible with the original disk.
Assuming I'm able to copy the existing .parity file to the new disk, and that the file might be damaged, either from bad sector corruption, or incomplete sync, should I first attempt a 'snapraid fix -d PARITY', and then run full sync? Or is it better to just leave out the existing parity file, and recreate a new one with a full sync.
Thanks for any advice.
Last edit: Leon Barber 2024-07-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Since your parity disk is broken, I would just replace the broken disk with the replacement disk and see this as a normal disk recovery. Afterwards I would run: snapraid fix -d PARITYNAME to recover the parity. Then make sure your files and everything are there, then run a snapraid sync.
The procedure you linked is mainly for replacing a working parity disk with a (bigger) one.
This is the relevant part for you: If you have a partially damaged or totally lost parity file, you can run the "fix" command to recreate it, but ensure to use the -d option to fix only the interested parity and not the other disks. snapraid fix -d PARITYNAME
P.S. If your files changed after the last SYNC operation, make sure you only run the FIX operation on the PARITY disk (with the command listed above). That will restore your parity to the previous SYNC state, but not your files (your changes would be lost). A SYNC after the FIX will then update parity with any new files added/updated since the last SYNC operation.
Last edit: Rysz 2024-07-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I completed the replacement process as follows, and everything appears to be normal.
Copied the existing parity file to the new drive.
With both 14TB drives in USB docks, a 7TB parity file, and transfer rate of only 85MB/s, this step took almost 24 hours. Unfortunately, the source drive disconnected with less than 5% to go, and the copy had to be repeated. Started the copy a second time, and for some odd reason, the transfer rate this time was 230MB/s, so it completed in only 9 hours.
Placed the new drive in the internal bay where it belongs, and ran the snapraid fix -d PARITYNAME command.
This ran for about 35 hours, with only 2 warnings.
Ran a standard sync, that completed with no issues.
So considering how long the fix step took, I'm not sure validating parity using an existing copy was beneficial compared to just building a new one from the data.
Thanks again for the advice.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I have 6 data disks and 2 parity, under Windows 10 Pro, connected to an Areca HBA in JBOD mode.
My previous sync failed due to bad sectors on the first parity drive, and data has changed since last successful sync. I attempted to repair with chkdsk /F /R, but it returned insufficient space to replace bad clusters.
I'm not clear on what the recovery procedure is with the new replacement disk.
Following the FAQ section at https://www.snapraid.it/faq#reppardisk ,
it suggests first running a sync, which is not possible with the original disk.
Assuming I'm able to copy the existing .parity file to the new disk, and that the file might be damaged, either from bad sector corruption, or incomplete sync, should I first attempt a 'snapraid fix -d PARITY', and then run full sync? Or is it better to just leave out the existing parity file, and recreate a new one with a full sync.
Thanks for any advice.
Last edit: Leon Barber 2024-07-20
Hello!
Since your parity disk is broken, I would just replace the broken disk with the replacement disk and see this as a normal disk recovery. Afterwards I would run: snapraid fix -d PARITYNAME to recover the parity. Then make sure your files and everything are there, then run a snapraid sync.
The procedure you linked is mainly for replacing a working parity disk with a (bigger) one.
This is the relevant part for you: If you have a partially damaged or totally lost parity file, you can run the "fix" command to recreate it, but ensure to use the -d option to fix only the interested parity and not the other disks. snapraid fix -d PARITYNAME
P.S. If your files changed after the last SYNC operation, make sure you only run the FIX operation on the PARITY disk (with the command listed above). That will restore your parity to the previous SYNC state, but not your files (your changes would be lost). A SYNC after the FIX will then update parity with any new files added/updated since the last SYNC operation.
Last edit: Rysz 2024-07-20
I completed the replacement process as follows, and everything appears to be normal.
With both 14TB drives in USB docks, a 7TB parity file, and transfer rate of only 85MB/s, this step took almost 24 hours. Unfortunately, the source drive disconnected with less than 5% to go, and the copy had to be repeated. Started the copy a second time, and for some odd reason, the transfer rate this time was 230MB/s, so it completed in only 9 hours.
This ran for about 35 hours, with only 2 warnings.
So considering how long the fix step took, I'm not sure validating parity using an existing copy was beneficial compared to just building a new one from the data.
Thanks again for the advice.