Re: [Bacula-users] A scheduling quirk
On Mon, Dec 12, 2005 at 08:33:17PM +0100, Arno Lehmann wrote: > Unfortunately, you did miss something :-P > > From the maual, section "Configuring the Director", subsection "Jobs": > > Max Start Delay = Yes, that looks like it should do what I need. I'm pretty sure that I read through that section of the documentation when I began setting up Bacula, but it didn't occur to me that this could be used to eliminate the back to back incremental and catalog backups that I've noticed. Thanks once more for the excellent and insightful advice. -- John Kodis. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] A scheduling quirk
Hello, John Kodis schrieb: On Mon, Dec 12, 2005 at 03:23:39PM +0100, Jo wrote: Why don't you change the schedule so no backups are made on Saturday and Sunday? I may end up doing something like that (I'd only skip incrementals on the first Saturday and Sunday of the month), although I was hoping for a more general solution. No problem... Sorry for not being able to actually answer the question. That's quite alright. It at least tells me that there's not an obvious solution that I've just overlooked, and I'm grateful for that alone. Thanks! Unfortunately, you did miss something :-P From the maual, section "Configuring the Director", subsection "Jobs": Max Start Delay = The time specifies the maximum delay between the scheduled time and the actual start time for the Job. For example, a job can be scheduled to run at 1:00am, but because other jobs are running, it may wait to run. If the delay is set to 3600 (one hour) and the job has not begun to run by 2:00am, the job will be canceled. This can be useful, for example, to prevent jobs from running during day time hours. The default is 0 which indicates no limit. You've only got to think the other way: Let the job start, but when it waits too long have it canceled automatically. You achieve the desired result with the correct setup of the Maximum Concurrent Jobs setting at different places, by the way. Hope this helps, Arno -- John Kodis. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users -- IT-Service Lehmann[EMAIL PROTECTED] Arno Lehmann http://www.its-lehmann.de --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] A scheduling quirk
On Mon, Dec 12, 2005 at 03:23:39PM +0100, Jo wrote: > Why don't you change the schedule so no backups are made on Saturday > and Sunday? I may end up doing something like that (I'd only skip incrementals on the first Saturday and Sunday of the month), although I was hoping for a more general solution. > Sorry for not being able to actually answer the question. That's quite alright. It at least tells me that there's not an obvious solution that I've just overlooked, and I'm grateful for that alone. Thanks! -- John Kodis. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] A scheduling quirk
John Kodis wrote: On Mon, Dec 12, 2005 at 02:05:16PM +0100, Jo wrote: I'm not so sure this is a waste of resources. Only the files that were changed will be in those incrementals. The first one will catch all the files that changed while the full was running. The second one will be virtually empty. In my case, these would get run Sunday night, and so both would contain little beyond the log files that have changed. I'd rather not bother saving these twice, and could certainly do without the three near-identical copies of the catalog backup. In addition to the waste of tape, this creates a bunch of job entries that I don't care about. If you skip these backups and then a problem occurs the following day, you won't be able to restore to the most current situation, but only to the situation at the moment of the full backup. That's a good reason to leave the default action as is, although in my situation I'd still like to be able to override it. -- John Kodis. Why don't you change the schedule so no backups are made on Saturday and Sunday? Sorry for not being able to actually answer the question. Jo --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] A scheduling quirk
On Mon, Dec 12, 2005 at 02:05:16PM +0100, Jo wrote: > I'm not so sure this is a waste of resources. Only the files that were > changed will be in those incrementals. The first one will catch all the > files that changed while the full was running. The second one will be > virtually empty. In my case, these would get run Sunday night, and so both would contain little beyond the log files that have changed. I'd rather not bother saving these twice, and could certainly do without the three near-identical copies of the catalog backup. In addition to the waste of tape, this creates a bunch of job entries that I don't care about. > If you skip these backups and then a problem occurs the > following day, you won't be able to restore to the most current > situation, but only to the situation at the moment of the full backup. That's a good reason to leave the default action as is, although in my situation I'd still like to be able to override it. -- John Kodis. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] A scheduling quirk
John Kodis wrote: I've been using the standard monthly-full, weekly-differential, and daily-incremental backup scheme that's provided by the bacula-supplied configuration files. This is all working fine, but I've now added enough clients that a full backup takes just over two days. After the full backup completes, it is immediately followed by the two daily incremental backups and the three catalog backups that have queued up while the full backup was in progress. While it's only a minor waste of tape, it's still something that I'd like to avoid if I can do so easily. Is there a job directive or some other way to say "Don't schedule another instance of a job if the same job is already waiting to run?" -- John Kodis. I'm not so sure this is a waste of resources. Only the files that were changed will be in those incrementals. The first one will catch all the files that changed while the full was running. The second one will be virtually empty. If you skip these backups and then a problem occurs the following day, you won't be able to restore to the most current situation, but only to the situation at the moment of the full backup. Jo --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] A scheduling quirk
I've been using the standard monthly-full, weekly-differential, and daily-incremental backup scheme that's provided by the bacula-supplied configuration files. This is all working fine, but I've now added enough clients that a full backup takes just over two days. After the full backup completes, it is immediately followed by the two daily incremental backups and the three catalog backups that have queued up while the full backup was in progress. While it's only a minor waste of tape, it's still something that I'd like to avoid if I can do so easily. Is there a job directive or some other way to say "Don't schedule another instance of a job if the same job is already waiting to run?" -- John Kodis. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
