Hello,
On 12/17/2005 11:13 PM, Kern Sibbald wrote:
Hello Arno,
Now we are very close to finding the problem.
Damn good news. Something this day (or yesterday, rather) really needs :-|
Can you send me the beginning of the log output that shows
reserve.c:493 ... ?
No. See below.
It shoul
Hello Arno,
Now we are very close to finding the problem.
Can you send me the beginning of the log output that shows
reserve.c:493 ... ? It should have 3 or four of those lines reserve.c:493
before it goes into the endless loop. That is the part that will tell me what
combination of drives and
Hello,
On 12/17/2005 8:38 PM, Natxo Asenjo wrote:
hi,
Following the instructions in
http://bacula.org/rel-manual/Backup_Strategies.html#SECTION000283300
I have a little problem. The script /etc/bacula/end_of_backup.sh when
run manually works fine, when run at the end of the job I g
hi,
Following the instructions in
http://bacula.org/rel-manual/Backup_Strategies.html#SECTION000283300
I have a little problem. The script /etc/bacula/end_of_backup.sh when
run manually works fine, when run at the end of the job I get this
message:
17-Dec 20:26 tux-dir: RunAfter: + e
Kern Sibbald wrote:
Hello,
I have released the second BETA version 1.38.3 (14 December 2005) as a tar
file to Source Forge. This version has a rewrite of the reservation
algorithm that hopefully will improve situations where users were finding all
jobs waiting to reserve a drive. I've also
Hello,
There may be a need for more features, but it seems that there are at least
two that already exist that could solve or partially solve your problems:
1. Run multiple simultaneous jobs.
2. Fix a maximum time for the job to run after which it will be cancelled.
On Wednesday 14 December 20
I think the basic problem that you have had, and it seems like you don't quite
understand though you have found a solution, is that recycling for Bacula
requires applying two concepts: 1. the time Bacula can write on a Volume, 2.
the time Bacula keeps that Volume before reusing it.
Most people
