December 2, 20214 yr I have a small unRAID setup that consist of (1) 14TB Parity disk, (3) 12TB data disks and (1) 6TB data disk. After shutting my system down to add a GPU, I had accidently set one of my data disks as a 2nd Parity disk. Before starting the array, I did select the "Parity is already valid" checkbox. About 1 minute into the start up of the system, I realized my mistake and stopped the arry. I then went to set the disks back to the original setup prior to my mistake but I saw the errors indicating wrong disks so went to create a new config. Unraid can no longer see data on the 12TB disk that I had accidently set as the 2nd Parity. Is there anyway I can still rebuild that disk from the 1st Parity Disk or is my data pretty much gone?
December 2, 20214 yr Author Diagnostic has been attached. Thank you. skynet-diagnostics-20211202-1701.zip
December 3, 20214 yr Community Expert 10 hours ago, ktran said: I did select the "Parity is already valid" checkbox. If this is true disk should be mostly OK, assuming no other writes to the array, there will always be some writes to parity due to mounting and unmounting the other filesystems, to keep other options open if needed post new diags after trying to mount the affect disk with the UD plugin.
December 3, 20214 yr Community Expert 5 hours ago, JorgeB said: other options There is more than one way forward here, but don't do anything without advice. 5 hours ago, JorgeB said: mount the affect disk with the UD plugin.
December 3, 20214 yr Author Affected disk mounted and new diagnostics attached. Thank you. skynet-diagnostics-20211203-0924.zip
December 3, 20214 yr Community Expert I don't see anything mounted in the diagnostics, or even any assigned disks. You do have a failing SSD attached though. Post a screenshot of Main - Array Devices and Main - Unassigned Devices.
December 3, 20214 yr Community Expert No doubt nothing is assigned because of the New Config. I assume you know what your disk assignments are supposed to be. But you haven't mounted the Unassigned Device. "Mount" is a special word that means much more than just installing a disk, it means the filesystem on the disk has been made accessible.
December 3, 20214 yr Author I haven't assigned any disks to the Array devices because I was afraid if I did, it would overwrite any data I have on the affected disk (DISK 1). However, I do know what my disk assignments are supposed to be prior to the mishap. As for the Unassigned Devices, the "Mount" option is greyed out on the affected disk (DEV 5) so I'm assuming it's already mounted?
December 3, 20214 yr Community Expert 8 minutes ago, ktran said: As for the Unassigned Devices, the "Mount" option is greyed out on the affected disk (DEV 5) so I'm assuming it's already mounted No, that means the UD plugin is not recognising a file system it can mount. If it HAD mounted then you would have an unmount option
December 3, 20214 yr Author Thank you for the clarification. So does that mean both my Parity Disk 1 and my Data Disk 1 are no longer accessible since the option to mount them are greyed out? Also, if I assign disk 2, 3 & 4 back into the Array devices without the Parity Disk 1 and Data Disk 1, will my unRAID system will be able to function? And if so, will it affect my array or my data without the other two disks? I was hoping I can still have my unRAID system running while we look into options to try to restore data to Disk 1 if possible.
December 3, 20214 yr Community Expert It's normal for parity not to have a mount option, since there's no valid filesystem, as for old disk1 and assuming the filesystem was the default XFS you can try running xfs_repair to see if it finds a backup superblock: xfs_repair -v /dev/sdb1
December 5, 20214 yr Author So I ran xfs_repair -v /dev/sdb1 and it looks like it completed. However, I'm not sure where to go to grab the logs. Can someone help me please? Thank you.
December 5, 20214 yr Community Expert You can copy/past from the GUI/CLI, or just see if the disk now mounts.
December 5, 20214 yr Author When I came back to check the repair status on the GUI/CLI, the tab for the terminal was closed out. I didn’t get to see the result and the disk is not able to mount. The “Mount” option is still greyed out. At this point, what are my other options?
December 6, 20214 yr Author New diagnostics attached Thanks. skynet-diagnostics-20211205-1907.zip Edited December 6, 20214 yr by ktran
December 6, 20214 yr Community Expert Try the repair command again and be sure to capture the output.
December 8, 20214 yr Author Please see output below: root@SKYNET:~# xfs_repair -v /dev/sdb1 Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... .....found candidate secondary superblock... unable to verify superblock, continuing... ...found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... ............................................ Sorry, could not find valid secondary superblock Exiting now.
December 8, 20214 yr Community Expert Looks like we are going to have to try to rebuild it from parity. Post a screenshot of Main - Array Devices
December 9, 20214 yr Author I've attached the original config of the disks prior to the incident as well as the current config (which was done to get the system online temporarily). In the current config, I did not add back the 14tB parity disk since I'm hoping I can rebuild DISK 1 (SN# 8CJLUPOE - sdb), and was afraid if I had re-add the parity disk, the data would get overwritten.
December 9, 20214 yr Community Expert Would have been better if array hadn't been started since this began but nothing to be done about that, parity is going to be out-of-sync to some extent. Hopefully you haven't actually written anything to the array during all this, but that first screenshot has more writes to disk4 than seems appropriate. Any idea what that is about?
December 9, 20214 yr Author So if data were added recently, would that cause any issues while rebuilding disk1? As for disk4, that's where my most recent data are stored.
December 9, 20214 yr 7 minutes ago, ktran said: So if data were added recently, would that cause any issues while rebuilding disk1? Yes. Parity is the missing bit combined with ALL the data drives. So any data altered on the rest of the drives is going to corrupt the rebuild of disk1. With that much altered on the rest of the data disks, emulating disk1 is no longer an option. Sometimes you can get away with a few writes caused by the mounting process where the corruption is small enough that a file system check can repair things, but new files being written to the remaining data drives is going to corrupt things way beyond repair. The parity drive in isolation is worthless, it has no data whatsoever. It only has value when it's in sync with all the rest of the data drives. Remove one data drive, and the rest of the data drives plus the parity bit emulate the single missing drive.
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.