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
