Hi, 18.09.2007 21:33,, Ivan Adzhubey wrote:: > Hi, > > I am running 2.2.4 for the last three days (upgraded from 2.2.1). > > I have found this in the logs this morning (spooling enabled): > > 18-Sep 14:17 xxxxx-sd: Despooling elapsed time = 05:20:43, Transfer rate = > 22.60 M bytes/second > 18-Sep 14:27 xxxxx-sd: Spooling data again ... > 18-Sep 14:27 yyyyy-fd: Could not > stat /mnt/data/Out/<username>/<dirname>/make_pfm.pl~: ERR=No such file or > directory > > And as far as I can see, one of the (huge) jobs that has finished spooling > about 400GB of data yesterday night and was supposed to finish despooling to > tape overnight is still running and busy spooling the same data over again. > What is going on? The only explanation I can think of is that this is somehow > related to 'checkfilechanges' option. I do not have this option mentioned > anywhere in any of my FileSet resources but I suspect it is set on by > default, which is not documented. What is worse however, the above "start > over on error" behavior is also undocumented:
I doubt that. I suppose this job can not spool the complete jobs data, so it works in slices: spooling as much as possible, despooling that data, spooling again, etc. and ad nauseam. You might be able to confirm if the FD sends the same data (at least) twice by regularly checking the 'sta client' output. Also, has this job now spooled lots of data again? 'sta sd' can tell you that. > See: > http://www.bacula.org/rel-manual/Configuring_Director.html#SECTION001470000000000000000 > > "checkfilechanges=yes|no > On versions 2.0.4 or greater, if enabled, the Client will checks size, > age > of each file after their backup to see if they have changed during backup. If > time or size mismatch, an error will raise. > > zog-fd: Client1.2007-03-31_09.46.21 Error: /tmp/test mtime changed > during > backup. > > In general, it is recommended to use this option." > >>From the description above, I was expecting this option to simply warn about > vanished/changed files. Me too. > Invalidating whole backup and starting from scratch > due to a single missing file looks like overkill for me. Overkill is too friendly, IMO - this would qualify as a bug. > Besides, there is > very little chance avoiding at least a single file mismatch of this kind > during large backups on a live production system. On the other hand, I would > really like such errors to be checked and reported (as warnings) so that > operator can notice more unusual situations. > > So, am I right and this "Spooling data again..." behavior is caused by > checkfilechanges feature? Well, as I wrote, I doubt that, but it might be... Arno > Thanks, > Ivan > > > The information transmitted in this electronic communication is intended only > for the person or entity to whom it is addressed and may contain confidential > and/or privileged material. Any review, retransmission, dissemination or > other use of or taking of any action in reliance upon this information by > persons or entities other than the intended recipient is prohibited. If you > received this information in error, please contact the Compliance HelpLine at > 800-856-1983 and properly dispose of this information. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users -- Arno Lehmann IT-Service Lehmann www.its-lehmann.de ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
