@iFFgen , Sorry to have to repeat this but changing a disks UUID (which isn't possible other than maybe with very breaking-stuff-level-hackery) isn't going to magically make the lost data appear on that disk - the data belonged to basically what is the past-life of that disk (assuming what you said regarding to new UUID is true).
As I said, if a disk has a new vSAN UUID then to vSAN and the Disk-Group this is a part of, this was a claimable blank disk that has now been added to the Disk-Group as a blank disk - do you have auto-claim enabled? Asking as that is another possibility over human intervention (but still, vSAN would have had to see it as a blank disk with no partitions for that to occur).
Regardless, looking at the inaccessible Objects it is clear that they were not in a redundant state when the failure occurred (e.g. FTT=1 with 2 failures) - the data components on esxi-5 were being resynced from the data stored on esxi-1 (e.g. in the below it had synced 8.66GB of 58.61GB) when the only full remaining copy of the data stored on esxi-1 was lost due to (presumably) hardware failure on esxi-1.
Object UUID: e3c79760-3c90-201c-014a-0cc47a6cd44e
Version: 10
Health: inaccessible - Lost quorum.(APD)
Owner: esxi-2
Size: 0.00 GB
Used: 8.67 GB
Policy:
Configuration:
RAID_1
Component: e3c79760-ad57-f91c-5a95-0cc47a6cd44e
Component State: ABSENT, Address Space(B): 108447924224 (101.00GB), Disk UUID: 52a32d00-2307-8dd5-8c14-90604418bc75, Disk Name: N/A
Votes: 1, Host UUID: None
Component: 246b9a60-46ac-46ff-4de5-0cc47a6cd44e
Component State: RECONFIGURING, Address Space(B): 108447924224 (101.00GB), Disk UUID: 52657cd9-b4ca-a1fe-5ce3-969aa4d57a26, Disk Name: t10.ATA_____Hitachi_HDS723020BLE640_______________________MS77215W0RKDVA:2
Votes: 1, Capacity Used(B): 62935531520 (58.61GB), Physical Capacity Used(B): 9302966272 (8.66GB), Host Name: esxi-5.xxxxxxxxxxxxx
Witness: 246b9a60-6ed3-48ff-c622-0cc47a6cd44e
Component State: ACTIVE, Address Space(B): 0 (0.00GB), Disk UUID: 528f6cb0-1b49-8b69-a5bf-76ac9805361e, Disk Name: naa.5000c500a407e844:2
Votes: 1, Capacity Used(B): 12582912 (0.01GB), Physical Capacity Used(B): 4194304 (0.00GB), Host Name: esxi-2
Type: vdisk
Path: /vmfs/volumes/vsan:528c37b83342ce2a-6b0ecc1731c834e9/e2c79760-8447-b999-d99d-0cc47a6cd44e/Test-1CRent-De.vmdk (Exists)
Group UUID: e2c79760-8447-b999-d99d-0cc47a6cd44e
Directory Name: N/A
I am going to hazard an educated guess and assume the data in FS_1.vmdk is what is valuable to you here and I will say from looking at the remaining components that full recovery of this will not be possible as there is not a complete copy of the data (and the reconfiguring/partial components are only a fraction of the data) - best-effort recovery attempt of the data from the rest of the components (e.g. minus the ~158GB of data that was on disk with UUID 52a32d00-2307-8dd5-8c14-90604418bc75) would at best result in partial data usable and at worst none of it useable (depends on too many factors to say). That being said, if you have no backup recovery plan, can't engage Kroll or someone to see what is on that disk and whether it is usable (assuming it is not over-written partitions/blank) then do open an SR with us in vSAN GS.
