A drive wouldn’t mount via UD, so I went to shutdown the server. After it wouldn’t power off by itself for over 4 hours, I had to hard shutdown the server. Upon restart, one of the array drives had no partition anymore. All drives in the array were encrypted. Filesystem was xfs – encrypted.

 

Restored the server and got everything running again. So far so good.

 

The drive with the lost partition is still as is. Now I would like to try and recover it, if possible. It would give me a chance to see if there are files that were newer than from the backup.

 

The drive in question is outside the array now and I’m looking for steps I need to take, recovering the data, if at all possible.

 

Edited December 17, 20205 yr by UnraidDuck

Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread 

3 hours ago, trurl said:

Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread 

Thanks @trurl for the quick response. I'm not looking at fixing one of my unraid servers, so a Diagnostics will do no good. Far too much personal info in it.

 

What I am looking for is advice on how to go about checking for a lost partition table on an xfs - enxrypted drive. Password is known. So how to use cryptsetup and xfs_repair commands.

 

Further disk info and smart status are no problem, although they won't change the way to possibly recover information from the drive.

The reason I asked for diagnostics was to save a lot of questions back and forth. You say the disk is outside the array now. Is the disk being emulated in the the array? Or did you New Config / Rebuild Parity without it?

 

Is there something specific in the anonymized diagnostics that you think needs to be anonymized?

As stated in the original post, "Restored the server and got everything running again. So far so good."

 

So, we are just talking about a single drive which used to be part of an array that does not exist anymore.

 

I'm greatful about your and the forum communities help. If any specifics about the drive is needed, let me know, however that should make no difference on the recover. The drive is in very good shape, no defekt oder strange noises. It is still under a 5 year data recovery option from seagate. But rather than having it travel for several month (that's how long another recovery took in Covid times) I would like to have a non destructive look myself.

I know what you said. Please answer the specific question

14 minutes ago, trurl said:

did you New Config / Rebuild Parity without it?

The reason I asked is because removing a disk from parity in order to repair its filesystem is not the usual approach since the repair has to include parity. 

No paritiy on the old server, therefore no rebuilt. New server setup, different Hardware. First thing I tested was different hardware and controllers. All hardware checked OK. Drive is also OK. I did not loose anything.

 

Still a single drive which I would like to start a non destructive look onto. Since I can't loose anything on the drive, nothing can go wrong.

https://wiki.unraid.net/Check_Disk_Filesystems

2 minutes ago, trurl said:

https://wiki.unraid.net/Check_Disk_Filesystems

Already checked that. Unless I overlocked it (if so, please point me to the correct block), there is no entry for fixing xfs - encrypted. Searching the entire wiki page for encrypted or luks provides no hits. First I need to recover the LUKS entries. Only than can I use xfs_repair.

If the disk were in the array then using the section on repairing it in the webUI should work. No other advice for you since I don't use encryption. Maybe someone else will.

Managed to get access to the lost data. Hope this little workflow helps the next person this might be happening to.

 

So, after a system lockup and a hard rest, one of my data drives in the array showed up without any partition or data. The drive was part of an array with xfs-encrypted drives. There was no parity drive. (No risk for me, as I have plenty backups)

 

Use the following method at your own risk. Always have backups, there is no substitute.

 

The drive in question needs to be outside the array or the array needs to be stopped. My drive was outside the array and only visible in the GUI with the great plugin Unassigned Devices. At the end of the identification (Table Unassigned Devices, Main page), you find the device name sdx (where x typically is a, b, c, etc.). Let us say it is sdg.

 

Open the terminal. First, we need to find the LUKS header.

hexdump -C /dev/sdg | grep "4c 55 4b 53 ba be"

If you get a result use CTRL-C to stop the dump.

 

Note the first Hex number, it should look something like “00008000”. Now translate it into decimal. I used https://www.rapidtables.com/convert/number/hex-to-decimal.html

 

00008000 translates to decimal 32768.

 

Let us find the next free loop filesystem.

df -h

If you see entries like /dev/loop3 use the next one up, that is not listed. Now we combine the device, the decimal number and the next free loop in the next step.

losetup -o 32768 /dev/loop4 /dev/sdg

Now we open the device. If we get asked for the secret password, we hit the right spot to access the data.

cryptsetup luksOpen /dev/loop4 lukstemp

Enter your passphrase. If you get back to the prompt without any message, it worked!

 

Finally, we create a mount point and mount the filesystem.

mkdir /mnt/decrypted_drive

mount /dev/mapper/lukstemp /mnt/decrypted_drive

If all went as planned, we now can access the data under /mnt/decrypted_drive .