On 10/26/16 12:08, Bruno Friedmann wrote: > On mercredi, 26 octobre 2016 09.41:25 h CEST Douglas K, Rand wrote: >> On 10/26/16 6:03 AM, Jörg Steffens wrote: >>> Besides this, we had also some internal discussion about this. >>> While upgrade to Full is a useful feature, it is normally not required >>> if you use Accurate. Also besides update to Full, an upgrade to Accurate >>> might also be an option.
>> Jorg, you are right about Accurate mode, which is enabled on our File >> Set. It seems that the rule "any change to a fileset" is a bit heavy >> handed with Accurate. >> >> For now I've reverted my File Set to avoid the problem and pushed the >> exclude off the the clients via Puppet. I was lucky enough to have file >> = "\\</usr/local/etc/bareos/excludes" already in my Excludes, so I >> leveraged that instead of changing the File Set.) >> >> I'll noodle about the co-funding. > > While the full needs after changes can be a burden, I'm not 100% sure to > subscribe to not "forcing it" in a way or another. > > Every admin will have one day or another a change to setup in its filesets. > Accurate will pick that ok, but then the time to restore will come, > and I beat on the fact that there will be a lot of complains about why "my > files are not there" expectation. > The reason will be because at that time, the fileset didn't know about them, > and nobody will remember at that time, a change occurs in the fileset, and no > full were made again. > > I'm sorry if I'm not clear enough yet, I would like to see all the real > scenario before jumping saying "bravo". > Perhaps we need a fileset version in the database ? > > Or some options are minor, and other major ? > > Isn't there a way to trick bareos with the content of fileset table ? > like saving the date of the previous hash for a given ressource, make the new > one and bring back the old data ? It does seem that the change the fileset and get a new full backup rule is safest. And probably a good default. I was noodling about a "I'm smarter than Bareos" option that would allow me to change a fileset and take responsibility for not requiring the next backup be a full backup. In my particular case the change is fairly innocent: The fileset starts at / and backups up all local filesystems other than some directories that are excluded. And my work around was to not add "File = /project/tmp" to the Excludes stanza in the fileset, but instead add a line to the excludes file on the client. Adding the line to the excludes file on the client doesn't force a new backup and yet has exactly the same result as adding it to the fileset. -- You received this message because you are subscribed to the Google Groups "bareos-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
