Re: [Burp-users] include vs. filesystem boundaries

[Graham K. <gr...@gr...>]

On Sat, Aug 07, 2021 at 09:46:13AM +0200, Pascal Suter via Burp-users wrote:
> Hi
> 
> i am in the process of migrating my backup from a self written rsync wrapper
> to burp. I am having some difficulties wrapping my head around how burp
> works with corssing filesystems and the difference between the "include" and
> "cross_filesystem" config options
> 
> for the following let's assume i have a linux installation with these
> mounts:
> 
> /dev/sda1 -> /
> /dev/sda2 -> /boot
> 
> inside my /boot directory i have two sub directories, /boot/grub and
> /boot/test
> 
> in my config on the burp client i have set cross_all_filesystems=0
> 
> i want to backup only / and /boot/test but nothing else from /boot should be
> backed up
> 
> after some playing around, i found the following config to probably be the
> best solution for what i want:
> 
> include=/
> cross_filesystem=/boot
> exclude=/boot
> include=/boot/test
> 
> here is what else i have tested:
> 
> # test 1
> 
> include=/
> include=/boot/test
> 
> -> this does not backup anything in /boot, it just contains the empty
> mountpoint - this was unexpected, coming from rsync, i would have expected
> this to do what i actually wanted :)
> 
> # test 2
> 
> include=/
> cross_filesystem=/boot/test
> 
> -> same as above, emtpy /boot in my backup - that was expected as the
> manpage says that cross_filesystem should be given mountpoints of fileystems
> to cross, so no surprise there
> 
> # test 3
> 
> include=/
> include=/boot
> 
> -> this backed up the entire boot directory and all its contents, so it
> seems to automatically trigger the cross_filesytsem in the background
> 
> # test 4
> 
> incldue=/
> include=/boot
> exclude=/boot
> include=/boot/test
> 
> -> this resulted in /boot/test and its contents being in the backup twice,
> but other than that nothing else from /boot was in there.. so short of
> creating duplicates this did almost the same as my final solution
> 
> so my question is: is my solution above with setting cross_fileystem to the
> mount point, then excluding the mount point and finally including what i
> really want to backup currently the actual way to go or is there a more
> elegant solution to it?
> 
> a change i would request to make this more intitive: At least for me (as a
> long time rsync user i have to admit, so i might be biased here) it seems a
> lot more intuitive to use the configuration of my "test 1" to achieve what i
> wanted here. especially since "test 3" showed, that when I include a
> mountpoint it automatically crosses over to that filesystem, which I totally
> agree on doing.
> 
> Now if that change was made, and the syntax as used in "test 1" implied
> automatically that crossing into the /boot filesystem was allowed, I  think
> there might be no reason to keep the "cross_filesystem" config option any
> longer as it would just be a sort of a limited synonym for "include" that
> only works on mountpoints :) .. frankly i think this would make things a lot
> easier to comprehend
> 
> the behavior in "test 4" may be expected for someone who knows the internals
> of burp but from a newbie user point of view this is a bug. I see no reason
> to ever have the same file contained twice i the same backup.
> 
> 
> with all that said, thanks for writing, maintaining and most importantly
> sharing burp! it looks like an awesome tool to me :) I have had burp on the
> radar for a while, sort of used it a long time ago to try to backup some
> windows notebooks of friends and family but got lazy on maintaining the
> setup after a while.. now i am "back" moving over from my own rsync based
> backup script due to the ever increasing danger of ransomware worms and what
> they can do to other types of backups. in case you are interested in a
> long(er) read and my thought process that brought me over to burp, have a
> look at http://wiki.psuter.ch/doku.php?id=rethinking_my_backup_strategy it
> really shows some areas where burp was ahead of many other solutions back
> when you started developing it.

Hello,

Thank you for your kind words.

Yes, "test 4" is demonstrating a bug that I didn't know about. I will try to
fix that ASAP.

Once I have done that, I will think about making "test 1" do what you expect.