Re: Recursive delete file from all subvolumes (snapshots)

[Duncan <1i5t5.duncan@cox.net>]

Wolfgang Mader posted on Fri, 15 Jan 2016 14:33:27 +0100 as excerpted:

>> 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.

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.

-- 
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