If this is truly a read-only database then it must be sourced from somewhere...how is this database built? Is it ever updated and changed - and if so how is that process managed?
If the read-only database is sourced from another instance (e.g. backup and restore from other system) then you don't need local backups.
If the read-only database is built with a process and then set to read-only then you really only need a single backup taken after the build and stored in a safe location.
Unless there is other data on that server that is changing on a regular basis - then a daily snapshot isn't even necessary. A single snapshot would suffice - but that will depend on how large the snapshot gets over time due to delta changes.
With all of that said - setting up native SQL backups is a good practice regardless of other options that are available. It is also much easier to manage if you know that all SQL Server systems will have a defined backup and scheduled maintenance. Just because a database is set to read-only does not mean you can ignore running integrity checks - but you can avoid index rebuild and statistics updates (if the data isn't changing on some scheduled basis).
The only advantage to adding (not replacing) VM snapshots is that you can recover the whole system if needed. The advantage to native backups and maintenance is a standardized approach across all servers regardless of other available technologies which leads to consistent management of all systems.
Problems are opportunities brilliantly disguised as insurmountable obstacles.
How to post questions to get better answers faster[/url]
Managing Transaction Logs[/url]