# Practical limit on the number of btrfs snapshots?

I am considering using btrfs on my data drive so that I can use snapper, or something like snapper, to take time based snapshots. I believe this will let me browse old versions of my data. This would be in addition to my current off site backup since a drive failure would wipe out the data and the snapshots.

From my understanding btrfs snapshots do not take up much space (meta data and the blocks that have changed, plus maybe some overhead), so space doesn't seem to be a constraint.

If I have a million snapshots (e.g., a snapshot every minute for two years) would that cause havoc, assuming I have enough disk space for the data, the changed data, and the meta data?

If there is a practical limit on the number of snapshots, does it depend on the number of files and/or size of files?

As someone who is using a btrfs filesystem with Arch Linux for almost 2 years now I can safely say that there does not seem to be a practical limit on the number of snapshots that can be easily reached. There are some caveats though. btrfs filesystem can lead to fragmentation. It is therefore advisable to use the online defragmentation feature built into btrfs. Furthermore, one can make good use of btrfs's compression feature. These measures should take care of most performance issues that could sensibly arise on a reasonably decent computer from creating a lot of snapshots.

As you might know btrfs treats subvolumes as filesystems and hence the number of snapshots is indeed limited: namely by the size of files. According to the btrfs wiki the maximum filesize that can be reached is 2^64 byte == 16 EiB[1].

Aside from these limitations there can potentially always be problems when you run out of space without you immediately recognizing because checking for free space on btrfs filesystems can sometimes be tricky, i.e. without being able to differentiate between different methods of measuring free space on a btrfs filesystem one can easily use track of what amount of space is actually left. One possible way to prevent this scenario is the use of quota. This ensures that users (or the user if it is only one) can only use a certain amount of space. This concept is discussed very ably here and also here.

Last but not least a warning: I am no expert on btrfs filesystems and only read about these things when I had the same question a while ago. Furthermore, there is always the problem that btrfs is a "fast moving target" (Nice wording being stolen from an Arch Linux wiki page I think.) so things might change.

• Im one of those earlier adopters as well, and this is bang-on. – mikeserv Jul 31 '14 at 13:58
• Yep pretty much bang on :) – Mark K Cowan Apr 6 '15 at 20:08
• You should try to stay below 100 snapshots on one BTRFS volume. Otherwise you may encounter performance issues, especially on deleting snapshots. Creating snapshots is low cost, but deleting them is not. Also, note that the recommendation to perform defragmentation along with using snapshots will eliminate the space efficiency of snapshots. Defragging breaks the reflinks and multiplies the space used. – MountainX Nov 1 '17 at 2:21
• @MountainX can you elaborate on this in an answer. 100 snapshots on a volume is not even one a week for two years. – StrongBad Jan 12 '18 at 16:10
• @StrongBad - I received that info from the BTRFS mailing list in response to a problem. Everyone agreed that it is a bad idea to have many hundreds or thousands of snapshots. For a more technical answer, you would have to ask on the BTRFS mailing list. – MountainX Jan 12 '18 at 20:17

While technically there is no limit on the number of snapshots, I asked on the BTRFS mailing list:

The (practical) answer depends to some extent on how you use btrfs.

Btrfs does have scaling issues due to too many snapshots (or actually the reflinks snapshots use, dedup using reflinks can trigger the same scaling issues), and single to low double-digits of snapshots per snapshotted subvolume remains the strong recommendation for that reason.

But the scaling issues primarily affect btrfs maintenance commands themselves, balance, check, subvolume delete. While millions of snapshots will make balance for example effectively unworkable (it'll sort of work but could take months), normal filesystem operations like reading and saving files doesn't tend to be affected, except to the extent that fragmentation becomes an issue (tho cow filesystems such as btrfs are noted for fragmentation, unless steps like defrag are taken to reduce it).

It appears that using snapshots as an archival backup similar to time machine/snapper is not a good idea.

• Time Machine is not an archival backup, it's a backup. I don't share your conclusion. Using btrfs snapshots can be a very good idea for Time Machine like backups (because the Linux kernel is not able to link a directory, thus causing to recreate the complete directory structure for every snap, which can cause considerable disk space usage). For a backup on a single backup device, without wishing to add additional devices, there is not even a purpose in running a balance command. The btrfs list answer also tries to explain this. – Pro Backup Feb 7 '18 at 22:54
• @ProBackup the btrfs list answer says keep the number of snapshots to single to low doubt-digits which the arch default for snapper does not really do. While btrfs-balance is not needed for a simple setup, a lot of users like the idea of btrfs-check, even if they never need it, and subvolume delete seems critical if you want to rotate subvolumes the way snapper does. – StrongBad Feb 7 '18 at 23:17
• @ProBackup archival backup is probably not the right term for Time Machine. It seems like time machine is more than just an incremental backup, but I wasn't comfortable calling it a snapshot based backup like snapper or rsnapshot, but maybe that would be better. Happy for you to edit the term as it sounds like you know a lot about the field. – StrongBad Feb 7 '18 at 23:24
• From what I read on the homepage of snapper, snapper is not a backup tool. Despite that snapper can go back in time, doesn't mean that it is like Time Machine. The essential difference is that Time Machine stores copies of all data an a separate medium, where snapper might not even create a copy. – Pro Backup Feb 7 '18 at 23:25
• @ProBackup finally, please write an answer and explain why my conclusions about the the answer on the mailing list are wrong. That way we can see how the community feels. – StrongBad Feb 7 '18 at 23:25

You can have a combined total of 264 snapshots and subvolumes.

The btrfs design wiki page says (empahsis mine):

Subvolumes are basically a named btree that holds files and directories. They have inodes inside the tree of tree roots and can have non-root owners and groups. Subvolumes can be given a quota of blocks, and once this quota is reached no new writes are allowed. All of the blocks and file extents inside of subvolumes are reference counted to allow snapshotting. Up to 264 subvolumes may be created on the FS.

Snapshots are identical to subvolumes, but their root block is initially shared with another subvolume. When the snapshot is taken, the reference count on the root block is increased, and the copy on write transaction system ensures changes made in either the snapshot or the source subvolume are private to that root. Snapshots are writable, and they can be snapshotted again any number of times. If read only snapshots are desired, their block quota is set to one at creation time.