In the message dated: Fri, 22 Feb 2008 15:55:07 +0100,
The pithy ruminations from Peter Buschman on
<[Bacula-users] Incremental promotion to full for queued jobs> were:
=>
=> I have the following schedule at a site I deal with:
=>
=> Full on the first saturday of every month.
=> Incremental on non-full saturdays plus sun-fri.
=>
=> The problem:
=>
=> When the first incremental backup is run, Bacula promotes it to a
=> full as expected since there is no prior full. However, this backup
Right, that's normal.
=> is roughly 1TB being compressed and written to an NFS share at
=> approx. 1.5MB/s. Thus, the full backup takes over 48 hours to
=> complete. While that is running, the Bacula scheduler kicks-in on
Ick.
=> the next day and the day after, queueing-up those day's
=> backups. However, because the full that those backups depend on is
=> still running and has not been committed to the catalog, those jobs
=> are likewise promoted to fulls. When the initial backup completes,
Double ick. What version of Bacula are you running? I'm far from certain about
this, and I'm not running a current version myself, but I believe that Kern
talked about fixing this in a future version, and that fix may be in the
current release.
=> it is immediately followed by 2 more full backups which exceeds the
=> space available. Although this can be worked around by temporarily
=> disabling the incremental schedules, it is not ideal since the
=> problem will only occur again when the 50-day retention period is exceeded.
Huh?
If you've got a 50 day retention period for full backups, then after the first
one, there should be a "full" in existence, meaning that subsequent
incrementals will not get promoted to fulls. Of course, this doesn't alleviate
the problem with the monthly full taking more than 24hrs to run, and having
simultaneous full and incremental backups running (which is the issue that I
think has been fixed).
=>
=> Is it possible for Bacula to determine whether or not an incremental
=> job should be promoted to a full at the time the job starts running
=> rather than at the time the job gets queued by the scheduler? That
It sounds like the problem may be with your retention period...are you sure
that it's not less than 30 days?
=> would solve my problem since any incremental jobs that were queued
=> while their dependent full was still running would not get promoted
=> to fulls themselves.
I sympathize...really!
=>
=> I suspect this is a corner-case since backups, even fulls, that take
=> longer than 24 hours (let alone 48 hours) are rare.
Unfortunately, not as much of a corner case as you think. I've got 4 jobs that
take over 24hrs for full backups, and a 5th that's so close that any additional
load on that disk system or the network during backups pushes the job over
24hrs.
=>
=> --PLB
=>
----
Mark Bergman [EMAIL PROTECTED] 215-662-7310
System Administrator Section of Biomedical Image Analysis
Department of Radiology University of Pennsylvania
PGP Key at: https://www.rad.upenn.edu/sbia/bergman
The information contained in this e-mail message is intended only for the
personal and confidential use of the recipient(s) named above. If the reader of
this message is not the intended recipient or an agent responsible for
delivering it to the intended recipient, you are hereby notified that you have
received this document in error and that any review, dissemination,
distribution, or copying of this message is strictly prohibited. If you have
received this communication in error, please notify us immediately by e-mail,
and delete the original message.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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
