btrfs, linux, shell

Easy sync BTRFS snapshots with btrfs-sync

To complement the last BTRFS tool btrfs-snp (which allows us to schedule snapshots), I would like to share a new tool to synchronize them locally or remotely  to achieve efficient data redundancy.

With btrfs-snp we can replicate our BTRFS snapshots in a different BTRFS system, and have a second copy of our versioned subvolume in a much more efficient manner than using the traditional rsync.


  • Local or remote sync through SSH
  • Simple syntax
  • Progress indication
  • Support for xz or pbzip2 compression in order to save bandwidth
  • Retention policy
  • Automatic incremental synchronization
  • Cron friendly


The syntax is similar to that of scp



Synchronize snapshots of home to a USB drive

Synchronize snapshots of home to a USB drive in another machine

Synchronize one snapshot of home to a USB drive in another machine

Synchronize only monthly snapshots of home to a USB drive in another machine

Use --verbose  to get more details


Daily synchronization over the internet, keep only last 50

Daily synchronization in LAN, mirror snapshot directory


Get the script and make it executable. You can do this in two lines, but better inspect it first. Don’t trust anyone blindly.

It is recommended to set up a designated user for receiving the snapshots that has sudoers access to the  btrfs  command.

  • Create a btrfs user at the both ends

  • Create a public key in your sending machine

  • Give passwordless access to the btrfs user at the remote machine.

  • Give permissions to the btrfs user to use the btrfs on both ends. Create a file

with the contents

If you want to run it from cron, you might have to install it first because some distributions have already completely replaced it by systemd timers.

This was the case for me in Arch Linux. In my case, I installed cronie.

cronie logs the output to the system log by default, but you can set an email system if you want old style cron mails.

Also, note that you can use chronic if you only want logging to occur only if something goes wrong.

Comparison with rsync

The main difference between these two methods is that BTRFS works at the block level, whereas rsync works at the file level.

Because rsync works with files, it will not detect things such as renaming or moving a file, so it can only send it again. Also, it needs to analyze the existing files at the destination to see if they have been updated or not.

In order to achieve this, it can either analyze modification dates and sizes, which is relatively fast, or compare checksum of file chunks at both ends which is more robust but slower. In any case, there will be a significant processing overhead when you are synchronizating a whole partition with many thousands of files.

A plus of this approach is that you are able to exclude certain files or folders, where BTRFS works by subvolumes in an all or nothing fashion.

BTRFS on the other hand understands blocks, and because it is a COW filesystem, it already knows what bytes have changed between a snapshot and the next. If we renamed the file, only some tiny metadata has changed, and BTRFS knows that we don’t need to transfer the whole file again, only those few bytes.

The same happens when a big file changes internally, such as an image file for a virtual machine where we have been working.

This is the same reason why snapshots in COW filesystems are so space efficient, allowing us to create instant safety copies of huge volumes that only takes extra space as we change the files in them.

Obviously a drawback is that you need a BTRFS filesystem at both ends, but why would we stick to an old generation filesystem where we now have more modern and featureful ones?



Author: nachoparker

Humbly sharing things that I find useful [ github dockerhub ]

One Commnet on “Easy sync BTRFS snapshots with btrfs-sync

Leave a Reply

Your email address will not be published. Required fields are marked *