by doing this,
# btrfs subvolume snapshot /mnt/1 /mnt/1/snapshot
# tree /mnt/1
/mnt/1
├── a
├── snapshot
│ ├── a
│ └── subv
└── subv
└── b
3 directories, 3 files
We can create snapshot from /mnt/1 on btrfs.
My question is: what is advantage of using snapshot , than using rsync to simpaly backup filesystem?
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:
Snapshots don't do backups. Think of them as fancy set of copy-on-write hardlinks (that are consequently limited to the same btrfs partition) that you will be able to mount as a seemingly separate filesystem (in future you will be able to use different mount options for each subvolume (=snapshot) ).
Only with rsync you actually copy the data.
In BTRFS, thanks to the immutability of the actual data stored on disk (unless you mount with --nodatacow) it is possible to have two copies of the identical file stored in the shared area on the drive, but without any side effects of either symlinks nor hardlinks. There is even a tool "bedup" that scans your btrfs partition and frees hard drive space used by identical files.
This BTRFS feature also integrates with the cp program: from the user perspective the cp --reflink <source> <dest> does not differ from normal copying, although is many orders of magnitude faster. It does not actually copy the data. The copy will be done transparently by the filesystem, whenever you try to actually modify any either destination or source files. And this is true for any file you modify, not only ones, that have been copied with --reflink. That's why it is called COW system (COW = Copy On Write)
The main difference between a snapshot and a copy with cp -a --reflink to the same filesystem is that the snapshot is much faster (near instantaneous); performance doesn't depend on how many files there are in the original subvolume. There is also a less fundamental difference, which I do find a bit inconvenient: snapshotting only copies the volume itself, and nested subvolumes will appear as empty directories inside the snapshot. For completeness, the --reflink flag asks cp to use the reflink syscall, which is fast and enables space sharing on COW filesystems, instead of copying the data by reading from one file and writing into the other.
Snapshots can be sent to another BTRFS lying on a separate disk or machine using btrfs send. This operation can be extremely fast and efficient when performing incremental snapshot transfers since BTRFS will only send the differences since the last transferred snapshot. This is superior to rsync/cp in many cases (https://btrfs.wiki.kernel.org/index.php/Incremental_Backup)
I do not think you can send an rsync'd folder via btrfs send. Same for a folder copied via cp -a --reflink=true
Also, the accepted answer (from Michael) does not include the fact that for Btrfs, you can use cp -a --reflink=true which behaves in many aspects as a snapshot of an arbitrary directory. Meaning "until the data actually changes, no additional physical copy of the data is made." (so no extra space is used and the operation is extremely fast).
Also note that cp -a --reflink=true is different from cp -al. Only the common blocks are referenced, so modifying one file does not modify the other. As far as I know ZFS does not support this feature.
