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

[Myles Loosley-M. <my...@pr...>]

Just a heads up, there's a typo in test #4's parameters (assuming they 
were copied/pasted), which could potentially impact results:

-----

incldue=/
include=/boot
exclude=/boot
include=/boot/test
-----

Myles Loosley-Millman - Priority Colo Inc.
my...@pr... - www.prioritycolo.com
1-888-AS-30176 (1-888-273-0176) x301

On 2021-08-09 5:50 p.m., Graham Keeling wrote:
> 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.
>
>
> _______________________________________________
> Burp-users mailing list
> Bur...@li...
> https://lists.sourceforge.net/lists/listinfo/burp-users