We modify the Bacula source to remove this limit since we regularly run 10-14
day backups. As an archive, we do full backups of each volume annually to go to
Iron Mountain and quarterly to go to another building (data are mirrored online
as well), with volumes on the order of 50-100 TB. Splitting these up further
runs the risk of missing some directories, and complicates restore. I do not
understand the need for a hard-coded limit; perhaps kill a job with no activity
after some period instead. We are pleased with Bacula and have found it very
reliable.
Robert Candey
> -------- Original Message --------
> Subject: Re: [Bacula-users] how to debug a job
> From: Roberts, Ben <ben.roberts AT gsacapital DOT com>
> To: Kern Sibbald <kern AT sibbald DOT com>
> Cc: bacula-users <bacula-users AT lists.sourceforge DOT net>
> Date: Mon Jan 26 2015 02:51:10 GMT-0500 (EST)
>
>
> Hi Kern,
>
> >> Hard-coded, huh? Nobody's tried backing up that big data I keep hearing
> >> about?
>
> > No, there is no change in the hard coded 6 day limit, and at the moment, I
> personally
>
> > am not planning to implement anything, for two reasons: 1. I would like to
> limit the
>
> > number of new Directives to what is absolutely necessary because there are
> already
>
> > more than I can remember. 2. In my opinion, any Job that runs more than 6
> days is
>
> > virtually destined to have problems during restore -- i.e. you will likely
> have backup
>
> > dates that span 6 days of time in a single job. That appears to me to be
> something very undesirable.
>
> Just to add my views to the 6-day limit conversation I frequently have issues
> running into this limit. As I write I am crossing my fingers hoping that a
> 44TB backup job will complete in time. If it maintains a constant speed to
> 100MB/sec it should in theory take 5.6 days however my other weekend jobs
> have
> slowed this average down to just 71MB/sec so I suspect it’s going to fail L.
> If it does, I think I’ll be out of options other than to patch and recompile
> Bacula to remove the limit myself.
>
> This is a ZFS snapshot being written via bpipe so regardless of how long it
> takes to write out on the storage daemon there’s no risk of internal
> inconsistency. While I understand the reason behind the limit when backups
> are
> taken at the file level, in this case the six-day limit serves no technical
> purpose, and only causes me more work. An additional directive to configure
> this, even if not used by 99% of Bacula users would be much appreciated if
> only to save the maintenance overhead of patching each Bacula release.
>
> Regards,
>
> Ben Roberts
>
> *From:*Kern Sibbald [mailto:kern AT sibbald DOT com]
> *Sent:* 25 January 2015 10:56
> *To:* Radosław Korzeniewski; Dimitri Maziuk
> *Cc:* bacula-users
> *Subject:* Re: [Bacula-users] how to debug a job
>
> On 23.01.2015 19:22, Radosław Korzeniewski wrote:
>
> Hello,
>
> 2015-01-22 3:42 GMT+01:00 Dimitri Maziuk <dmaziuk AT bmrb.wisc DOT edu
> <mailto:dmaziuk AT bmrb.wisc DOT edu>>:
>
> On 01/21/2015 06:41 PM, Bill Arlofski wrote:
>
> > Bacula has a hard-coded 6 day limit on a job's run time. 518401
> seconds =
> > 6.00001157 days, so it appears that is the cause for the watchdog
> killing the job.
>
> Hard-coded, huh? Nobody's tried backing up that big data I keep hearing
> about?
>
> Yes, but nobody was interested in changing it to the config parameter. It
> is possible that someone did that in 7.x, I need to check.
>
>
> No, there is no change in the hard coded 6 day limit, and at the moment, I
> personally am not planning to implement anything, for two reasons: 1. I would
> like to limit the number of new Directives to what is absolutely necessary
> because there are already more than I can remember. 2. In my opinion, any
> Job
> that runs more than 6 days is virtually destined to have problems during
> restore -- i.e. you will likely have backup dates that span 6 days of time in
> a single job. That appears to me to be something very undesirable.
>
> Best regards,
> Kern
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
