Virtual harddrive broken

[xyno]

Since yesterday i've notice my webserver was down, it has been running as a virtual machine within truenas scale.
Signal that im afraight the virtual disk is broken:

Obviously i expected something to be broken preventing it from booting, however when i type exit to get into the virtual bios, Boot from file, i get a complete empty window without any options what so ever:

Next up i tried to mount it into kali that i installed quickly, to have that handy UI to recover files and the database.. but i ran out of luck here

lsblk shows the drive as sdb with the correct disk size (32gb)

Trying to mount it:

This is as far i know how to deal with these situations.

I am unsure what exactly happend, no power failure, other VM's seem to be uneffected.

Disks are running in mirror, no errors as far i can tell.

 

[joeschmuck]

While I don't have the experience to answer this question, I do know that you should specify the version of SCALE you are using and list your hardware specs. Provide some details so the person who provides you help is not totally guessing.

 

[xyno]

While I don't have the experience to answer this question, I do know that you should specify the version of SCALE you are using and list your hardware specs. Provide some details so the person who provides you help is not totally guessing.

Good point

Hardware:
i7 11700k, 64gb ram installed
The drives im using are magnetic harddrives (2x2 in mirror).
below 40% capacity used, monthy scrub jobs.
2nd drive is on its edge of being full, but it only runs test machines and pretty much is a media-disk

disk is visible in datasets (as highlighted)

Version:
TrueNAS-SCALE-22.12.2

Im not sure what more info i should include here, hope someone with a bit more knowledge being able giving me pointers.

 

[joeschmuck]

Again, I'm not the right person to really help but until someone does, let me see if I can help a little.

The mount command you were using, you need to specify the partition I believe, but I'm not sure why sdb does not indicate it having any partitions. This could be your problem, no partitions. Did you by chance to anything to the system a few days ago? a week ago? Think back, it's easy to make a mistake. Check sdb for partitions. Hopefully you can find one such as sdb1.

Can you get into the VM drive at all to see your server pages so you can save it if needed? Or do you have a snapshot that might help you?

That is all I got. Wish I could be of more help. I do not run VM's in TrueNAS.

 

[xyno]

Bump, new VM is running, still unable to repair partitions/view lost data.
Any pointers still welcome.

 

[sfatula]

Can you fdisk -l /dev/sdb as root from within Kali linux, assuming it's still sdb?

 

[xyno]

Mounted the drive again on the VM, its called sda now
When using fdisk -l /dev/sda i get the following:

Sadly no partitions listed

 

[joeschmuck]

So if the drive is sda, and you enter cd /dev/sda does that work? If yes then ls -all to see if anything is listed at all.

I'm pretty sure not of that will work. That is one of the hazards with virtual drives.

 

[xyno]

So if the drive is sda, and you enter cd /dev/sda does that work? If yes then ls -all to see if anything is listed at all.

I'm pretty sure not of that will work. That is one of the hazards with virtual drives.

Yeah it doesnt, the partitions doesnt show up neither.
I have set up a propper backup now on the new VM, however still having some hopes that i can recover the database.

 

[joeschmuck]

I was using something called ESXiBackup (name could be wrong) when it was free to home users, the home version was limited but was all I needed. I did not want to pay for a subscription. Every thine ESXi changed and be charged for the working product upgrade. I just manually backup my VM's whenever I think about it. I suspect I can automate it but I have so few to backup and they are small, so it isn't a big deal for me. But I only use VM disks for testing, I pass through real drives for long term use. I know not everyone can do that so VM disks is a way to go.

Best of luck recovering the data.