If you stop the server PRIOR to taking a snapshot then snapshot should be fine. It is taking a snapshot while the server is running that can potentially create issues.
Snapshots can be a useful "quick and dirty" tool, but unless you want to regularly stop your server, they are not a reliable backup (due to data volatility within a running server; e.g. perhaps a file is halfway though being written when you take the snapshot!?).
There are also some other considerations to keep in mind:
Size/Cost:
You pay for storage on Amazon, admittedly it's pretty cheap, but it can add up (I cleaned a couple of particularly large snapshots that I had forgotten about recently, saving me $70/mth). Snapshots are essentially a complete copy of your filesystem (AFAIK at a block level). This means that they include the full OS which makes them big! OTOH TKLBAM backups only contain what it needs to; then compresses it. That makes them small! And that's just the "full" backups, the incrementals are much smaller again.
Security and "uniqueness":
A server snapshot is that server's filesystem at a particular point in time. If you launch a new server from a snapshot; for all intents and purposes, the new server IS the old server (at that point in time). It will contain all the configurations of your original server - including things like hostname, HubDNS configuration, SSH and SSL key(s) and certificates.
Assuming that you understand the implications of that, from a development standpoint it is probably not really an issue (e.g. you can adjust the hostname, regenerate secrets, etc). However for a production server (unless the new server is to replace the old one) it is a bad thing. It has serious security implications!
You can work around them if you wish, but none of those shortcomings apply to a TKLBAM restored backup. A new server with a restored TKLBAM backup is a new server, but with the old server's data!
A clone from a snapshot contains all the all the old package versions (at least until turnkey-secupdates runs next). Whereas assuming that you allow the secupdates to run on firstboot; a TKLBAM restore will include all the latest security patches. Other issues you may encounter from a "cloned" snapshot are the new server "stealing" the HubDNS configuration of the original host (and probably the original server stealing it back again later; and so on...). Also, if you are using TKLBAM as well then unless you manually intervene, the 2 separate servers will continue to back up to the same TKLBAM backup record (they both think that it belongs to them). That will almost certainly cause major issues down the track when it comes time to restore!
If the server is not running then snapshots are ok
Snapshots can be a useful "quick and dirty" tool, but unless you want to regularly stop your server, they are not a reliable backup (due to data volatility within a running server; e.g. perhaps a file is halfway though being written when you take the snapshot!?).
There are also some other considerations to keep in mind:
You pay for storage on Amazon, admittedly it's pretty cheap, but it can add up (I cleaned a couple of particularly large snapshots that I had forgotten about recently, saving me $70/mth). Snapshots are essentially a complete copy of your filesystem (AFAIK at a block level). This means that they include the full OS which makes them big! OTOH TKLBAM backups only contain what it needs to; then compresses it. That makes them small! And that's just the "full" backups, the incrementals are much smaller again.
A server snapshot is that server's filesystem at a particular point in time. If you launch a new server from a snapshot; for all intents and purposes, the new server IS the old server (at that point in time). It will contain all the configurations of your original server - including things like hostname, HubDNS configuration, SSH and SSL key(s) and certificates.
Assuming that you understand the implications of that, from a development standpoint it is probably not really an issue (e.g. you can adjust the hostname, regenerate secrets, etc). However for a production server (unless the new server is to replace the old one) it is a bad thing. It has serious security implications!
You can work around them if you wish, but none of those shortcomings apply to a TKLBAM restored backup. A new server with a restored TKLBAM backup is a new server, but with the old server's data!
A clone from a snapshot contains all the all the old package versions (at least until turnkey-secupdates runs next). Whereas assuming that you allow the secupdates to run on firstboot; a TKLBAM restore will include all the latest security patches. Other issues you may encounter from a "cloned" snapshot are the new server "stealing" the HubDNS configuration of the original host (and probably the original server stealing it back again later; and so on...). Also, if you are using TKLBAM as well then unless you manually intervene, the 2 separate servers will continue to back up to the same TKLBAM backup record (they both think that it belongs to them). That will almost certainly cause major issues down the track when it comes time to restore!