Theoretically, the guest system is totally isolated by the VM and cannot even "see" the host, let alone attack it; so the guest cannot break out of the VM. Of course, in practice, it has occasionally happened. An attack requires exploiting a security issue (i.e. a programming bug which turns out to have nasty consequences) in the VM implementation or, possibly, the hardware features on which the VM builds on. There are few exit routes for data out of the VM; e.g., for Internet access, the VM is emulating a virtual network card, which deals only with the lowest level packets, not full TCP/IP -- thus, most IP-stack issues remain confined within the VM itself. So bugs leading to breakout from VM tend to remain rare occurrences.
There are some kinds of attacks against which VM are very effective, e.g. fork bombs. From the point of view of the host system, the VM is a single process. A fork bomb in the guest will bring to its knees the scheduler in the guest OS, but for the host this will be totally harmless. Similarly for memory: the VM emulates a physical machine with a given amount of RAM, and will need about that amount of "real" RAM to back it up efficiently. Regardless of what the guest does, the VM will never monopolize more RAM than that. (You still want to limit VM RAM size to, say, at most 1/2 of your physical RAM size, because the extra "real" RAM is handy for disk caching; and the host OS will want to use some, too.)
Taken into account that malware/ransomware is implemented on the file level, the best method of protection would be based on a block level recovery tool.
In addition, the best way to overlook the possibility of loosing your data would be the implementation of the the 3-2-1 rule. Its a quite common safety measure in the data infrastructure. We actually implement it quite often, it is based on the replication of your data between 3 nodes as well as creating 2 real-time replication copies of the data between the nodes and storing a single copy of your data in a VTL on the cloud.
For any other additional information, I would like to suggest you to take a look at the following article - https://knowledgebase.starwindsoftware.com/explanation/the-3-2-1-backup-rule/
