This is a very common issue that must be looked at carefully, this will be a
large post and I apologize for it :P
Priority levels are very hard to manage/maintain since they can cause jobs to
block! Meaning if a job has network (or other) issues and the Bacula server
connection doesn't drop but
This is a shot in the dark but on some IBM standalone servers (not blade)
disabling MSI did help fix a few issues (recv' queue errors, etc), your mileage
may vary on this one.
I'm not sure about freebsd but centos it is just setting an option for modprobe
after the driver init, example:
modprob
What is the actual issue here?, I may have missed the actual topic of
discussion...
Base jobs are there to help reduce the overall file and network bandwidth when
you do a full backup, the time wasted is mostly on verifications and database
table content linking.
On the server end it has to d
This way is one way to do it using /etc/sudoers file. Just make sure you read
up on sudo beforehand.
/etc/sudoers:
# group
%httpd ALL=NOPASSWD: /usr/bin/bconsole
# user
httpdALL=NOPASSWD: /usr/bin/bconsole
Regardless of which way you go, any outside bconsole access is always dangerous
and
Last thing... In some cases I will use a diff fileset for base job only for
stuff I know will not change and anything that doesn't need to be there is
exempt, stuff like:
Log files (assuming these will be out of data by the next base job run)
Initial DB dump's
Database index/temp files
*.pid fil
If you want to use FQDN's in Bacula and do not want to touch your DNS servers
you could modify /etc/hosts (assuming you are on a *nix box) to do the job for
you.
The only gotcha is the remote host changes identity (repurposed, whatever)
I use /etc/hosts to avoid DNS look ups, changes are immedi
You can schedule jobs any way and time you like.
Note that Name = "job-name" is actually Name = "schedule-name"
"schedule-name" is used for the job(s) and not the other way around.
I have jobs that run fulls every day, there is more than 1 way to do the same
type of schedule you just have to
Can you post the full output of this command in mysql:
show FULL processlist;
FULL gives the whole query.
Also if you are subject to locking problems try moving the table types to InnoDB
and try using the dbi:mysql setting in the database definition within bacula,
the dbi driver helped fix a b
One gotcha with using reschedule on error is, if you cancel a job it will
reschedule said job until all reschedule counts are exhausted.
+--
|This was sent by ccs...@hotmail.com via Backup Central.
|Forward SPAM to ab...@backupce
You can also do that per Job OR JobDefs too, If you the same schedule for more
than 1 client this may be more appropriate for you:
Job or JobDefs {
Pool = "thisjob-inc-pool" # default 'level' pool *REQUIRED even if not used*
Full Backup Pool = "thisjob-full-pool"
Incremental Backup Pool = "t
Yes reload also scans through the included config files from bacula-dir.conf
I use them heavily in my environment.
What a reload does not do is load any modifications of bacula-sd.conf or
bacula-fd.conf you need to restart those daemons outside of bconsole.
(bacula-sd/bacula-fd)
I'm using 5.2.1
2012/11/29 Dan Langille langille.org (dan < at > langille.org)>
On Nov 29, 2012, at 4:56 PM, Jonathan Horne wrote:
If i have say, 2 data base servers, can i set bacula to ensure they are not
being backed up at the same time? Â Even if they are the last 2 jobs running,
id like to not back them b
bacula-fd.conf (both on the server and the client)
FileDaemon {
Maximum Concurrent Jobs = X
}
bacula-sd.conf
Storage {
Maximum Concurrent Jobs = X
}
Device {
Maximum Concurrent Jobs = X
}
bacula-dir.conf
Director {
Maximum Concurrent Jobs = X
}
Job or JobDefs {
Maximum Concurrent Jobs
I assume g++ is not able to locate something on the command line to build such
as conio.c => conio.o
Try adding in any necessary paths to allow the compilers extra locations to
check for code/libraries/etc
PATH=/usr/bin:/sbin:/usr/local/bin
LD_LIBARAY_PAT=/lib:/usr/lib:/usr/local/lib
failing th
same time upgrading everything to 5.2+
[5.2.12 on the director/sd side])
Also I piggy back on the DB dump script to issue reports when run - so if I
come into the office and see the report(s) didn't come in ... time to
investigate :P
On 12/11/12 16:47, ccspro wrote:
And make sure your Catalog
Or better yet setup a SVN or GIT repository for your config file changes?
Just an idea.
We do this for some of our router,switch and network configs.
Yup. Dump the DB to text that's retained for 15 days, back up the dumps
directory, compress and archive offs
I've only got a minute to write this out for you so I'll make it quick:
Toss this into the spot in your fileset where you specify paths for inclusion:
(assuming its unix, linux, etc)
File = "\\|/bin/bash -c \"find /folder/* -daystart -type f -mtime -365
\" "
reload via bconsole
perform
It does not
seem to be honoring
the References: field in the email headers. This messes up message
threading
which makes it harder to follow a conversation.
Is anyone else seeing this issue?
Yes. It's quite annoying. But I guess there's not much that c
posting is the ease of use
while at home or work :P no need to store anything on my work box or at home.
Just toss up multiple messages in tabs using a web browser and away ya go!
Hopefully this message threads properly... UGH
On 2012-12-13 18:42, ccspro wrote
Hi Silver,
You have a many options:
If it is a remote client system and not your bacula dir/sd machine - backup
your *.conf files in the bacula installation directory (normally /etc/bacula on
most systems) and reinstall the bacula 5.2.12 client package [you may need to
remove the package first]
20 matches
Mail list logo
