From btrfs Wiki
Jump to: navigation, search
Note: The autosnap functionality is currently not included in upstream version of btrfs

Using autosnap feature you could configure btrfs to take regular or event based snapshots and further manage the snapshots automatically.

btrfs autosnap design rationale

  • simple
  • integrate with the existing tools instead of introducing new pkg / script
  • core feature is to facilitate application layer to trigger and auto-manage the snapshots


Configuration concepts in btrfs autosnap

Time based autosnap are pre-configured periodical snapshots to work in conjunction with the backup scripts. The pre-configured frequency are minute, hourly, daily, weekly, monthly, yearly. or your could specify any cronjob entry to trigger btrfs autosnap.

Event based autosnap are typically used to snapshot the subvol before or after patch/package add/remove OR for that matter any application script writing to the subvol which you wary about, where you would have an option of reviewing and do that role-over. Here you would generate a configured autosnap tag which in these application has to call before or after such an event.

Managing the autosnap snapshots

autosnap is not just about taking the snapshot but also managing the created snapshots as of now you could configure autosnap to either delete the snapshots based on filesystem used space and or by number of snapshot that should be preserve for a particular frequency / tag. That means to say you could configure an hourly snapshot which takes snapshot every hour and retain 24*7 of them, which means you have file system snapshots for the entire week at every hour. See more examples below.

No identical consecutive snapshots

When there is no write/modification either in the data or metadata you might want not to take any snapshot, so there is an option (enabled by default) to have your (frequency/event based) snapshots taken and preserved only if there is a change in the filesystem.


In an effort to make autosnap more interesting here is the timeslider for btrfs (this was originally implemented in JDS). Timeslider is a nautilus python extension which when on a btrfs subvol will show all its snapshots on a scale marked with snapshot date and time, you could slide the time-scale backward to view the contents of the subvol back in time.




Follow the instructions in the README file to install.


Slide the scale back which shows the locations of the snapshot now press enter to go to that location. To hide the Timeslider, select Edit -> 'Timeslider show/hide'

Example configuration


Takes autosnap of subvol '/btrfs/sv1' every 15 mins (only if there is any change in the '/btrfs/sv1') and retains up to latest 8 snapshots.

# btrfs autosnap enable -m 15 -c 8 /btrfs/sv1
	subvol: /btrfs/sv1 tag: @minute retain: 8 identical: older

# btrfs au show /btrfs/sv1
tag	retain	identical	subvol
@minute	8	older		/btrfs/sv1
autosnap threshold 75%, /btrfs 11% full

Since we are using a pre-configured frequency you could check crontab for the updated crontab entry.

# crontab -l
#BEGIN autosnap entry
*/15 * * * * /usr/local/bin/btrfs autosnap now -t @minute /btrfs/sv1
#END autosnap entry

Set the autsnap to delete older snapshot if the /btrfs used space is more than 80% (threshold).

# btrfs au fslimit -n 80 /btrfs
'/btrfs' autosnap threshold set at 80%
		 Snapshot delete works in async manner, until there is a way
		 where btrfs can provide more accurate disk space info, this
		 feature can not be very effective.

Check your configuration

# btrfs au show /btrfs/sv1
tag	retain	identical	subvol
@minute	8	older		/btrfs/sv1
autosnap threshold 80%, /btrfs 11% full

List snapshots drill down by parent.

# btrfs su list -t parent=/btrfs/sv1 /btrfs
/btrfs/.autosnap/6c0dabfa-5ddb-11e1-a8c1-0800271feb99 Thu Feb 23 13:01:18 2012 /btrfs/sv1 @minute

Since option identical is active to keep older and /btrfs/sv1 is idle there is only one autosnap created.

# touch /btrfs/sv1/anand

# btrfs su list -t tag=@minute,parent=/btrfs/sv1 /btrfs
/btrfs/.autosnap/6c0dabfa-5ddb-11e1-a8c1-0800271feb99 Thu Feb 23 13:01:18 2012 /btrfs/sv1 @minute
/btrfs/.autosnap/5669613e-5ddd-11e1-a644-0800271feb99 Thu Feb 23 13:15:01 2012 /btrfs/sv1 @minute

Check /var/spool/mail/root for cron logs. The below log shows that the latest autosnap was deleted because it was identical to the previous autosnap.

From: root (Cron Daemon)
To: root
Subject: Cron <root@localhost> /usr/local/bin/btrfs autosnap now -t @minute /btrfs/sv1
Create a snapshot of '/btrfs/sv1' in '/btrfs/.autosnap/9f8c26b6-5de3-11e1-8b89-0800271feb99'
Newer snapshot is identical to the previous snapshot, deleting the newer
Delete subvolume '/btrfs/.autosnap/9f8c26b6-5de3-11e1-8b89-0800271feb99'


Configure autosnap with a user defined tag 'nightly', retain 7 snapshots (and take snapshot only if the workspace has any change - default).

# btrfs au enable -t nightly -c 7 /btrfs/workspace
	subvol: /btrfs/workspace tag: nightly retain: 7 identical: older
	command to call in the script:
	btrfs autosnap now -t nightly /btrfs/workspace

This provides the btrfs autosnap command to be called in the script, here in this case you need to update the crontab to call the command at specific time as below. Note: crontab manual entry should be OUTSIDE of the autosnap BEGIN and END marks.

# crontab -l
#BEGIN autosnap entry
*/15 * * * * /usr/local/bin/btrfs autosnap now -t @minute /btrfs/sv1
#END autosnap entry
0 0 * * * /usr/local/bin/btrfs autosnap now -t nightly /btrfs/workspace


Enable autosnap with a tag pkg, -s to self maintain the autosnap, which means no snapshot will be deleted and the identical (-n) is disabled.

# btrfs au enable -t pkg -s -n disable /btrfs1/packages
	subvol: /btrfs1/packages tag: pkg retain: -1 identical: disable
	command to call in the script:
	btrfs autosnap now -t pkg /btrfs1/packages

Now set the /btrfs1 threshold at 95%, where 'btrfs au fslimit -c /btrfs1' would check if the /btrfs1 disk-usage exceeded the threshold and would delete an autosnap snapshot if otherwise.

# btrfs au fslimit -n 95 /btrfs1
'/btrfs1' autosnap threshold set at 95%
		 Snapshot delete works in async manner, until there is a way
		 where btrfs can provide more accurate disk space info, this
		 feature can not be very effective.

# btrfs au fslimit -c /btrfs1

[In the long run I would expect the above command to be associated with the system disk usage monitoring tool, and the autosnap dir to be associated with the quota system, check future enhancements section for more info]

Caveat: Known bugs and Limitations

  • Renaming the mount point / subvol

You should not change the btrfs mount-point nor rename/move subvol, this would result in autosnap and timeslider resulting in error. Surely this is a bug.

Workaround: Start afresh, reconfigure the autosnap and delete all older autosnap created snapshots.

Status: Fix in progress.

  • Space management

There is no good way that a btrfs kernel can let the application layer know the space consumed by the snapshot that is space taken up COW. And further the snapshot delete works in asynchronous manner, so application layer as of now can be accurate in this area.

Workaround: When filesystem reaches threshold, the autosnap would delete one oldest snapshot and then stop. Further system admin has to wait and determine if further autosnap delete would be required and run (btrfs au fslimit -c) accordingly to delete next oldest snapshot.

Status: btrfs space management application interface is work in progress, autosnap should be updated when that's ready.

  • Timeslider redirecting the nautilus URI to a new location doesn't work as of now

This is because, I had the challenge to make the Timeslider work entirely using its python extension and as of now its not possible to redirect the nautilus URI to a new location from the python extension.

Workaround: Please press enter when you slide the timeslider should go into the location in the snapshot.

Status: Planning.

  • Autosnap-ing the btrfs mount point

This is not recommended since autosnap-ing the mount point will create snapshot of the snapshots as the autosnap snapshots are placed under /mount-point/.autosnap/. And so two consecutive snapshots will never be identical even though there isn't any real write on the filesystem. Autosnap is mainly designed for subvols on a mount-point. And configuring the autosnap for the root is really bad thing to do as of now.

  • btrfs should be accessible to enable or disable the autosnap

The mount point has to be mounted and accessible to disable the autosnap config. This is a kind of limitation rather than a bug, since we need to access the subvol before we could determine the its mount point.

Workaround: If you want to clean up then manually delete the config file '/etc/autosnap/config' and the contab entries if any.

Future plans

  • add 2D snapshot scale graph, X=time Y=snapshot-size
  • cli and gui: to show snapshot COW size
  • Services to monitor file-system available free space
  • .autosnap directory as a subvol and associate it with the quota
  • better cli syntax
  • Associate 'btrfs autosnap now' with the package manager and 'btrfs autosnap fslimit' with the disk space manager utility.


Other similar solutions which I found during the survey, autosnap is created in a view to avoid redundancy and compliment the other existing solution.

  • Snapper:
Personal tools