On 11/29/21 12:07, Neil Balchin wrote:
> Recently, I had to reconfigure a large ZFS disk array. Prior to the
> reconfiguration, It was shared to my bacula-fd instance across NFS and I was
> doing daily incrementals, the pool was configured with a scratch pool of
> blank tapes and I kept the backups without any pruning or recycling, veal
> more of an archive than a backup.
>
> After reconfiguring the disk system I ran a restore job and all my files went
> back into place with permissions perfectly in tact.
>
> 3 days later the scheduled backup job started running and instead of
> recognizing the existing files it ran the backup like a Full, never been
> backed up before job.
>
> I have to do this 4 more times on different disk arrays, how can I avoid
> re-backing up all the files I’ve just restored ?
>
>
> Neil B
Hello Neil,
First, before running a new job after the restore, or when editing a Fileset, I
recommend always using the bconsole commands:
* @tall /tmp/file_list.txt (opens a log of bconsole i/o)
Note: If @tall does not work, use the older @tee command)
* estimate listing job=xxx level=incremental (or differential if that is what
you need)
* @tall (with no filename closes the log and stops logging bconsole i/o)
Then open that file in your favorite editor (vim of course :) and have a look.
This is so that you can see what Bacula thinks it needs to backup. This can
save you a lot of time (and media if writing to
tapes)
Next, what you have described "should not happen"™ :)
If possible, I would check to make sure that attributes (ownership,
permissions, etc) of the restored files match what was
backed up. The linux 'stat' command is great for this. IF you can run this
on some files after they are backed up and
before the array is re-built you might be able to identify what is is happening.
Then, you can add the 'Accurate = yes" to your backup job, and the "Accurate =
...." setting in your FileSet's Options{}
block to tell Bacula what attributes to compare when deciding if a file needs
to be backed up.
See the "accurate=<options>" section in the "FileSet Resource" section of the
Main Manual for full information on this option.
We have seen cases where a customer had a script that ran each Saturday which
(much to their surprise) 'touched' every file
in a directory tree, so the next day's Incremental backed up every file as if
it were a full backup because the modification
or change time (I forget which it was) had changed, and it was one of the
default things Bacula looks at when determining if
a file needs to be backed up.
I think, by default (if not specified), the default options are 'pcms' - I can
never remember this for sure though. :)
Hope this helps!
Best regards,
Bill
--
Bill Arlofski
w...@protonmail.com
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
