Re: [Burp-users] include vs. filesystem boundaries
Brought to you by:
grke
|
From: Graham K. <gr...@gr...> - 2021-08-09 22:07:18
|
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. |