Paco Hope #resist<p><span class="h-card" translate="no"><a href="https://infosec.exchange/@FritzAdalis" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>FritzAdalis</span></a></span> The virtual hard disks of the VMs are ZFS zvols, not files. There are regular snapshot of those zvols. But: (a) restoring a VM from a zvol snapshot is an exercise left to the reader. There’s no GUI, no CLI script. No documentation. (b) I don’t know if it’s possible (it certainly isn’t easy) to move those snapshots off-host/off-site for safe keeping, then bring them back onto the host to restore. (c) it takes more to back up a VM than making a write-consistent snapshot of the hard disk. How many CPUs had I assigned? How much RAM? If it had more than one virtual disk, which zvol was boot and which was data? If I restore by making a new VM with a new virtual NIC it will get a new MAC address and DHCP will assign a different IP when the restored VM boots. A backup process for a VM captures all these things. A restore process accounts for putting things back.</p><p>It’s not that any of this is insurmountable. (Maybe the zvol export thing is) It’s just that I shouldn’t be doing this from scratch/the hard way in 2025. There is absolutely no reason to run VMs this way.</p><p>There are so many better ways to offer VMs. They would have done better to leave the feature out. It’s less work for them and doesn’t mislead their users.</p><p><a href="https://infosec.exchange/tags/TrueNAS" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>TrueNAS</span></a> <a href="https://infosec.exchange/tags/selfhosted" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>selfhosted</span></a></p>