Snapshotting can be seen as a special case of, but distinct from, copying.
I'm not really familiar with the specifics of Btrfs, but the following applies to ZFS, from which Btrfs draws much inspiration. Apparently Btrfs snapshots are actually read/write, making them more similar to ZFS file system clones, but that does not change their relationship to file copies.
A snapshot is a read-only, point-in-time copy of the filesystem state.
This works because both Btrfs and ZFS are so-called Copy On Write filesystems. Whenever a block of data is changed, the changed data is written to a location on disk different from the original copy. The primary upside of this is that it greatly increases reliability: because very little data needs to be overwritten in place, there is a greatly reduced possibility of a problem leading to data loss. However, there are also other advantages. One such advantage is that you can do filesystem-level snapshotting efficiently. A major downside is that as your storage fills up, it tends to greatly increase storage fragmentation as the block allocator struggles to find somewhere, anywhere, to physically store the copy. As a matter of fact, it is recommended to keep ZFS pool usage below 80%, presumably not in the least for that exact reason.
A snapshot basically tells the filesystem code "these blocks are still needed". Hence, they won't be reclaimed and potentially overwritten with new data. However, they still reference the same old data blocks.
Now, how is that different from simply making a copy using rsync, cp, cat or whatever? It's different because until the data actually changes, no additional physical copy of the data is made.
It's like hardlinks on stereoids; the same physical on-disk copy of the data is used when accessing a file under different names. The difference is that with hardlinks, a change to the file under one name propagates to every other copy because they really reference the same data blocks. With copy-on-write and snapshotting, the changed blocks only show up in the place where they were changed. (With read-only snapshots, this means in the "current" version of the file.) You also only need to rewrite the blocks that have actually been changed; the remaining blocks are left exactly where they are. For doing things like snapshotting files containing VM disk images for example, this can make a massive difference in amount of data needed to store on the disk.
So, to recap:
- Snapshotting only requires as much disk space as the changed blocks require. Copying requires the number of copies times the size of the file.
- Snapshots are read-only or read/write, depending on file system design. Copies are read/write by design.
- Copies are independent. Snapshots reference the same data blocks as the current version of the file, until the current version of the file changes (in whole or part).