Before you explore options, you should consider your goals. I say this because each option provides a different level of coverage.
- You have one server now, but what happens a year or two down the road and you add servers into the farm? How will you back these servers up (or will you even need to)?
- What are your service level agreements (SLA) with the business? Is this SharePoint instance critical to the business? What will happen if there is a significant outage while you are restoring from backups? I gather your particular instance is not super critical as it is contained on a single server, but will you lose your job if the site's not available for a day?
- How big is your site, and where can you back up all that data?
That all said, there are more or less four high-level options and you could implement one or more of these for added protection:
Back up the virtual machine
This strategy typically involves backing up the Hyper-V VHD(s) as part of a backup that occurs on the VM host. The main benefit to backing up your VM is you can restore the entire server quickly. However, since you are backing up the entire server you typically don't have the ability to perform a restore of anything other than the entire server. Web application corrupted? Gotta restore the whole server. Overwrote a site collection? Restore the whole server. Deleted an item and it's no longer in the recyle bin? Yup, restore the server and lose 30 days or so of content. Alternatively you could restore an old backup elsewhere, spin it up and copy out the content you need. This could be a very intensive operation.
Pros: complete server, simple restore, less troubleshooting following restore. Cons: Must restore entire server, can't restore individual items
The backup and restore tools in SP2010 have improved since v3. It's easy to restore individual service applications, web applications or content databases. You can automate daily backups with PowerShell and scheduled tasks, and use Central Admin for restores. You still can't get item-level restores, though most of the time the Recycle Bins will come through for you. Also, this backup goes to a network share. Will you have a place where you can have multiple days of backups? For more information, see Back up a farm (SharePoint Foundation 2010). Since it's out of the box, the built-in backup tools are supported by Microsoft and well understood within the SharePoint community. Generally a backup routine using the built-in tools feels kludgy and is not suitable for an enterprise (though that doesn't stop them), especially for compliance.
Pros: Work well, supported by Microsoft and the community, free. Cons: not an enterprise solution, no item-level restore.
Most backup vendors can backup up SharePoint either natively or with the use of an agent or extension. These tools can be more complicated and significantly more costly, but almost all of them provide the full range of restores from the entire server right down to an item level restore. The restores can be redirected to other farms or disk and generally provide many more features. Again, costly. Third party tools can make use of different backup media and retention policies which are important if your organization has compliancy requirements. Costly.
Here are some tools (I'm not recommending, just listing so you get an idea of what's available)
Pros: Generally a full backup solution that is part of your enterprise backup solution, item-level restore, useful functionality, can satisfy compliance requirements. Cons: Can cost more than your farm, can be difficult to use or support.
If all you care about are the content databases and you're prepared to attach them to a new farm as needed, this could work for you but generally you'd only do this as a backup to your backup. With a content database you can restore the site collections in the content databases, though with a full recovery model you can restore to a point in time.
Pros: Your DBAs will love them. Cons: Not useful for full farm restores.