by doing this,

# btrfs subvolume snapshot /mnt/1 /mnt/1/snapshot
# tree /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?

5 Answers 5


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).
  • 1
    On BTRFS Snaphots are - be default - read/write. The read-only snapshots were introduced AFAIK with kernel 3.8. Jan 7, 2014 at 9:44
  • @AdamRyczkowski So a Btrfs snapshot is similar to a ZFS clone. That's a good piece of information, although I don't think it has any significant impact on the validity of my answer.
    – user
    Jan 7, 2014 at 9:47

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)

  • Concept of "backups" is very muddy, Adam. Both full copying, zero-time copying (cloning), snapshoting, copying onto other hard drive, copying onto other machine are all considered backups, with different levels of safety so to speak.
    – ArekBulski
    Oct 29, 2015 at 18:59

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.


Spanshots are fast to make and don't consume space for files/blocks that didn't change, sure, but that's just an icing on the cake. Main advantage of spanshots and the reason they exist is consistency. A snapshot is basically a freeze-frame of the whole filesystem, not of each file individually.

This becomes quite important if some files are modified while you're taking a backup. Imagine you have a directory images/ and a database for them - images.sqlite. Programmatically, adding an image looks like this:

  1. Write a new file to images/
  2. Add a row for the new image to images.sqlite

All looks good, database never contains a reference to a file that doesn't exist yet.

Now let's see what can potentially happen if you run rsync in parallel with this:

  1. rsync copies images/
  2. Application writes a new file to images/
  3. Application adds a new row to images.sqlite
  4. rsync copies images.sqlite

... and now your rsync copy contains a database with a reference to a file that's not present in the copy.

A spanshot avoids this problem by freezing the state of the whole filesystem at once, i.e. it will either have both the file and the row in the database, only the file, or none of them; never only the row.

Of course, a snapshot alone is not actually a backup - it still resides on the same disk partition and is likely to be destroyed if the filesystem gets corrupted.

For the above reasons it's often preferable to run rsync (or any other backup tool) on a snapshot, rather than the live filesystem, to get a consistent backup. And more comprehensive backup solutions usually take snapshots behind the scenes before copying anything.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .