ktran Posted December 2, 2021 Share Posted December 2, 2021 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? Quote Link to comment
trurl Posted December 2, 2021 Share Posted December 2, 2021 Attach Diagnostics to your NEXT post in this thread Quote Link to comment
ktran Posted December 2, 2021 Author Share Posted December 2, 2021 Diagnostic has been attached. Thank you. skynet-diagnostics-20211202-1701.zip Quote Link to comment
JorgeB Posted December 3, 2021 Share Posted December 3, 2021 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. Quote Link to comment
trurl Posted December 3, 2021 Share Posted December 3, 2021 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. Quote Link to comment
ktran Posted December 3, 2021 Author Share Posted December 3, 2021 Affected disk mounted and new diagnostics attached. Thank you. skynet-diagnostics-20211203-0924.zip Quote Link to comment
trurl Posted December 3, 2021 Share Posted December 3, 2021 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. Quote Link to comment
trurl Posted December 3, 2021 Share Posted December 3, 2021 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. Quote Link to comment
ktran Posted December 3, 2021 Author Share Posted December 3, 2021 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? Quote Link to comment
itimpi Posted December 3, 2021 Share Posted December 3, 2021 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 Quote Link to comment
ktran Posted December 3, 2021 Author Share Posted December 3, 2021 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. Quote Link to comment
JorgeB Posted December 3, 2021 Share Posted December 3, 2021 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 Quote Link to comment
ktran Posted December 3, 2021 Author Share Posted December 3, 2021 Thanks. Running repair now. Will let you know how it turns out. Quote Link to comment
ktran Posted December 5, 2021 Author Share Posted December 5, 2021 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. Quote Link to comment
JorgeB Posted December 5, 2021 Share Posted December 5, 2021 You can copy/past from the GUI/CLI, or just see if the disk now mounts. Quote Link to comment
ktran Posted December 5, 2021 Author Share Posted December 5, 2021 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? Quote Link to comment
trurl Posted December 5, 2021 Share Posted December 5, 2021 Post new diagnostics Quote Link to comment
ktran Posted December 6, 2021 Author Share Posted December 6, 2021 (edited) New diagnostics attached Thanks. skynet-diagnostics-20211205-1907.zip Edited December 6, 2021 by ktran Quote Link to comment
trurl Posted December 6, 2021 Share Posted December 6, 2021 Try the repair command again and be sure to capture the output. Quote Link to comment
ktran Posted December 8, 2021 Author Share Posted December 8, 2021 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. Quote Link to comment
trurl Posted December 8, 2021 Share Posted December 8, 2021 Looks like we are going to have to try to rebuild it from parity. Post a screenshot of Main - Array Devices Quote Link to comment
ktran Posted December 9, 2021 Author Share Posted December 9, 2021 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. Quote Link to comment
trurl Posted December 9, 2021 Share Posted December 9, 2021 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? Quote Link to comment
ktran Posted December 9, 2021 Author Share Posted December 9, 2021 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. Quote Link to comment
JonathanM Posted December 9, 2021 Share Posted December 9, 2021 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. Quote Link to comment
Recommended Posts
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.