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,
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>:
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
> Does it ask you for a new volume?
No. Good guess, but the storage is a vchanger and it's working just fine.
If you are using a vchanger then I guess it is a disk only backup, so why do you spool data? It is not required but making you backup slow down at least 2 times then standard job. You can define an attributes spooling only.
--
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
