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
r...@craeon.net <mailto:r...@craeon.net>
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
--
Arno Lehmann
IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
