

I don’t think this meets the definition of 3-2-1. Which isn’t a problem if it meets your requirements. Hell, I do something similar for my stuff. I have my primary NAS backed up to a secondary NAS. Both have BTRFS snapshots enabled, but the secondary has a longer retention period for snapshots. (One month vs one week). Then I have my secondary NAS mirrored to a NAS at my friends house for an offsite backup.
This is more of a 4-1-1 format.
But 3-2-1 is supposed to be:
-
Three total copies of the data. Snapshots don’t count here, but the live data does.
-
On two different types of media. I.e. one backup on HDD and another on optical media or tape.
-
With at least one backup stored off site.
Might be a bit late on this, but ProxMox doesn’t really handle assigning threads to the e/p cores. That’s handled by the kernel and as long you’re running kernel version 6.1 or greater you should be good on that front.
If you really need to, you can also pin specific VMs to specific cores. So that if you’ve got something that always needs the performance it can always run on the p-cores and things that aren’t as demanding can always run on e-cores.
That said, especially if you’re over provisioning, it’s probably better to let the scheduler in the kernel handle thread assignments.