Since this can concern filesystems, databases, version control systems, and other things, I'll just use the term "data" for whatever it is you're backing up or snapshotting, and "system" for the database or filesystem driver.
"Backup" is the easiest to define: it's a dataset that contains everything needed to restore the data to the state it was when the backup was done. Hopefully, the backup is consistent, that is, it will restore the data to exactly the point in time the backup was made. If some changes were done to the data during the backup process, they should not be included in the backup, since that would break consistency.
For example, zipping a directory into an archive is not guaranteed to be consistent: if some of the files change during the process, what version will be included in the zip is up to anyone's guess. For the same reason, filesystem backups done with tools like rsync (among others) are better than nothing, but they're not guaranteed to restore into a consistent state. In fact, if you're backing up a live database by copying the files, it's pretty much guaranteed to result in garbage.
"Snapshot" is the solution to the above problem. The snapshot is not data you can see directly, it is a feature offered by a database or filesystem. When you ask it to take a snapshot, it gives you a virtual view of the data, frozen in time, as it was when the snapshot was taken. Unlike a backup, which is a bunch of files that exist independent of the application they came from, a snapshot only exists as internal state within the system. It's basically a time travel portal that allows you to look at your data as it was when the snapshot was taken. So the snapshot itself cannot be copied to another machine, because it's not a file. But we usually also call "snapshot" the data you can read through this time portal and actually copy, so you could say you "copied a snapshot" meaning you copied the data.
Usually you can access your snapshot in the same way as you access your data, for a filesystem the snapshot will present as a read-only filesystem, for a database it will look just like a read-only version of the live database with SQL queries, etc.
Implementations are system dependent, but the general idea is that when a write occurs, the data that would be overwritten but can still be seen by any snapshot taken in the past cannot be simply overwritten. Instead the system has to keep separate versions of the modified rows, and keep track of which snapshot can see which version.
All multiuser transactional databases must make snapshots in order to work. Usually it's called "transaction isolation level" which determine when these are made. For example, a snapshot can be made at the beginning of each query. Then the query executes without seeing modifications to the tables that are done while it runs. Otherwise the query wouldn't have a consistent view of the database, foreign key relations would break, etc.
Now once you have your snapshot, you can do several things with it:
You can take a snapshot, then do some modifications. If you don't like the result, roll back to the snapshot.
If you run your normal backup program on your filesystem or database snapshot, it's guaranteed the data it sees won't be modified during the copy process. Therefore, your backup will be consistent.
For example if you do a ZFS snapshot and then zip it or rsync it to another machine, then that backup will restore your data exactly as it was. If the data comes from programs that write files without crash recovery or transaction logs (ie, MyISAM) it will still be unusable, but that's not the snapshot's fault.
Most systems that allow snapshots for backup purposes will offer a faster way to do that backup than copying files or dumping SQL. That usually results in a huge file that contains all your data.
- You can make incremental backups
Because snapshots imply version tracking, if you take a snapshot on Sunday and make a full backup of it, then take another snapshot on Monday... then, usually, the system will offer the possibility to do an incremental backup: that's a file that contains only the changes between the two snapshots. If you have huge data but only a small part of it changes, this will make your backups much faster.
On restore, you would restore the full backup from Sunday. Then you can stop there, or restore the incremental backups (in order) to get the data back to the point in time you want.
- You can fork it or branch it
The snapshot being read-only is not a requirement. Nothing stops the developers from making it read-write. In this case it will not change the data as it was when the snapshot was taken, but simply fork it into a writable copy, while not having to actually store it all twice. I don't think any SQL database allows this kind of time travel paradox in their database, but this is how all source code version control systems work, like git for example.
Anyway, I hope that clears things up. A backup is a bunch of files. A snapshot is a time portal.
I have no idea what an "image" of a database is supposed to be.
It's a bit fuzzy since the term can be applied to both a snapshot or a backup. For example a "disk image" like .iso is a file that contains the whole contents of the disk. So it's a backup of the disk. Some also call a snapshot an image too. But the "image" term also conveys the notion that you'll be able to access it directly like it was the real thing, for example you can mount an ISO, but you can't run SQL queries on a database SQL dump, which is just a bunch of text files.