BTRFS snapshots are ‘incremental’. So, the very first snapshot is a clone of your system at the time that snapshot was created.
The second snapshot only contains what changes there were from the first.
The third snapshot only contains what changes there were from the first+second.
And so on.
So, yes, you can delete the fifth snapshot, but for the most part, it will mean that the sixth snapshot just incorporates the changes that the fifth snapshot contained.
If you’re looking to free up space, deleting the fifth snapshot will only do that, if files had been added before the fifth snapshot got created, which then had been removed again before the sixth snapshot got created.
Because then removing the fifth snapshot means those files are completely removed from any snapshots, they don’t need to be remembered anymore.
If between the fourth and the sixth snapshot, you had only ever added files, then deleting the fifth snapshot will free up effectively no space at all.
Not sure I would call them incremental. Nor each snapshot (or even the first) being a clone of the system (which is contradictory to being incremental).
All snapshots ‘contain’ all data relevant to that snapshot. It is just that multiple snapshots can point to the same underlying block of data and when new block of data is written it is copied to a new location so old snapshots can still see the old blocks of data but newer ones see the newer blocks. If you delete a snapshot that is the only thing pointing to some blocks then those blocks are now considered free and can be overwritten. But other blocks that still have other snapshots pointing to them will remain.
So you can delete any snapshot you want and no other snapshots needs to change or incorporate any other changes - they all already point to all the data they need.
Well, the official btrfs docs call it “incremental”, maybe you want to argue with those guys. :P
For example, here it says:
efficient incremental filesystem mirroring and backup
But yeah, I guess, I wasn’t quite accurate there, because I was conflating it with incremental backups.
Semantically, it’s like you have a full copy in the first snapshot, but because of copy-on-write magic, it doesn’t actually need to duplicate the bytes until the data gets changed for the first time.
Still means, though, that deleting an intermediate snapshot will only free up data, if something’s contained in it, which is reverted in later snapshots.
Send/receive of subvolume changes, efficient incremental filesystem mirroring and backup
This is explicitly talking about a different feature that can incrementally sending changes to the filesystem to another filesystem as a backup. Not at all about how snapshots work.
My interpretation was that since send/receive foots on snapshots, those would be related, but I guess, the incremental backup is actually a separate thing.
Some articles online call them “incremental snapshots” as well, which is where I might’ve gotten that initially, but I agree that on a logical level, they’re not that, even if they’re similarly space-saving.
BTRFS snapshots are ‘incremental’. So, the very first snapshot is a clone of your system at the time that snapshot was created.
The second snapshot only contains what changes there were from the first.
The third snapshot only contains what changes there were from the first+second.
And so on.
So, yes, you can delete the fifth snapshot, but for the most part, it will mean that the sixth snapshot just incorporates the changes that the fifth snapshot contained.
If you’re looking to free up space, deleting the fifth snapshot will only do that, if files had been added before the fifth snapshot got created, which then had been removed again before the sixth snapshot got created.
Because then removing the fifth snapshot means those files are completely removed from any snapshots, they don’t need to be remembered anymore.
If between the fourth and the sixth snapshot, you had only ever added files, then deleting the fifth snapshot will free up effectively no space at all.
Not sure I would call them incremental. Nor each snapshot (or even the first) being a clone of the system (which is contradictory to being incremental).
All snapshots ‘contain’ all data relevant to that snapshot. It is just that multiple snapshots can point to the same underlying block of data and when new block of data is written it is copied to a new location so old snapshots can still see the old blocks of data but newer ones see the newer blocks. If you delete a snapshot that is the only thing pointing to some blocks then those blocks are now considered free and can be overwritten. But other blocks that still have other snapshots pointing to them will remain.
So you can delete any snapshot you want and no other snapshots needs to change or incorporate any other changes - they all already point to all the data they need.
Well, the official btrfs docs call it “incremental”, maybe you want to argue with those guys. :P
For example, here it says:
But yeah, I guess, I wasn’t quite accurate there, because I was conflating it with incremental backups.
Semantically, it’s like you have a full copy in the first snapshot, but because of copy-on-write magic, it doesn’t actually need to duplicate the bytes until the data gets changed for the first time.
Still means, though, that deleting an intermediate snapshot will only free up data, if something’s contained in it, which is reverted in later snapshots.
You missed an important part of that quote:
This is explicitly talking about a different feature that can incrementally sending changes to the filesystem to another filesystem as a backup. Not at all about how snapshots work.
Hmm, yeah, I guess I’m wrong there.
My interpretation was that since send/receive foots on snapshots, those would be related, but I guess, the incremental backup is actually a separate thing.
Some articles online call them “incremental snapshots” as well, which is where I might’ve gotten that initially, but I agree that on a logical level, they’re not that, even if they’re similarly space-saving.