anarcat
commented
9 years ago i would rather avoid a clunky --include and allow specifying multiple paths correctly.
if you look in the source code in bup_cron/__init__.py:1034 (https://github.com/anarcat/bup-cron/blob/master/bup_cron/__init__.py#L1034) you will see why: basically, we can't pass those paths all at once to bup index because we were having problems with bup index -x / /var.
we could however loop on bup index and then call bup save only once, but then the assumption is that each path provided is its own filesystem...
--include would require serious re-engineering here... there is already some work to be done to cleanup the snapshot/filesystem detection code here, as mentionned here:
but this is, yes, yet another oddity. can't hide all the weird bup corner cases here... ;)
I'm using
bupand want to switch tobup-cronfor obvious reasons. I don't backup firefox because it seems like unecessary churn from history & state-saving (firefox crash recovery), plus we have Firefox Sync. But I do back up my 400Kb of bookmarks. I can't see how to do this in bup-cron, while I can with bup:I think bup-cron should have --include. Possibly bup-index could implement it, and bup-cron just pass it through :). I don't want to pass multiple paths with
bup-cron -p, because then firefox is in a different backup to my other dotfiles.(Am also slightly disturbed by the semantics illustrated in the example config file. Why are there multiple overlapping paths? Because implementing
--snapshoteffectively requires--xdev. But this means--snapshotaffects what's being backed up. Strawman hack: implement--xdevif it's not already, and require it to be explicitly passed for--snapshot. Or snapshot recursively. Hmm, I wonder if other Windows backup programs handle mountpoints correctly with VSS :)).