You only need to set Ignore FileSet Changes = yes if you change a File= or
Plugin= line. The options are ignored.
__Martin
>>>>> On Tue, 10 Nov 2020 11:00:59 -0500, B Smith said:
>
> Well, that answers that! I suppose it isn't the end of the world, though it
> will use up a lot more of my tapes than I'd hoped. I suppose there's no
> reason to do the md5 comparison, then.
>
> One final question: if I want to change accurate to pinsmc but not start a
> whole new full backup, do I need to set Ignore FileSet Changes = yes, or
> will it continue with an incremental backup so long as I don't change the
> actual files/directories in the FileSet?
>
> Thanks again for all the help.
>
> On Tue, Nov 10, 2020 at 7:15 AM Martin Simmons <mar...@lispworks.com> wrote:
>
> > I'm replying inline because it is easier.
> >
> >
> > >>>>> On Mon, 9 Nov 2020 12:38:46 -0500, Brannon Smith said:
> > >
> > > I suppose I misinterpreted this from the manual:
> > >
> > > "In accurate mode, the File daemon knows exactly which files were present
> > > after the last backup. So it is able to handle deleted or renamed files.
> > >
> > > When restoring a FileSet for a specified date (including "most recent"),
> > > Bacula is able to restore exactly the files and directories that existed
> > at
> > > the time of the last backup prior to that date including ensuring that
> > > deleted files are actually deleted, and renamed directories are restored
> > > properly."
> > >
> > > So what is the difference between an accurate and a non-accurate
> > > incremental backup, if I have a fileset where one of the files has been
> > > renamed? Is the idea that a renamed file won't have a modified mtime, so
> > > ordinarily it would not be seen as needing to be backed up?
> >
> > Yes, that's almost correct. The mtime of a renamed file is not changed,
> > but
> > the ctime is changed so that would be included in a non-accurate backup.
> > The
> > problem is when you rename a directory, which doesn't change the mtime or
> > ctime of the files below it in the tree.
> >
> >
> > > I apologize for the basic questions, but let me explain what I think is
> > > happening with the accurate backup and maybe you can tell me where I have
> > > gone wrong.
> > > Bacula looks at the current file and the accurate options; if the md5
> > > (along with the other options) of the file matches the options and md5
> > of a
> > > file already stored for the fileset, then it isn't backed up (i.e., the
> > > file was renamed). Does Bacula not keep a record of the new file name?
> >
> > That's not quite correct. When doing an accurate diff/incr backup, the
> > file
> > will be backed up using its current file name if either of the following is
> > true:
> >
> > 1) The current file name is not listed in the catalog (i.e. it is a new
> > name,
> > either a completely new file or a renamed file).
> >
> > 2) One of the attibutes listed in the accurate options has changed from the
> > value listed in the catalog for the current file name.
> >
> >
> > > Thinking through it, I see why it would have to calculate the md5 for
> > every
> > > file. I guess what I am really looking for is a way to check the ctime
> > (to
> > > detect a rename) and then only backup the file if the md5 has changed.
> > But
> > > that doesn't seem to be an option.
> >
> > Yes, that's correct.
> >
> > __Martin
> >
> >
> > >
> > > Thanks again for all the help,
> > >
> > > B. Smith
> > >
> > >
> > > On Mon, Nov 9, 2020 at 11:56 AM Martin Simmons <mar...@lispworks.com>
> > wrote:
> > >
> > > > Bacula doesn't have any code to match a renamed file with a previous
> > > > file. It
> > > > just makes a backup of every unknown file or those that match the
> > Accurate
> > > > options.
> > > >
> > > > Note that if you remove "5" from the Accurate options then you will
> > need to
> > > > add "mc" to make it detect changes to existing files.
> > > >
> > > > __Martin
> > > >
> > > >
> > > > >>>>> On Sat, 7 Nov 2020 15:22:05 -0500, B Smith said:
> > > > >
> > > > > Hi,
> > > > >
> > > > > Thanks for the response. My (incorrect, I suppose) understanding was
> > that
> > > > > Accurate=pins5 would just look at an unknown file and determine if
> > it was
> > > > > an existing file that had been renamed. In that case, I'm fine with
> > > > taking
> > > > > the extra time to calculate the MD5 to verify the correspondence of
> > the
> > > > > files. I wanted this option so that I wouldn't take up space on the
> > tape
> > > > > with files that had just been renamed. Is there a way to do the same
> > > > thing
> > > > > without recalculating the MD5 for files that obviously haven't
> > changed?
> > > > > Thank you,
> > > > >
> > > > > B. Smith
> > > > >
> > > > >
> > > > > On Sat, Nov 7, 2020 at 10:10 AM Eric Bollengier <
> > e...@baculasystems.com>
> > > > > wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > On 2020-11-07 01:01, B. Smith wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > When using accurate=yes and verify=pins5, does Bacula recalculate
> > > > the MD5
> > > > > > > for each file even when the atime/mtime/ctime of the file has not
> > > > > > changed?
> > > > > >
> > > > > > It is configurable, and from what I see in your fileset, this is
> > what
> > > > > > you have set. "Accurate = pins5" (the character 5 at the end).
> > > > > >
> > > > > > To speed up things, you might want to not do it unless you data is
> > very
> > > > > > critical.
> > > > > >
> > > > > > Hope it helps!
> > > > > >
> > > > > > Best Regards,
> > > > > > Eric
> > > > > >
> > > > > > > I have large files (~60GB) that rarely change in a directory;
> > usually
> > > > > > just
> > > > > > > a new large file is added every couple of weeks... files are
> > rarely
> > > > ever
> > > > > > > deleted and never modified. When I run the incremental, however,
> > it
> > > > is
> > > > > > > taking hours to examine the files. Is there anything I can do to
> > > > speed
> > > > > > this
> > > > > > > up? I have what should be plenty of memory (32GB). Job and
> > FileSet
> > > > > > > definitions are below.
> > > > > > >
> > > > > > > Job {
> > > > > > > Name = "Big Files"
> > > > > > > Write Bootstrap = "/var/db/bacula/bigfiles-%s-%e.bsr"
> > > > > > > JobDefs = DefaultJob
> > > > > > > Type = Backup
> > > > > > > Level = Incremental
> > > > > > > Client = FreeNAS-fd
> > > > > > > FileSet = "Big Files"
> > > > > > > Spool Data = yes
> > > > > > > Storage = TapeLibrary
> > > > > > > Pool = File
> > > > > > > Accurate = yes
> > > > > > > Schedule=LargeFileCycle
> > > > > > > Priority = 12
> > > > > > > }
> > > > > > >
> > > > > > > FileSet {
> > > > > > > Name = "Big Files"
> > > > > > > Include {
> > > > > > > Options {
> > > > > > > signature = MD5
> > > > > > > Accurate=pins5 #should allow keeping track of deleted/renamed
> > > > files.
> > > > > > > verify = pins5 #compare permission bits, then inodes, number
> > of
> > > > > > links,
> > > > > > > size, and finally MD5 changes
> > > > > > > IgnoreCase = yes
> > > > > > > }
> > > > > > > File = "/media/DataSet1/Big Files/"
> > > > > > > }
> > > > > > > }
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > B. Smith
> > > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Bacula-users mailing list
> > > > > > Bacula-users@lists.sourceforge.net
> > > > > > https://lists.sourceforge.net/lists/listinfo/bacula-users
> > > > > >
> > > > >
> > > >
> > >
> >
>
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
