Recursive delete file from all subvolumes (snapshots)
Dear all,
I have a btrfs raid 10 from which I take hourly snapshots using snapper. Now, I wonder, if there is a way to delete a file together with all its occurrences in all snapshots.
My use case is, that the file I want to delete is large, and I want to free its space on disk. Thus, I have to get rid of its "live" version but also of all references to it in snapshots.
Thank,
Wolfgang
Quoted 7 lines · On Fri, 15 Jan 2016 09:33:14 +0100 Wolfgang Mader…
I have a btrfs raid 10 from which I take hourly snapshots using snapper. Now, I wonder, if there is a way to delete a file together with all its occurrences in all snapshots.
My use case is, that the file I want to delete is large, and I want to free its space on disk. Thus, I have to get rid of its "live" version but also of all references to it in snapshots.
E.g. if your file is at /path/to/file.dat, and your snapshot structure is /snapshots/YYYY-MM-DD@time/, you would simply do:
rm /snapshots/*/path/to/file.dat
In fact this is what I often do with my timed snapshots when deleting some files and wanting to recover free space immediately, not waiting for all their snapshots to expire and get deleted by the usual time-based deletion rules.
If your snapshots are read-only it becomes more complex, but still doable.
Signature · 2 lines
With respect, Roman
Quoted 14 lines · CET Roman Mamedov
On Fri, 15 Jan 2016 09:33:14 +0100
Quoted 7 lines · Wolfgang Mader
I have a btrfs raid 10 from which I take hourly snapshots using snapper. Now, I wonder, if there is a way to delete a file together with all its occurrences in all snapshots.
My use case is, that the file I want to delete is large, and I want to free its space on disk. Thus, I have to get rid of its "live" version but also of all references to it in snapshots.
E.g. if your file is at /path/to/file.dat, and your snapshot structure is /snapshots/YYYY-MM-DD@time/, you would simply do:
Quoted 8 lines
rm /snapshots/*/path/to/file.dat
In fact this is what I often do with my timed snapshots when deleting some files and wanting to recover free space immediately, not waiting for all their snapshots to expire and get deleted by the usual time-based deletion rules.
If your snapshots are read-only it becomes more complex, but still doable.
Neat idea.
Thx.
Roman Mamedov posted on Fri, 15 Jan 2016 14:05:39 +0500 as excerpted:
Quoted 5 lines
Quoted 2 lines · On Fri, 15 Jan 2016 09:33:14 +0100 Wolfgang Mader…
I have a btrfs raid 10 from which I take hourly snapshots using snapper.
Hopefully you have snapper setup with a good thinning program as well, as ideally, you want to keep your snapshots to 250-ish per subvolume and a thousand or two per filesystem, maximum, for scaling reasons, and hourly snapshots will eat up that 250 target in 10 days, 10 hours...
But it's quite possible to start with hourly snapshots, thinning to say 6- hourly (four per day, deleting 5/6) after a couple days, and continuing to thin down to say weekly after several weeks, then keeping weekly snapshots for a year before deleting them to recover the space and resorting to proper backups if anything older needs recovered, and stay under 200 snapshots per subvolume.
That'll help keep your btrfs healthy and your btrfs maintenance commands (scrub, balance, check, etc), if needed, running in something like reasonable time. =:^)
Quoted 2 lines
Quoted 2 lines
Now, I wonder, if there is a way to delete a file together with all its occurrences in all snapshots.
If the file was there at the time of the snapshot, it's part of the snapshot and to remove it when deleting a file from the working set rather defeats the purpose, tho of course with writable snapshots, you can delete it from the snapshot manually (see RM's method below), and as RM says, with read-only snapshots it's more complex but still possible (see my reply under that bit, further below).
Quoted 7 lines
Quoted 3 lines
My use case is, that the file I want to delete is large, and I want to free its space on disk. Thus, I have to get rid of its "live" version but also of all references to it in snapshots.
E.g. if your file is at /path/to/file.dat, and your snapshot structure is /snapshots/YYYY-MM-DD@time/, you would simply do:
Quoted 6 lines
rm /snapshots/*/path/to/file.dat
In fact this is what I often do with my timed snapshots when deleting some files and wanting to recover free space immediately, not waiting for all their snapshots to expire and get deleted by the usual time-based deletion rules.
Of course that implies that the root containing all the snapshots is itself mounted or otherwise nested in the mounted tree, somewhere. The recommendation is to keep it unmounted and not directly accessible, by default, only mounting the snapshots root when you are directly working with the snapshots.
Among other reasons, there's a security issue if you're snapshots contain old executables including set-UID/GID executables, and they're security updated. If the old vulnerable versions remain accessible to ordinary users, as they will if the snapshots remain routinely accessible within the tree, then it's possible for a user to use them to gain the privs of the user/group (typically root) they run as. If these snapshots aren't normally accessible in the tree, then users won't have access to them and won't be able to use the old and vulnerable versions the snapshots contain to privilege-escalate.
Plus of course, if they're unmounted, they're less likely to be accidentally damaged or deleted.
Quoted 2 lines
If your snapshots are read-only it becomes more complex, but still doable.
Read-only is a snapshot property. As such, it can be toggled via btrfs property set calls. So the idea here would be a script that loops thru the snapshots, doing a btrfs property set writable, rm file, btrfs set property read-only, for each snapshot. Trivial enough shell script. So a bit more complex than if the snapshots are writable in the first place, but far from unmanageably so. =:^)
Signature · 3 lines
Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Quoted 19 lines · CET Duncan
Roman Mamedov posted on Fri, 15 Jan 2016 14:05:39 +0500 as excerpted:
Quoted 5 lines
On Fri, 15 Jan 2016 09:33:14 +0100 Wolfgang Mader
Quoted 2 lines · <[email protected]> wrote:
I have a btrfs raid 10 from which I take hourly snapshots using snapper.
Hopefully you have snapper setup with a good thinning program as well, as ideally, you want to keep your snapshots to 250-ish per subvolume and a thousand or two per filesystem, maximum, for scaling reasons, and hourly snapshots will eat up that 250 target in 10 days, 10 hours...
But it's quite possible to start with hourly snapshots, thinning to say 6- hourly (four per day, deleting 5/6) after a couple days, and continuing to thin down to say weekly after several weeks, then keeping weekly snapshots for a year before deleting them to recover the space and resorting to proper backups if anything older needs recovered, and stay under 200 snapshots per subvolume.
Quoted 3 lines
That'll help keep your btrfs healthy and your btrfs maintenance commands (scrub, balance, check, etc), if needed, running in something like reasonable time. =:^)
Thanks to raise this point. Right now, I have some of my subvolumes snapshoted w/o thinning, but I am aware of the issues arising from too many subvolumes. I have to fix this in a timely manner...
Quoted 25 lines
Quoted 3 lines
Quoted 3 lines
Now, I wonder, if there is a way to delete a file together with all its occurrences in all snapshots.
If the file was there at the time of the snapshot, it's part of the snapshot and to remove it when deleting a file from the working set rather defeats the purpose, tho of course with writable snapshots, you can delete it from the snapshot manually (see RM's method below), and as RM says, with read-only snapshots it's more complex but still possible (see my reply under that bit, further below).
Quoted 7 lines
Quoted 3 lines
My use case is, that the file I want to delete is large, and I want to free its space on disk. Thus, I have to get rid of its "live" version but also of all references to it in snapshots.
E.g. if your file is at /path/to/file.dat, and your snapshot structure is /snapshots/YYYY-MM-DD@time/, you would simply do:
Quoted 6 lines
rm /snapshots/*/path/to/file.dat
In fact this is what I often do with my timed snapshots when deleting some files and wanting to recover free space immediately, not waiting for all their snapshots to expire and get deleted by the usual time-based deletion rules.
Quoted 5 lines
Of course that implies that the root containing all the snapshots is itself mounted or otherwise nested in the mounted tree, somewhere. The recommendation is to keep it unmounted and not directly accessible, by default, only mounting the snapshots root when you are directly working with the snapshots.
As far as I know, snapper puts its snapshots under .snapshots in the root of the snapshoted subvolume. As I want to work with the subvolume, it is mounted, and with it its snapshots. So, according to your answer, I should figure out how to change the location at which snapper places its snapshots. The subvolumes snapper creates as ro, which gives some protection against unwanted changes.
Quoted 10 lines
Among other reasons, there's a security issue if you're snapshots contain old executables including set-UID/GID executables, and they're security updated. If the old vulnerable versions remain accessible to ordinary users, as they will if the snapshots remain routinely accessible within the tree, then it's possible for a user to use them to gain the privs of the user/group (typically root) they run as. If these snapshots aren't normally accessible in the tree, then users won't have access to them and won't be able to use the old and vulnerable versions the snapshots contain to privilege-escalate.
While I can see the issue, I only have music and image files. So this should be no problem for my setup. But good to keep this in mind.
Quoted 13 lines
Plus of course, if they're unmounted, they're less likely to be accidentally damaged or deleted.
Quoted 2 lines
If your snapshots are read-only it becomes more complex, but still doable.
Read-only is a snapshot property. As such, it can be toggled via btrfs property set calls. So the idea here would be a script that loops thru the snapshots, doing a btrfs property set writable, rm file, btrfs set property read-only, for each snapshot. Trivial enough shell script. So a bit more complex than if the snapshots are writable in the first place, but far from unmanageably so. =:^)
Wolfgang Mader posted on Fri, 15 Jan 2016 14:33:27 +0100 as excerpted:
Quoted 6 lines
Quoted 5 lines
Of course that implies that the root containing all the snapshots is itself mounted or otherwise nested in the mounted tree, somewhere. The recommendation is to keep it unmounted and not directly accessible, by default, only mounting the snapshots root when you are directly working with the snapshots.
Quoted 7 lines
As far as I know, snapper puts its snapshots under .snapshots in the root of the snapshoted subvolume. As I want to work with the subvolume, it is mounted,
and with it its snapshots. So, according to your answer, I should figure out how to change the location at which snapper places its snapshots. The subvolumes snapper creates as ro, which gives some protection against unwanted changes.
There's a suggested layout on the wiki:
https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Managing_Snapshots
I'd suggest something like the "even flatter" layout, since it emphasizes that snapshots are simply subvolumes that happen to be a snapshot of whatever subvolume at some particular moment.
That way, as the wiki discusses, rolling back is simply a matter of mounting the appropriate snapshot in place of the what was the working copy.
Tho you do have to ensure that toplevel (ID 5) is mounted any time you're working with snapshots, which means the snapshot creation script (snapper for you I guess) would need to mount it before taking the snapshot, and umount it after -- probably using a lockfile to determine whether it should umount, so you could create that lockfile any time you're working with toplevel mounted manually, to keep the hourly snapshot script from umounting it.
Signature · 3 lines
Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman