mjhjmtu

On my debian system, I am using hdds formatted with btrfs to make backups. The large volumes of data are my music and photo collections so it tends to be relatively stable and only growing.

I mount the btrfs volume in /media/backup, then I have a subdirectory backup and within that I have directories for the various sets of backup I am making. After I do the nightly backup, I make a snapshot.

DATE=$(date +"%Y%m%d_%H%M")
btrfs subvolume snapshot /media/backup /media/backup/$DATE

For the first day, this worked as expected, but the next day, the snapshot also contained the first days snapshot, the day after the snapshot contained the two first snapshots and so on..

If I have understood correctly what happens when I do a btrfs snapshot, this has no practical implications, the usage of disk space is absolutely marginal, but as it looks a bit messy, I would like to avoid it. My first idea was to do a snapshot of /media/backup/backup to avoid this, but as I tried to make a snapshot of a directory rather than a volume, that did of course not work.

Is there any way I can make a number of snapshot of the same volume and avoid having the newer snapshot also point to all the older ones?

First off, if you look at the most recent snapshot, you will notice that the directories from the previous snapshot don't contain any actual data inside the new snapshot, so it's not just marginal disk usage, it's zero extra.

Now, as to avoiding them, the only way to do so is to store your snapshots somewhere that isn't covered by the snapshot process. For this, you essentially have two options:

1. 
   

   Create a dedicated subvolume for your snapshots inside the subvolume you're snapshotting. Snapshots stop at subvolume boundaries (which is the reason that they won't store copies of existing snapshots), so you won't have any of them in your snapshots, just an empty directory for the snapshots subvolume. This is probably the easiest option to adopt right now, as it just requires creating the subvolume with btrfs subvolume create and pointing the snapshot creation script there for the location to store the snapshots. For what it's worth, .snapshots seems to be a de-facto standard name for this approach. After a few days of using this your directory tree would look roughly like this:

   
   
   

   /media/backups
   /media/backups/.snapshots
   /media/backups/.snapshots/20180207_1342
   /media/backups/.snapshots/20180209_0415
   /media/backups/.snapshots/20180312_1754
   

   
   
   

   All your non-snapshot data is in /media/backups, and all your individual snapshots are stored under /media/backups/.snapshots. Each snapshot will have an empty .snapshots directory in it.

   
   


2. 
   

   Instead of using the root subvolume of the BTRFS volume, put all your actual data in it's own subvolume, and snapshot that while placing the snapshots outside of it. This approach is not as easy to convert to, and will likely require you to update more than just your snapshot command, but also makes it easier to roll-back an entire snapshot all at once. After a few snapshots using this method, your directory tree would look something like this:

   
   
   

   /media/backups/current
   /media/backups/20180207_1342
   /media/backups/20180209_0415
   /media/backups/20180312_1754
   

   
   
   

   All your data is stored in /media/backups/current (which needs to be a BTRFS subvolume just like .snapshots does with the first method), and your snapshots sit alongside it under /media/backups. You can easily restore an entire snapshot by simply deleting the current subvolume and creating a writable snapshot called current of the snapshot you want to restore.

   
   

Now, there are two other observations I would like to make regarding what you've said that aren't directly part of your question:

1. The command you listed will create writable snapshots. This is almost certainly not what you want if your purpose here is to maintain archival copies of your collection, so I would suggest adding -r to the options to make the snapshots read-only. In the event you need to modify one (for example, if you need to completely purge a file from the collection), you can still use the btrfs property set command to toggle the read-only flag on the snapshot.


2. While not technically a significant issue, your timestamp format is somewhat unconventional, and as such may cause you problems if you try to deal with these snapshots with another tool or might confuse other people if you need to share this data. Given that, I would suggest using `'%FT%T', which will give you an ISO 8601 timestamp that should be parsable by all software and immediately recognizable to most people, while still providing sensible lexical sorting of the snapshots.