Arno, Thank you very much for your reply and advice. I will investigate " Allow Duplicate Jobs" and look at adding a runscript with 'whoami /all' to my windows clients.
My goals for my clients are primarily to back up their files, not be able to restore their systems to a certain state. This is a very (allegedly) simple small business workstation environment. I am also currently planning to copy my windows backups to cloud storage devices, and the manual advises me that the windows vss backups don't copy correctly because there is some xml data associated with each vss backup that isn't currently copied by a copy job. Do you know if this is still the case? I had considered having the FD simply do two backups, one to local storage and one to the cloud, but I'd rather avoid such a practice. For this reason, I am currently planning to set vss backups to no, and portable backups to yes. If you can share any wisdom on this subject (good practices, pitfalls), I would appreciate it. I think implementation should be fairly straightforward. Man, windows can be such a pain in the butt. Ugh. Thank you so much for your help! Regards, Robert Gerber 402-237-8692 r...@craeon.net On Thu, Jan 2, 2025 at 9:02 AM Arno Lehmann via Bacula-users < bacula-users@lists.sourceforge.net> wrote: > 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 >
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
