January 20, 20233 yr I recently had a drive fail on me. However as I was trying to locate the right drive I managed to drop and break another drive. Luckily (prehapse), this drive was the parity drive. So at this point I had two failed drives. And becuase I dont have dual parity - I could not rebuild the array. I managed to copy of the data from the original drive that failed onto a spare using windows explorer (one drive was pluged into my second unraid machine and I did a network copy onto a NTSF formatted drive in windows). After all this I set up a new array config. However the original drive that failed was being shown so I added that back in and put a new drive in and set of the parity sync. The parity sync completed however during the parity sync I got errors saying "current pending sector is 64" on the old drive. The old drive has failed for me again today (after a couple of days with no issues) so realised I need to replace that drive. My thoughts were: Create a new config with my existing drives (miuns the one that has failed) and add in a new one (to repolace the failed one) and readd the parity drive and set of a sync. I believe this should leave me with the data on all my drives minus the one that failed. I will then manually copy across all the data from the old drive that failed back onto the array. I can copy the data from the failed drive (if it can still be read) or the drive I copyued the data across to when it originally failed. Now my questions: Is the partiy drive I recently created any good? Or does the "current pending sector is 64" mean that data is likely to be corrupt? My thoughts are yes, and probably not a good idea to rely on it for a rebuild - hence the new config. What tools should I use to get data off my old failed drive. I previously used windows explorer to do this as I wanted to get as much data off as quickly as I could. It seemed to work, but not sure if any errors or issues would of stopped it. Should I of used another tool. I am happy to try another approach. Cheers
January 20, 20233 yr Community Expert You could try rebuild followed by check filesystem on the rebuilt disk and if that is OK it is probably fine. Keep the copied files and the original disk until you are satisfied with the rebuild. You must always have another copy of anything important and irreplaceable of course. Parity is not a substitute for backup.
January 25, 20233 yr Author On 1/20/2023 at 11:11 PM, trurl said: You could try rebuild followed by check filesystem on the rebuilt disk and if that is OK it is probably fine. Keep the copied files and the original disk until you are satisfied with the rebuild. You must always have another copy of anything important and irreplaceable of course. Parity is not a substitute for backup. Thanks rebuild array from parity and run the file check. I got the following message when I used tags -nv. Phase 1 - find and verify superblock... - block cache size set to 1417896 entries Phase 2 - using internal log - zero log... zero_log: head block 1792898 tail block 1792898 - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 1 - agno = 2 - agno = 3 - agno = 0 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Wed Jan 25 18:14:31 2023 Phase Start End Duration Phase 1: 01/25 18:13:38 01/25 18:13:39 1 second Phase 2: 01/25 18:13:39 01/25 18:13:39 Phase 3: 01/25 18:13:39 01/25 18:14:16 37 seconds Phase 4: 01/25 18:14:16 01/25 18:14:16 Phase 5: Skipped Phase 6: 01/25 18:14:16 01/25 18:14:31 15 seconds Phase 7: 01/25 18:14:31 01/25 18:14:31 Total run time: 53 seconds My understanding is the above is the output from a dry run. Do I need to re-run with just the -v tag or should I do somthing else? I cannot see any errors or warnings. Thanks Edited January 25, 20233 yr by ezzys
January 25, 20233 yr Community Expert 42 minutes ago, ezzys said: Do I need to re-run with just the -v tag Yes.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.