An update, since a few people asked for something.
I need to backtrack on my original statement that removing compression didn't
make a difference, I must have forgotten to restart the director after making
the change.
In fact switching from GZIP to LZO had the greatest performance gain, even
I think the sqlite backend and the large number of small files are
most likely slowing you down. Isn't sqlite explicitly *not*
recommended for production use in the bacula docs?
Also, using compression won't help with raw backup speed unless you
switch to LZO which enables near disk-speed reads wh
I would really like to know how much speed gain you get when you switch
to Mysql or Postgres, please
post it here, thanks.
On 6/21/2016 1:36 PM, fgd9329g wrote:
> This might be a dumb question, but I can't figure it out.
>
> Debian 8
> Bacula Version: 5.2.6
> sqlite3 -version 3.8.7.1
> Backing
Hello, have you tried to change the bacula database for MySQL or Postgres?
Best regards
Wanderlei Hüttel
Enviado de Motorola Moto X2
Em 21 de jun de 2016 11:21 PM, "fgd9329g"
escreveu:
> This might be a dumb question, but I can't figure it out.
>
> Debian 8
> Bacula Version: 5.2.6
> sqlite3 -ve
This might be a dumb question, but I can't figure it out.
Debian 8
Bacula Version: 5.2.6
sqlite3 -version 3.8.7.1
Backing up to disks, not tape.
I have two bacula systems, both have this same slowness issue. Here's what the
final output of our largest job looks like:
Elapsed time: 4
Hello,
I have had performance issues with version 1.36 and 1.37.x too.
Setting the FD's "Maximum Network Buffer Size = 65536" (instead of
the default 32k) gave a dramatic speed improvement. Though I don't
know if the default has changed for 1.38.
It might be worth trying.
Greetings,
Uwe
Kern Sibbald wrote:
> Another thing that tends to slow down backups is lots of hard links. In that
> case, you will see the CPU usage of the FD go above 90%.
I do not have any hardlinks that I am aware of.
> Also, I don't know whether or not Tracy is speaking about Full backups or
> others.
Another thing that tends to slow down backups is lots of hard links. In that
case, you will see the CPU usage of the FD go above 90%.
Also, I don't know whether or not Tracy is speaking about Full backups or
others. It makes no sense to try to look at backup rates as produced by
Bacula for a
Tracy R Reed wrote:
Karl Cunningham wrote:
How many files are you backing up? There is a database insert for every
file that gets backed up. Are you sure there isn't a lot of disk
thrashing going on for database IO? What if you temporarily put the
database on your usb disk to see if that m
On Tue, 1 Nov 2005, Tracy R Reed wrote:
We've found here that USB2 is quite slow for filestorage on linux systems
but I haven't had time to investigate why.
You mean like if I just cp -a my homedir to the USB disk? That is
exactly what I did when I first plugged in the USB disk. It's blazing
f
Karl Cunningham wrote:
> How many files are you backing up? There is a database insert for every
> file that gets backed up. Are you sure there isn't a lot of disk
> thrashing going on for database IO? What if you temporarily put the
> database on your usb disk to see if that makes a differen
Tracy R Reed wrote:
Karl Cunningham wrote:
Tracy --
I noticed in the release notes for 1.38.0 the following:
- Note, with gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5) on an
AMD64 CPU running 64 bit CentOS4, there is a compiler bug that
generates bad code that causes Bacula to segment fault.
Tracy R Reed wrote:
Ok, so over the course of the last few days I think I have got just
about everything figured out. I have a full backup of all three of my
systems safely on DVD, I can restore, it does incrementals automatically
every night, I am happy.
Except for one thing: The backups are VE
Karl Cunningham wrote:
> Tracy --
>
> I noticed in the release notes for 1.38.0 the following:
>
> - Note, with gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5) on an
>AMD64 CPU running 64 bit CentOS4, there is a compiler bug that
>generates bad code that causes Bacula to segment fault.
>Ty
On Mon, 31 Oct 2005, Tracy R Reed wrote:
New datapoint: I am now backing up to my recently acquired USB2 hard
drive using file storage and the backup speeds are very slow just like
with DVD. So it can't be disk bandwidth or DVD issues. Still have 95%
idle cpu time during backup.
What happens i
Alan Brown wrote:
> What happens if you just do block copies to the USB disk?
>
> We've found here that USB2 is quite slow for filestorage on linux systems
> but I haven't had time to investigate why.
You mean like if I just cp -a my homedir to the USB disk? That is
exactly what I did when I fir
New datapoint: I am now backing up to my recently acquired USB2 hard
drive using file storage and the backup speeds are very slow just like
with DVD. So it can't be disk bandwidth or DVD issues. Still have 95%
idle cpu time during backup.
Tracy R Reed wrote:
> Ok, so over the course of the last fe
Phil Stracchino wrote:
> Have you investigated a database bottleneck? What SQL backend are you
> using? What's system CPU load during backup?
I am using SQLite3. There is 95% idle cpu during the backup.
--
Tracy R Reed
http://copilotconsulting.com
---
Tracy R Reed wrote:
> Ok, so over the course of the last few days I think I have got just
> about everything figured out. I have a full backup of all three of my
> systems safely on DVD, I can restore, it does incrementals automatically
> every night, I am happy.
>
> Except for one thing: The back
Ok, so over the course of the last few days I think I have got just
about everything figured out. I have a full backup of all three of my
systems safely on DVD, I can restore, it does incrementals automatically
every night, I am happy.
Except for one thing: The backups are VERY slow. Even the host
20 matches
Mail list logo
