Creating a Snapshot
To create a snapshot:
# btrfs subvolume snapshot source [dest/]name
To create a readonly snapshot add the
-r flag. To create writable version of a readonly snapshot, simply create a snapshot of it.
Send/receive a snapshot
A subvolume can be sent to stdout or a file using the
send command. This is usually most useful when piped to a Btrfs
receive command. For example, to send a snapshot named
/root_backup (perhaps of a snapshot you made of
/ earlier) to
/backup you would do the following:
# btrfs send /root_backup | btrfs receive /backup
The snapshot that is sent must be readonly. The above command is useful for copying a subvolume to an external device (e.g. a USB disk mounted at
You can also send only the difference between two snapshots. For example, if you have already sent a copy of
root_backup above and have made a new readonly snapshot on your system named
root_backup_new, then to send only the incremental difference to
# btrfs send -p /root_backup /root_backup_new | btrfs receive /backup
Now a new subvolume named
root_backup_new will be present in
Managing snapshots with Snapper
Snapper was created by openSUSE's Arvin Schnell. It helps with managing snapshots of Btrfs subvolumes. It can create and compare snapshots, revert between snapshots, and supports automatic snapshots timelines.
The following packages use
btrfs send and
btrfs receive to send backups incrementally to an external drive. Refer to their documentation to see differences in implementation, features, and requirements.
The tools listed in section Snapper-based interface with snapper, whereas the ones listed in section Other do not require snapper to be installed. See Btrfs Wiki's Incremental Backup page for a more comprehensive list.
- snap-sync — "Use snapper snapshots to backup to external drive."
- snapsync — "A synchronization tool for snapper"
- btrbk — "Tool for creating snapshots and remote backups of btrfs subvolumes."
- buttersink — "Buttersink is like rsync for btrfs snapshots."
Suggested filesystem layout
Preserving log files
It's recommended to create a subvolume for
/var/log so that snapshots of
/ exclude it. That way if a snapshot of
/ is restored your log files will not also be reverted to the previous state. This makes it easier to troubleshoot.
Keeping many of snapshots for a large timeframe on a busy filesystem like
/, where many system updates happen over time, can cause serious slowdowns. You can prevent it by:
- Creating subvolumes for things that are not worth being snapshotted, like
- Editing the default settings for hourly/daily/monthly/yearly snapshots when using Snapper#Automatic timeline snapshots.
updatedb will also index the
.snapshots directory created by snapper, which can cause serious slowdown and excessive memory usage if you have many snapshots. You can prevent
updatedb from indexing over it by editing:
PRUNENAMES = ".snapshots"
Booting into snapshots
In order to boot into a snapshot, the same procedure applies as for mounting a subvolume as your root parition, as given in section mounting a subvolume as your root partition, because snapshots can be mounted like subvolumes. If using GRUB you can automatically populate your boot menu with btrfs snapshots when regenerating the configuration file with the help of or AUR.
Wrapping pacman transactions in snapshots
Backup non-btrfs boot partition on pacman transactions
/boot partition is on a non btrfs filesystem (e.g. an ESP) you are not able to do snapshot backups with it. You can copy the boot partition automatically on a kernel update to your btrfs root with a hook. This also plays nice together with .
[Trigger] Operation = Upgrade Operation = Install Operation = Remove Type = Package Target = linux* [Action] Depends = rsync Description = Backing up /boot... When = PreTransaction Exec = /usr/bin/rsync -a --delete /boot /.bootbackup