Phuriousgeorge Posted November 17, 2021 Share Posted November 17, 2021 (edited) Looking for assistance in recovering two of my data disks (all disks are xfs-encrypted) that have suddenly become "unmountable". I was moving a bunch of small files to the array in Krusader that caused the user mount to go away. I had seen this issue before, as this is a new server setup and I've been mass transferring files, so I made sure everything was stopped and restarted the machine. After entering the decryption key and starting the array, two array disks with content are showing as unmountable and persists through subsequent restarts. From looking at the diagnostics (attached), it appears it's related to: PGVault emhttpd: error: ckmbr, 2263: No such file or directory (2): open: /dev/sdj1 ... PGVault emhttpd: error: ckmbr, 2263: No such file or directory (2): open: /dev/sdx1 Now into my speculations: Somehow it appears these disks have lost their partition table? This is my 1st time dealing with issues on encrypted disks, but I've had to conduct a similar rescue in the past. Is it as simple as re-applying the partition table and viola, the data is accessible again? If so, anyone have a good reference for doing so? It's been awhile and I've got multiples of the same disk type to reference partition layout of. Unraid v6.9.2 Spoiler Unfortunately this was the last batch of information to move to the array before adding my parity disks (needed the raw write speed so I didn't spend 6 months transferring 205TB), so recovery via parity calculations isn't an option. pgvault-diagnostics-20211116-1927.zip Edited November 17, 2021 by Phuriousgeorge Unraid version Quote Link to comment
JorgeB Posted November 17, 2021 Share Posted November 17, 2021 Post the output of: fdisk -l /dev/sdX for both disks. Quote Link to comment
Phuriousgeorge Posted November 18, 2021 Author Share Posted November 18, 2021 root@PGVault:~# fdisk -l /dev/sdx Disk /dev/sdx: 9.1 TiB, 10000831348736 bytes, 19532873728 sectors Disk model: WDC WD100EMAZ-00 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 8881A93C-7815-4B51-BB9C-B79A125EB4A8 I didn't include the other disk because it consisted of easily-replaceable "Linux ISOs", so I've been experimenting with its headers...and failing. Quote Link to comment
JorgeB Posted November 18, 2021 Share Posted November 18, 2021 So it's not partition corruption, it's completely missing, easiest way is to rebuild the disk(s), assuming parity is still valid, partition information is outside parity, and Unraid will recreate the partitions, you can easily test by unassigning one of the disks and start the array, if the emulated disk mounts correctly rebuild on top, then repeat for the other one. Quote Link to comment
Phuriousgeorge Posted November 18, 2021 Author Share Posted November 18, 2021 I have no parity in this system at the moment. Quote Link to comment
JorgeB Posted November 18, 2021 Share Posted November 18, 2021 Then can't really help, redoing the partition table is something I never done and have no experience with. 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.