I'm having a RAID5 array of about 40TB in size. A separate RAID
controller card handles the disks. I'm planning to use the normal ext4
file system. It's standard and well known, most probably not the
fastest though. That will not have any great impact, as there is a 4TB
NVMe SSD drive, which
>Can Bacula use my 4 disks in the same way filling up backup1 and than
using backup2 etc?
The short answer is yes. We've been doing this for over a decade using
sym links to create one logical Bacula storage area that then points off
to 40-50 disks worth of volume data on each server. In
Bacula DOES NOT LIKE and does not handle network interruptions _at all_
if backups are in progress. This _will_ cause backups to abort - and
these aborted backups are _not_ resumable
Hi,
My feeble two cents is that this has been a bit of an Achilles heel for
us even though we are a LAN backup
Hello
I am used to this principle with Linux but I don't understand why it just takes
it when Bacula is working and it slows down the server so much that I can no
longer access it in ssh.
How is your storage allocated on the server? i.e. how are things
partitioned with regard to your backup
%Cpu(s): 0.1 us, 0.2 sy, 0.0 ni, 52.9 id, 46.5 wa, 0.0 hi, 0.2 si, 0.0 st
KiB Mem : 29987532 total, 220092 free, 697356 used, 29070084 buff/cache
KiB Swap: 15138812 total, 15138812 free,0 used. 28880936 avail Mem
It looks like your memory is being used by the Linux file
Hi,
How many files and total space on each client? 6 TB is not necessarily
a huge total amount but you may want to consider splitting each client
job into smaller chunks. Also, what does the status of the jobs show?
Does it show that it is indeed backing up data? Unfortunately, if they
Hi Kern, yes, I know - I should have mentioned that we're still running
an earlier version of Bacula. But my main point was that Postgres 10
doesn't seem to have any issues for us.
cheers,
--tom
On 09/07/2018 02:41 PM, Kern Sibbald wrote:
On 09/07/2018 12:05 PM, Thomas Lohman wrote
FWIW we have not seen any compatibility problems in v.10, but we're not
using it with bacula. All I can see in bacula is
/usr/libexec/bacula/create_postgresql_database:
We've been using Bacula with Postgres 10.x on RH Enterprise 7.5 for a
few months now with no issues. The only change to
> One of the queued backups is the next incremental backup of "archive".
> My expectation was that the incremental backup would run only some hours
> after the full backup finishes, so the difference is really small and it
> only takes some minutes and only requires a small amount of tape
>
The question now is: bacula decides if it will upgrade jobs when it
queues the jobs or when it starts the jobs? According to the logs
above I think it is when it starts.
To my mind it's upgraded when it's queued... I hope I'm wrong :)
Hi, it is done when the job is queued to run. So, if
On 25/06/15 13:21, Silver Salonen wrote:
But why it upgraded the other incrementals in the queue if the first
incremental was upgraded to full?
Because the algorithm is broken. It should only make that decision when
the job exits the queue.
I filed a bug against this a long time ago, It
Ok, so the option Allow Duplicate Job=no can at least prevent multiple
full backups of the same server in a row as stated before?
As others mentioned, I think it may help in your case but it may not
completely solve the problem that you saw. It looks like you had 5
instances of the same job
No, because the end time of Full job #1 occurred after the end time of
the failed job #2. Bacula doesn't see any failed jobs occurring after
the end time of successful job #1 which is all it cares about - at least
in our patched version.
--tom
Wouldn't this changed behavior run into the
Even though, IMHO, spooling disks backup is just muda (Japanese
Term): http://en.wikipedia.org/wiki/Muda_(Japanese_term)
Not necessarily - if you have a number of backups that tend to flake out
halfway through for whatever reasons (network, client issues, user
issues, etc) e.g. then by
is there a quick way to set the schedule to be every other week
(to create full backups every 14 days i.e. on even weeks since
01.01.1971 for example)
If there is no predefined keyword, is there a way to trigger this
based on the result of an external command?
Hi, you may also want to look
This is probably a question for Kern or perhaps should be better posted
to bacula-devel but I'll send it here since others may have experienced
or have comments on this.
Assume you are running Virtual Fulls every x days (aka the Max Full
Interval for Virtual Fulls) and also have retention
First let me thank you all for your responses, i really appreciate
them. As Joe, i think the problem here are the bacula jobids, ¿ is
there any way to say bacula to start from (let say) job id 900 ?
i think that's an easy way to fix all the problem as i will be able
I am not familiar
My volumes are of type files so using new volumes vs recycling expired
ones just fills up the file system with old data. It makes it hard to
manage and forecast filesystem space needs.
I have never understood Bacula's desire to override my policy and insist
on preserving data that I already
StartTime does not get updated when migrating a job. Is this a bug or
is it the way it is supposed to be?
I believe that this is the way it is supposed to work. When
copying/migrating a job or when creating a virtual Full job from
previous jobs, the start time of the new job gets set to the
According to
http://www.baculasystems.com/windows-binaries-for-bacula-community-users,
6.0.6 is still the latest version. Does this mean the bug was never
fixed there, or is it the text on that page that needs updating? Or
is there still something else entirely, and is it not this bug that's
Because traffic is going through those firewalls, I had already
configured keepalive packets (heartbeat) at 300 seconds. In my first
tests, backups *did* fail because that was missing. Now they don't
seem to fail anymore, but there's that socket terminated message
every now and then that
I've seen this error before on and off on one particular client.
Nothing changes with regard to the configuration and yet the error will
crop up. Usually a combination of the following fixes it -
cancel/restart the job, restart the Bacula client, or restart the Bacula
storage daemon. Since
thank you, so the only way is to configure the volume to be used in only
1 job, So if a job fail i can delete the entire volumen. I try this.
Hi, you can also choose to spool jobs before they are written to your
actual volumes. This way if jobs tend to fail in the middle for
whatever reason,
I guess I will go with Sven's suggestion, or does anyone have any
other recommendation on running a weekly backup with 7 days archive?
Hi, this may be the same as Sven's recommendation but if you want to
guarantee the ability to restore data as it was 7 days ago then
you'll need to set your
It did. Thanks a lot for your help - I highly appreciate it.
If we ever should run into each other in real life please remember me
that I owe you some beer...
No problem :) - glad that you got it working.
--tom
I tried that, but it fails:
Enter SQL query: alter sequence fileset_filesetid_seq restart with 76;
Query failed: ERROR: must be owner of relation fileset_filesetid_seq
I ran this under bconsole, i. e. as user bacula - is this not the
right thing to do?
Wolfgang,
As someone I
My guess is that during the migration from MySQL to Postgres, the
sequences in Bacula did not get seeded right and probably are starting
with a seed value of 1.
the filesetid field in the fileset table is automatically populated by
the fileset_filesetid_seq sequence.
Run the following two
Wolfgang,
Dear Thomas,
In message 52d555c5.9070...@mtl.mit.edu you wrote:
My guess is that during the migration from MySQL to Postgres, the
sequences in Bacula did not get seeded right and probably are starting
with a seed value of 1.
Do you have any idea why this would happen? Is this
That seems a working solution, but creating a symbolic link for every
volume required by a restore job introduces a manual operation that
would be better to avoid, especially if a lot of incremental volumes are
being considered.
We use symbolic links here and have never had any problems. All
10-dic 17:46 thisdir-sd JobId 762: acquire.c:121 Changing read
device. Want Media Type=JobName_diff have=JobName_full
device=JobName_full (/path/to/storage/JobName_full)
I think that you want to make sure the Media Type for each Storage
Device is File. It looks like you've
25-Nov 13:38 home-server-dir JobId 144: Fatal error: Network error with FD
during Backup: ERR=Connection reset by peer
25-Nov 13:38 home-server-dir JobId 144: Fatal error: No Job status returned
from FD.
25-Nov 13:38 home-server-dir JobId 144: Error: Bacula home-server-dir 5.2.5
- heartbeat: enabling on the SD (60 seconds) and
net.ipv4.tcp_keepalive_time also set to 60
In glancing at your error (Connection reset by peer) and your config
files, I didn't see the Heartbeat Interval setting in all the places
that it may need to be. Make sure it is in all the following
We do something like this by running a job within Bacula every morning
that scans all client configuration files, builds a list of expected
current jobs/clients and then queries the Bacula DB to see when/if
they've been successfully backed up or not (i.e. marked with a T). If
it's been more
We are having a problem between a Bacula server version 5.2.5
(SD and
Dir) and a Windows client running Bacula-fd 5.2.10.
While this may not be your problem, in general, I recall it is best to
keep the client versions = to the server versions.
--tom
Yes, for disk storage, it does not make much sense to have data spooling
turned off.
I would suggest to always turn attribute spooling on (default off) so
that attributes
will be inserted in batch mode (much faster), and if possible ensure
that the
working directory, where attributes are
Hi,
We have jobs that we want to limit their time either sitting and waiting
or running to certain number of hours. In addition, we want these jobs
to reschedule on error - essentially, start the job at X time, keep
trying to run but after Y hours end no matter what. I've found that if
you
One idea I can think of is using a list of filesystem types that matter.
That way you can handle most things and also exclude cluster
filesystems like ocfs2 that should best be backed up with a different
job and separate fd.
This is what we do for our UNIX systems. We actually define each
Yesterday I waited for the job to finish the first tape and then wait
for me to insert the next one.
I opened wireshark to see if there is a heartbeat during waiting -
and there was none. During the job the heartbeat was active.
From what you wrote the heartbeat should be active when
I now could check if bacula fd to sd connection timed out because of
the network switches. This was not the case. My job still cancels.
My experience is that the heartbeat setting has not helped us with our
Connection Reset by Peer issues that occur occasionally. Something
more is going on
Tom: How did you restart the job. Did you have a script or do you do it
by hand?
There are Job options to reschedule jobs on error:
Reschedule On Error = yes
Reschedule Interval = 30 minutes
Reschedule Times = 18
The above will reschedule the job 30 minutes after the failure and it'll
try
2012-09-19 22:58:45 bacula-dir JobId 13962: Start Backup JobId 13962,
Job=nina_systemstate.2012-09-19_21.50.01_31
2012-09-19 22:58:46 bacula-dir JobId 13962: Using Device FileStorageLocal
2012-09-19 23:02:41 nina-fd JobId 13962: DIR and FD clocks differ by 233
seconds, FD
Hi folks.
I've got a problem whereby my email and web servers sometimes fail to backup.
These two servers are inside the DMZ and backup to the server inside my LAN.
The problem appears to be the inactivity on the connection after the data has
been backed up while the database is being
Since adding Heartbeat Interval (set to 15 seconds) on our clients'
FileDaemon definition as well as the Director definition in
bacula-dir.conf and the Storage definition in bacula-sd.conf, it has
fixed some of the firewall timeout issues that we've had backing up some
clients but we've also
bat ERROR in lib/smartall.c:121 Failed ASSERT: nbytes 0
This particular message is generated because some calling method is
passing in a 0 to the SmartAlloc methods as the number of bytes to
allocate. This is not allowed via an ASSERT condition at the top of the
actual smalloc() method in
bat ERROR in lib/smartall.c:121 Failed ASSERT: nbytes 0
This particular message is generated because some calling method is
passing in a 0 to the SmartAlloc methods as the number of bytes to
allocate. This is not allowed via an ASSERT condition at the top of the
actual smalloc() method in
I downloaded the latest stable QT open source version (4.8.2 at the
time) and built it before building Bacula 5.2.10. Bat seems to work
fine with it. If you do this, just be aware that the first time you
build it, it will probably find the older 4.6.x RH QT libraries and
embed their location
This may be a stupid question but is the working state data, that are
cached on the client and used to display the recent job history of a
client from the tray monitor, limited to the most recent 10 job events?
Or is there a way to configure this to show and/or cache more than
just 10?
Hi,
We're running 5.2.10 for both Windows 7 clients and our servers. My
system admins have noticed that when during restores of files to a
Windows 7 client that the restored files are all hidden which requires
them to then go in and uncheck the hide protected operating system files
option.
This actually is a hardcoded sanity check in the code itself. Search
the mailing lists from the past year. I'm pretty sure I posted where in
the code this was and what needed to be changed. We have no jobs that
run more than a few days so have not made such changes ourselves so I
can't
I am running version 5.2.9 on my director and file daemon. I am
able to backup successfully but when I attempt to restore data onto
the 32bit Windows 2003 file daemon the bacula service terminates on
the 2003 server and the restore job fails. I can choose a Linux
file daemon as the target
Restores to the Windows client systematically crash the FD on the
client without restoring anything. This seems to be a known, as
yet unsolved problem. There are several posts on this on the list.
Yes, we have the same problem. For now, we have rolled back our Windows
clients to 5.0.3 which
Jon,
I believe I posted this same issue back in April and didn't get any
replies. I never did submit it as a bug but it does seem to be a bug to me.
http://sourceforge.net/mailarchive/forum.php?thread_name=4F8ECD71.8080203%40mtl.mit.eduforum_name=bacula-users
Perhaps I'll go ahead and post a
Before I submit this as a possible bug, I just wanted to see if perhaps
it is the expected behavior for Bacula.
We have a few long running jobs that take 24 hours to do a Full
backup. Because of this, we have the following set:
Allow Duplicate Jobs = no
Cancel Lower Level Duplicates = yes
The update postgres script for 5.2.x is missing these two lines which
you can run manually from within psql (connect to the bacula db as your
Postgres admin db user):
grant all on RestoreObject to ${bacula_db_user};
grant select, update on restoreobject_restoreobjectid_seq to
In an effort to work around the fact that bacula kills long-running
jobs, I'm about to partition my backups into smaller sets. For example,
instead of backing up:
Since we may end up having jobs that run for more than 6 days, I was
pretty curious to see where in the code (release 5.0.3) this
Just to followup on this in case others have this issue. I was able to
rebuild bacula with the -g compiler option to get some debugging
information. The scenario that causes the SD to crash with a SEGFAULT
is not consistently reproducible which makes me think of some kind of
race condition.
Hi,
We've been seeing our Bacula Storage Daemon die with a segmentation
fault when a client can't be reached for backup. We have two servers
and have observed this behavior on both of them. Some searching has
revealed that others seem to have (or had) this same issue.
57 matches
Mail list logo
