Re: full job runs again right after previous full job???

Hi Rob,

Am 30.12.2024 um 04:34 schrieb Rob Gerber:
> Happy new year, everyone!
> 
> I have a testing environment that I'm assembling for a client. Bacula 
> 15.0.2, running in a rocky linux vm on a synology DS423+.
> 
> I have tested backups with a windows FD using a windows VM running 
> windows 11. This went well. A few days ago I added one of my windows 11 
> workstations as an FD. This FD has about 1.44TB of space used. The FD 
> name is 'akita'.
> 
> Because I'd just added the FD client to akita, I started a full backup. 
> Overnight, the routinely scheduled incremental backup queued up behind 
> the full backup. Looking at the logs, the scheduled incremental waited 
> until 20 seconds after the manually started full backup of akita had 
> concluded. In such a situation I would expect an incremental to complete 
> with very few files. However, this is not what happened. The incremental 
> was upgraded to a full because 'no suitable full backup was found'.

The backup level to run the new backup with is determined when the job 
gets put into the work queue, at which point the previous job was still 
running, thus there really was no suitable full backup.

To avoid this can be very easy -- if the available controls for job 
concurrency are used. See Allow Duplicate Jobs settings and related.

> This 
> would be reasonable, except such full backup literally just finished. 
> Worse, the upgraded incremental had a number of VSS writer errors that 
> resulted in a backup that was incomplete. The first, correct full backup 
> clocked in at 1.3TB in size. The erroneously upgraded incremental backup 
> was about 300GB. Even worse, the second full finished with a T status,


If individual files or anything can not be backed up, Bacula does not 
make this a job failure. The "with warnings" note at the Termination 
code is quite relevenat. Also, not that the actual number of failures 
reported by the FD is in the Job report. This is quite important 
information that unfortunately does not make it into the single letter 
code but can easily be derived from the catalog, the job report, or log 
files.

> indicating a successful backup. If I hadn't known better, I would have 
> thought that this was a good backup based on the status.
> 
> What on earth is going on here? Why didn't bacula recognize the 
> previously ran full backup as valid? Any idea why many of the VSS 
> writers failed? It's particularly concerning that the job finished with 
> a T status despite so many VSS writers failing,

VSS is not something the FD controls. I would recommend checking 
Windows' logs for anything interesting.

Also, as you already concluded, Accurate mode is a pretty useful thing, 
although it does have its drawbacks.

>...
>I do wonder if the whole problem was kicked off 
> because bacula didn't have time to properly quantify the client's backup 
> state before the scheduled incremental backup started,

I doubt that.

> but I can't 
> imagine how to avoid such a problem occurring again if a backup runs 
> long enough. I have had backups run for WEEKS and haven't had this 
> problem before, on a linux system.

Duplicate job control, as I mentioned above.

>... 
> I note that many of the items listed as having issues are in c:\backups 
> regarding a files and folders dump from a previous windows machine 
> (minerva-w10). I briefly wondered if maybe the issue is because there is 
> a parallel windows system in that folder, but I see also that it failed 
> to back up an mrimg image file containing that same system. the system 
> should certainly be unaware of the contents of the image file.

May be worth checking ACLs and the account your file daemon runs under; 
Windows can be very particular and tricky in this respect (I'm currently 
working with a few Windows admins who are trying to get their Windows 
user and permission setup sorted out because it has developed into 
something rather messy, and seeing some serious experts being scared of 
Windows' way to inherit, override, modify and otherwise work with its 
complex account and permissions system is interesting).
One thing I found helpful diagnosing permissions issues on Windows was 
to add a Run Script which calls
whoami /all to a job so you see the effective permissions of the running 
FD in a job report.

> There 
> were also issues with a number of other, unrelated files and folders, 
> including c:\games and c:\boot. Of course, the first full backup had no 
> issues with any of this.
> 
> I would welcome input from anyone with knowledge about this strange 
> behavior. Thank you in advance.

You're welcome :-)

Although I think only one issue is strange here, and that is all 
Windows, so even the term "strange" could be disputed ;-)

Cheers,

Arno

> Regards,
> Robert Gerber
> 402-237-8692
> [email protected] <mailto:[email protected]>
> 
> 
> _______________________________________________
> Bacula-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bacula-users

-- 
Arno Lehmann

IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück



_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users