The advent in virtualisation and snapshots resulted in a exponential increase in lazy admins!
You really need to think before you snapshot!
A couple of good basic video tutorials on Snapshots
Takeaways from them
Snapshot is not a backup!
Data may of changed on the machine since the snapshot (just like a backup) or on a remote machine, your local machine relies on
Check the best practices for virtualisation of your applications and what the impact of reverting a snapshot will be!
Common Mistakes People Make Implementing Snapshots
Snapshots are fine when you know the application running on the server does not make changes to any data at any other location , or the data is not replicated off the server.
Here are a number of situations where you should NOT snapshot
Exchange 2013 and snapshots
Exchange 2013 does store some of its data in Active Directory. So if for example you are changing some feature in powershell (such as HTTP over RPC aka Outlook Anywhere) you really need to test the change on a test server first (preferably on a test domain) as if you revert the snapshot on the Exchange server, it does not undo the changes done in AD (funnily enough…)
USN rollback is when a domain controller is restored from backup or reverted from a snapshot
There is a good article here explaining it.
Short answer is never revert a snapshot or backup without really thinking about the resultant issues that may result
Application Server with remote database connection or some form of replication
A classic where would be upgrading an application server. It stores some information on the application server, but the majority in a remote SQL database. If your upgrade fails, without rollback of the application server and SQL Server information, you may get an inconsistency between what the application server is thinking is ok and what the SQL server thinks is OK. Always follow and verify the vendors backup and restore processes
Another classic here would be when you patch an exchange server with CCR.