Your "backup strategy" fully relies on VM functionality. I don't believe that this is a good idea for a production PI System. What happens if in case of a hardware failure of your VM host(s)? You should aim for a solution that considers a minimum of data loss for your worst case scenario. Hence I recommend setting up PI Backup on the Primary and on Secondary nodes. To avoid PI Backup files become lost when you need to restore a previous snapshot of a VM, I suggest copying the files over to a storage that is independent from the VM environment.
A tip, if there is a gap with archive files on whatever collective member, you can synchronize / copy missing files from another collective member and mount those archives. Because all members of a PI Collective archive independently, archive start and end times usually drift apart. Hence you may want to go back to the last synchronization, the point in time where the oldest archive is the same on all collective members. PI Collective manager can be used to force a synchronization on secondary collective members. The procedure includes taking a backup of the Primary (including selected archives), copying the files to the secondary nodes archive location and registering those archives. The archive registration is build from scratch causing that only those archives are registered that were synchronized. Hence additional (older) archives may need to be registered after the synchronization but this can be done with a single command. Please see the following example:
piartool -ar D:\PI\dat\piarch.0*