This entirely depends on how you want to go about backups. Well, that's a partial lie; it depends also on your tolerance for downtime.
One, treat the machines as actual machines. That is, put them into your backup cycle on your backup server. If there's a failure, you re-create the virtual machine as a blank slate (or create a template from a machine) then restore from "bare metal" as you would any other server.
Second, you can shut down the machine, and from the vSphere console (or a dedicated copy utility like Veam's copy utility (Veem?)) copy the subdirectory from the datastore to another location.
Third, you could spend the cash on getting a storage array that can snapshot the filesystem and copy it elsewhere without the operating system knowing about it, or mirror the storage system to another server over ethernet.
Fourth...I believe there are products available, perhaps from VMWare or other vendors, made to copy the virtual machines. But I'm not sure on that since I don't use products like this.
If you're doing this on the absolute cheap, I'd go with shutting down the servers and copying the directories periodically. This can literally take hours; in our case it can take the better part of a weekend. But we make do with what resources we have available.
We also do backups with agents to the backup server; if necessary we could recreate a server and restore from backup for most of our virtual machines. Probably "best practice" without special applications would be to do it this way.
Also remember you would end up with "clones" doing this, down to the MAC address. Probably not a good thing to have them both running at the same time or you'll confuse your switches and other machines that suddenly see two "FileServerABC"'s on the network all of a sudden fighting over who owns what static IP and Windows name.
And while having virtualized DC's can work well, don't snapshot them and roll them back a significant amount of time or you can wreak havoc with your Active Directory setup...