Not just re-format, you need to delete existing partition, v6.9 uses a more optimized partition layout for SSDs:
https://wiki.unraid.net/Unraid_OS_6.9.0#SSD_1_MiB_Partition_Alignment
Disk3 needs to be replaced, but if the filesystem in the emulated disk can't be fixed you can use ddrescue on it and it should be able to recover almost everything.
Mar 5 13:51:20 Tower dhcpcd[1598]: br0: soliciting a DHCP lease
Mar 5 13:51:20 Tower dhcpcd[1598]: br0: offered 10.0.0.15 from 10.0.0.1
Mar 5 13:51:25 Tower dhcpcd[1598]: br0: probing for an IPv4LL address
Mar 5 13:51:30 Tower dhcpcd[1598]: br0: using IPv4LL address 169.254.148.36
Mar 5 13:51:30 Tower dhcpcd[1598]: br0: adding route to 169.254.0.0/16
Not really a network guy but looks like a network problem, it's being offered a DHCP address but it's not getting that and using a private IP address instead.
Seems to be related to the Marvell IOMMU issue, you can try this (or disabling IOMMU if not needed), but if it's an option I would recommend replacing that controller with an LSI HBA, those controllers have multiple known issues and are not recommended for a long time.
There have been multiple users with issues with the 8TB Ironwof + LSI, for now best to stick with v6.8.3 or connect those disks to a non LSI controller.
I don't remember if the disk was unmountable at any time, but if the used space looks about right and there's no lost+found folder (if the filesystem was repaired) you should be fine.
It is strange, it should still start, and there's no error, it's like the setting changes to disable, you can try toggling VM service off then on, but doubt it helps.
Should be fine either way but just in case better to update after.
They are, just make sure the emulated disk is mounting and contents look correct before rebuilding on top.