On Friday, January 15, 2016 11:48:11 AM CET Duncan wrote: > Roman Mamedov posted on Fri, 15 Jan 2016 14:05:39 +0500 as excerpted: > > On Fri, 15 Jan 2016 09:33:14 +0100 Wolfgang Mader > > > > <Wolfgang_Mader@xxxxxxxxxxxxx> 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. > > 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... > > >> 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). > > >> 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. > > 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. > > 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. > > Plus of course, if they're unmounted, they're less likely to be > accidentally damaged or deleted. > > > 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. =:^) -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
