Re: [Bacula-users] Bacula backup speed

2015-12-17 Thread Robert Oschwald 
We got approx 80 mio entries in the file table and I confirm Alan.

Before, we had MySQL 5.5 with 24GB buffer ram, but attribute insertions took 
ages.
Then we migrated the DB to PostgreSQL and the issue resolved.

1 year ago, we migrated the physical backup Server to a vCenter VM and lowered 
the memory of the VM dramatically to 4GB (not kidding).
No issues since then. Speed is still really good. We do B2D2T.



> Am 17.12.2015 um 12:34 schrieb Uwe Schuerkamp :
> 
> On Tue, Dec 15, 2015 at 05:16:42PM +, Alan Brown wrote:
>> 
>> MySQL works ok for small sites but doesn't scale well. PostgreSQL is a 
>> heavy load on small installations but will keep running long after MySQL 
>> has decided to use all your system ram and swap too. The breakeven point 
>> is about 10-15 million entries. Beyond that point MySQL needs endless 
>> tuning and PostgreSQL doesn't.
> 
> 
> Hm, I cannot confirm your observation here. Our largest catalog has
> 600,000,000 file table entries on a 64GB server that also runs the
> director with about half of that allocated to the innodb buffers, and
> while it's not exactly a speed daemon when restoring stuff it's also
> no slouch, backing up over 300 clients and about 10TB of data on
> average every day. I doubt postgres would perform much better with a
> similar sized catalog on the same hardware.
> 
> We're using MariaDB 5.5x if that has anything to do with it.
> 
> All the best,
> 
> Uwe
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --
> ___
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users


--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Bacula backup speed

2015-12-17 Thread Uwe Schuerkamp 
On Tue, Dec 15, 2015 at 05:16:42PM +, Alan Brown wrote:
> 
> MySQL works ok for small sites but doesn't scale well. PostgreSQL is a 
> heavy load on small installations but will keep running long after MySQL 
> has decided to use all your system ram and swap too. The breakeven point 
> is about 10-15 million entries. Beyond that point MySQL needs endless 
> tuning and PostgreSQL doesn't.


Hm, I cannot confirm your observation here. Our largest catalog has
600,000,000 file table entries on a 64GB server that also runs the
director with about half of that allocated to the innodb buffers, and
while it's not exactly a speed daemon when restoring stuff it's also
no slouch, backing up over 300 clients and about 10TB of data on
average every day. I doubt postgres would perform much better with a
similar sized catalog on the same hardware.

We're using MariaDB 5.5x if that has anything to do with it.

All the best,

Uwe









--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Bacula backup speed

2015-12-16 Thread Phil Stracchino 
On 12/15/15 20:22, Bryn Hughes wrote:
> MySQL is clever enough that it won't assign memory until it actually 
> needs it.

This is true to a point.  It is NOT true of the InnoDB buffer pool,
which is pre-allocated at startup time and cannot be dynamically resized
prior to MySQL 5.7.

It is generally accepted that the "sweet spot" for InnoDB performance
begins with the buffer pool size 25% to 30% larger than the total volume
of InnoDB data plus indices.  However, the unconfigured compiled-in
default size is 8MB.  If you have an 8MB buffer pool and 300MB of data
you will be hurting.  I would advise that you set your InnoDB buffer
pool somewhere in the range of 512MB to 1GB for now, and monitor for
data growth.

Other things you want to consider:
- What MySQL version are you running?  The 5.5 branch will be
end-of-life on December 31, and anything older already is.  At this
point you should be running 5.6 or 5.7.
- If you're running 5.5 or later, you should be using innodb_file_format
= Barracuda.  This becomes the default in 5.7.
- If you're running 5.5 or later, you should also be using
innodb_file_per_table.  This id the default from 5.6 on.
- If you want to change either of those two after the fact, the best
method is to do a full dump, reinitialize the InnoDB global tablespace,
then reload.
- Consider Percona Server.  It is free to use and has a number of
performance tweaks and improvements vs. community MySQL.  Also, it
includes meaningfully useful hash algorithms for checksumming.  While
you're at it, consider installing Percona Toolkit.

(Community MySQL supports only MD5, which is slow, and crc32, which is
worthless.  Percona Server adds fnv64 and murmur, both of which are
cryptographically secure and much faster than MD5.)


-- 
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: 603.293.8485

--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Bacula backup speed

2015-12-16 Thread Uwe Schuerkamp 
I fully agree with Bryn here, 8GB would be overkill for a 300MB
database. Just make sure mysql has enough memory to keep your largest
DB in RAM, so increasing the buffer pool if necessary always seems
like a good option.


> > We have 659,172 entries in the File table.

That is quite a small catalog, indeed. Given that you're using innodb
as the db engine your bacula instance should be performing much better
than it currently is. It might be a good idea to check the db for any
corrupt tables or indices then.

All the best, Uwe

--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Bacula backup speed

2015-12-15 Thread Alan Brown 
On 15/12/15 13:20, Heitor Faria wrote:

> Suggestion: http://bacula.us/tuning/

Whilst that page is a good starting point, a couple of points are flat 
out wrong:

EG: setting maximum block size in tapes - DON'T SET THIS - EVER (unless 
the driver manufacturer advises it)

Compression should only _ever_ be used on disk backups (tapes generally 
have their own hardware compression engines) and not at all if the 
underlaying filesystem uses compression (eg: ZFS)

LTOs run so fast that disk spooling needs to be solid state (ramdisk or 
SSD) on SATA3/SAS2

Hardware RAID controllers are generally a waste of time on modern 
systems. Stick with MD-raid (This applies to Linux and BSD)

MySQL works ok for small sites but doesn't scale well. PostgreSQL is a 
heavy load on small installations but will keep running long after MySQL 
has decided to use all your system ram and swap too. The breakeven point 
is about 10-15 million entries. Beyond that point MySQL needs endless 
tuning and PostgreSQL doesn't.

Define non-transparent huge pages. MySQL and PostGreSQL will both use 
them better than transparent ones.

Enough memory is a critical factor. Put in as much as you think you need 
and then double it. 300 million file entries will need 48GB for 
PostgreSQL and at least double that for MySQL if you want to avoid 
swapping and keep the system usable for actual backups as well as 
database activities.

A fast CPU isn't important until you do lots of database work. It's more 
important to keep the ram base speed as fast as possible - 1333MHZ 
instead of 800MHz, etc. If this means paying more for 8*32GB dimms 
instead of 16*16GB dimms, that's a worthwhile investment.

The tuning recommendations for PgSQL are long-outdated. See 
postgresql.org for better ones (shared buffers should be much larger on 
large systems for starters)


None of the above stuff is going to make any difference to the primary 
problem the OP has: -  Extremely poor backup speed across the network to 
disk before attribute despooling takes place which also has extremely 
poor speeds. Something, somewhere is badly compromising disk and/or 
network throughput. The cause must be found/resolved before any other 
work can have meaningful results.




--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Bacula backup speed

2015-12-15 Thread Uwe Schuerkamp 
On Mon, Dec 14, 2015 at 09:12:06PM +, Lewis, Dave wrote:
> Hi,
> 
> Thanks. I ran it again with attribute spooling. That sped up the backup of 
> data to the disk pool - instead of 6 hours it took less than 2 - but writing 
> the file metadata afterwards took nearly 6 hours.
> 
> 12-Dec 18:24 jubjub-sd JobId 583: Job write elapsed time = 01:51:55, Transfer 
> rate = 703.0 K Bytes/second
> 12-Dec 18:24 jubjub-sd JobId 583: Sending spooled attrs to the Director.  
> Despooling 120,266,153 bytes ...
> 13-Dec 00:11 jubjub-dir JobId 583: Bacula jubjub-dir 5.2.6 (21Feb12):
>   Elapsed time:   7 hours 39 mins 13 secs
>   FD Files Written:   391,552
>   SD Files Written:   391,552
>   FD Bytes Written:   4,486,007,552 (4.486 GB)
>   SD Bytes Written:   4,720,742,979 (4.720 GB)
>   Rate:   162.8 KB/s
>   Software Compression:   None
>   Encryption: yes
>   Accurate:   no
> 
> So the transfer rate increased from about 200 KB/s to about 700 KB/s, but the 
> total elapsed time increased.
> 

Hi Dave,

how large is your catalog database? How many entries do you have in
your File table, for instance? Attribute despooling should be much
faster than what you're seeing even on SATA disks. 

I guess your mysql setup could do with some optimization w/r to buffer
pool size (I hope you're using InnoDB as the backend db engine) and
lock / write strategies.

As your DB runs on the director machine, I'd assign at last 50% of the
available RAM if your catalog has a similar size.

A quick google search came up with the following query to determine
your catalog db size: 

SELECT table_schema "DB Name",
Round(Sum(data_length + index_length) / 1024 / 1024, 1) "DB Size in MB" FROM 
information_schema.tables GROUP BY table_schema;

All the best, Uwe




--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Bacula backup speed

2015-12-15 Thread Josh Fisher 


On 12/14/2015 5:19 PM, Lewis, Dave wrote:
> We are running MySQL, and the database is on the same server as the director. 
> The disk that the database is on is a 7200 RPM, 3 Gb/s SATA disk.

What else is writing to this same disk when the metadata is being written?

>
> Thanks,
> Dave
>
>
> -Original Message-
> From: Bryn Hughes [mailto:li...@nashira.ca]
> Sent: Monday, December 14, 2015 4:37 PM
> To: bacula-users@lists.sourceforge.net
> Subject: Re: [Bacula-users] Bacula backup speed
>
> Sounds pretty clear that you have some performance issues on your database.
>
> What are you running (MySQL/Postgresql/Sqlite/etc) for your DB? Is it running 
> on the same server as your director?  What kind of disk storage do you have 
> under your database?
>
> Bryn
>
> On 2015-12-14 01:12 PM, Lewis, Dave wrote:
>> Hi,
>>
>> Thanks. I ran it again with attribute spooling. That sped up the backup of 
>> data to the disk pool - instead of 6 hours it took less than 2 - but writing 
>> the file metadata afterwards took nearly 6 hours.
>>
>> 12-Dec 18:24 jubjub-sd JobId 583: Job write elapsed time = 01:51:55,
>> Transfer rate = 703.0 K Bytes/second 12-Dec 18:24 jubjub-sd JobId 583: 
>> Sending spooled attrs to the Director.  Despooling 120,266,153 bytes ...
>> 13-Dec 00:11 jubjub-dir JobId 583: Bacula jubjub-dir 5.2.6 (21Feb12):
>> Elapsed time:   7 hours 39 mins 13 secs
>> FD Files Written:   391,552
>> SD Files Written:   391,552
>> FD Bytes Written:   4,486,007,552 (4.486 GB)
>> SD Bytes Written:   4,720,742,979 (4.720 GB)
>> Rate:   162.8 KB/s
>> Software Compression:   None
>> Encryption: yes
>> Accurate:   no
>>
>> So the transfer rate increased from about 200 KB/s to about 700 KB/s, but 
>> the total elapsed time increased.
>>
>> Thanks,
>> Dave
>>
>>
>> -Original Message-
>> From: Christian Manal [mailto:moen...@informatik.uni-bremen.de]
>> Sent: Thursday, December 10, 2015 6:14 AM
>> To: bacula-users@lists.sourceforge.net
>> Subject: Re: [Bacula-users] Bacula backup speed
>>
>> On 10.12.2015 01:06, Lewis, Dave wrote:
>>> Does anyone know what's causing the OS backups to be so slow and what
>>> I can do to speed them up?
>> Hi,
>>
>> the problem might be number of files, as in, writing all the file metadata 
>> to the catalog could very well be your bottle neck.
>>
>> Try enabling attribute spooling, so all the metadata is collected and 
>> commited to the DB in one go instead of file by file.
>>
>>
>> Regards,
>> Christian Manal
>>
>> --
>>  ___
>> Bacula-users mailing list
>> Bacula-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bacula-users
>> IMPORTANT NOTICE: This e-mail is meant only for the use of the intended 
>> recipient. It may contain confidential information which is legally 
>> privileged or otherwise protected by law. If you received this e-mail in 
>> error or from someone who is not authorized to send it to you, you are 
>> strictly prohibited from reviewing, using, disseminating, distributing or 
>> copying the e-mail. PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN 
>> E-MAIL AND DELETE THIS MESSAGE FROM YOUR SYSTEM. Thank you for your 
>> cooperation.
>>
>> --
>>  ___
>> Bacula-users mailing list
>> Bacula-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
> --
> ___
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
> IMPORTANT NOTICE: This e-mail is meant only for the use of the intended 
> recipient. It may contain confidential information which is legally 
> privileged or otherwise protected by law. If you received this e-mail in 
> error or from someone who is not authorized to send it to you, you are 
> strictly prohibited from reviewing, using, disseminating, distributing or 
> copying the e-mail. PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN 
> E-MAIL AND DELETE THIS MESSAGE FROM YOUR SYSTEM. Thank you for your 
> cooperation.
>
> --
> ___
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users


--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Bacula backup speed

2015-12-15 Thread Lewis, Dave 
> -Original Message-
> From: Uwe Schuerkamp [mailto:uwe.schuerk...@nionex.net]
> Sent: Tuesday, December 15, 2015 4:47 AM
> To: Lewis, Dave
> Cc: bacula-users@lists.sourceforge.net
> Subject: Re: [Bacula-users] Bacula backup speed
>
...
> Hi Dave,
>
> how large is your catalog database? How many entries do you have in
> your File table, for instance? Attribute despooling should be much
> faster than what you're seeing even on SATA disks.

Hi Uwe,

I don't know much about databases, but I'm learning.

We have 659,172 entries in the File table.


> I guess your mysql setup could do with some optimization w/r to buffer
> pool size (I hope you're using InnoDB as the backend db engine) and
> lock / write strategies.

The command
SHOW TABLE STATUS;
shows that we're using InnoDB.


> As your DB runs on the director machine, I'd assign at last 50% of the
> available RAM if your catalog has a similar size.
>
> A quick google search came up with the following query to determine
> your catalog db size:
>
> SELECT table_schema "DB Name",
> Round(Sum(data_length + index_length) / 1024 / 1024, 1) "DB Size in MB"
> FROM information_schema.tables GROUP BY table_schema;
>
> All the best, Uwe

The above command gave
++---+
| DB Name| DB Size in MB |
++---+
| bacula | 216.6 |
| information_schema | 0.0   |
++---+

To assign 50% of RAM (we have 16 GB total) I suppose I should add the line
innodb_buffer_pool_size = 8G
in /etc/mysql/my.cnf, then I assume restart MySQL. But maybe we don't need it 
that big at this time, since the database is much smaller.

Our my.cnf doesn't currently have a line for innodb_buffer_pool_size; I don't 
know what it uses by default.

Thanks,
Dave
IMPORTANT NOTICE: This e-mail is meant only for the use of the intended 
recipient. It may contain confidential information which is legally privileged 
or otherwise protected by law. If you received this e-mail in error or from 
someone who is not authorized to send it to you, you are strictly prohibited 
from reviewing, using, disseminating, distributing or copying the e-mail. 
PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AND DELETE THIS 
MESSAGE FROM YOUR SYSTEM. Thank you for your cooperation.

--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Bacula backup speed

2015-12-15 Thread Lewis, Dave 
> -Original Message-
> From: Heitor Faria [mailto:hei...@bacula.com.br]
> Sent: Tuesday, December 15, 2015 8:21 AM
> To: Alan Brown
> Cc: Lewis, Dave; bacula-users@lists.sourceforge.net
> Subject: Re: [Bacula-users] Bacula backup speed
>
...
>
> Suggestion: http://bacula.us/tuning/

Thanks, I'll check it out.
Dave

>
> Regards,
> ===
> 
> Heitor Medrado de Faria - LPIC-III | ITIL-F | Bacula Systems Certified
> Administrator II Do you need Bacula training? http://bacula.us/video-
> classes/
> +55 61 8268-4220
> Site: http://bacula.us FB: heitor.faria
> ===
> 
IMPORTANT NOTICE: This e-mail is meant only for the use of the intended 
recipient. It may contain confidential information which is legally privileged 
or otherwise protected by law. If you received this e-mail in error or from 
someone who is not authorized to send it to you, you are strictly prohibited 
from reviewing, using, disseminating, distributing or copying the e-mail. 
PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AND DELETE THIS 
MESSAGE FROM YOUR SYSTEM. Thank you for your cooperation.
--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Bacula backup speed

2015-12-15 Thread Alan Brown 
On 14/12/15 22:19, Lewis, Dave wrote:
> We are running MySQL, and the database is on the same server as the director. 
> The disk that the database is on is a 7200 RPM, 3 Gb/s SATA disk.

What size is your database? ("select count(*) from File;")
What write speeds are you actually achieving to the database drive? 
(MB/s and iops - "iostat -kxt 2" will tell you this)

How much ram does the server have?
How much swap?
how much Swap activity is there?
How much swap is in use?

Have you tuned your MySQL?
is MySQL writing lots of temp files?
Are you using MyISAM or InnoDB?

If the MySQL is larger than 8-10 million entries, why aren't you using 
Postgresql?

What is the network environment? (speeds? switches? hubs? subnets? Routers?)

700kB/sec is an abysmal rate for backup to disk unless you're running on 
10Mb/s thinnet.
Why is it so awful?

Solve that first, THEN look at the attribute despooling issue.


> Thanks,
> Dave
>
>
> -Original Message-
> From: Bryn Hughes [mailto:li...@nashira.ca]
> Sent: Monday, December 14, 2015 4:37 PM
> To:bacula-users@lists.sourceforge.net
> Subject: Re: [Bacula-users] Bacula backup speed
>
> Sounds pretty clear that you have some performance issues on your database.
>
> What are you running (MySQL/Postgresql/Sqlite/etc) for your DB? Is it running 
> on the same server as your director?  What kind of disk storage do you have 
> under your database?
>
> Bryn
>
> On 2015-12-14 01:12 PM, Lewis, Dave wrote:
>> Hi,
>>
>> Thanks. I ran it again with attribute spooling. That sped up the backup of 
>> data to the disk pool - instead of 6 hours it took less than 2 - but writing 
>> the file metadata afterwards took nearly 6 hours.
>>
>> 12-Dec 18:24 jubjub-sd JobId 583: Job write elapsed time = 01:51:55,
>> Transfer rate = 703.0 K Bytes/second 12-Dec 18:24 jubjub-sd JobId 583: 
>> Sending spooled attrs to the Director.  Despooling 120,266,153 bytes ...
>> 13-Dec 00:11 jubjub-dir JobId 583: Bacula jubjub-dir 5.2.6 (21Feb12):
>> Elapsed time:   7 hours 39 mins 13 secs
>> FD Files Written:   391,552
>> SD Files Written:   391,552
>> FD Bytes Written:   4,486,007,552 (4.486 GB)
>> SD Bytes Written:   4,720,742,979 (4.720 GB)
>> Rate:   162.8 KB/s
>> Software Compression:   None
>> Encryption: yes
>> Accurate:   no
>>
>> So the transfer rate increased from about 200 KB/s to about 700 KB/s, but 
>> the total elapsed time increased.
>>
>> Thanks,
>> Dave
>>
>>
>> -Original Message-
>> From: Christian Manal [mailto:moen...@informatik.uni-bremen.de]
>> Sent: Thursday, December 10, 2015 6:14 AM
>> To:bacula-users@lists.sourceforge.net
>> Subject: Re: [Bacula-users] Bacula backup speed
>>
>> On 10.12.2015 01:06, Lewis, Dave wrote:
>>> Does anyone know what's causing the OS backups to be so slow and what
>>> I can do to speed them up?
>> Hi,
>>
>> the problem might be number of files, as in, writing all the file metadata 
>> to the catalog could very well be your bottle neck.
>>
>> Try enabling attribute spooling, so all the metadata is collected and 
>> commited to the DB in one go instead of file by file.
>>
>>
>> Regards,
>> Christian Manal
>>
>> --
>>  ___
>> Bacula-users mailing list
>> Bacula-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bacula-users
>> IMPORTANT NOTICE: This e-mail is meant only for the use of the intended 
>> recipient. It may contain confidential information which is legally 
>> privileged or otherwise protected by law. If you received this e-mail in 
>> error or from someone who is not authorized to send it to you, you are 
>> strictly prohibited from reviewing, using, disseminating, distributing or 
>> copying the e-mail. PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN 
>> E-MAIL AND DELETE THIS MESSAGE FROM YOUR SYSTEM. Thank you for your 
>> cooperation.
>>
>> --
>>  ___
>> Bacula-users mailing list
>> Bacula-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bacula-users
> --
> ___
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
>

Re: [Bacula-users] Bacula backup speed

2015-12-15 Thread Heitor Faria 

>> We are running MySQL, and the database is on the same server as the director.
>> The disk that the database is on is a 7200 RPM, 3 Gb/s SATA disk.
> 
> What size is your database? ("select count(*) from File;")
> What write speeds are you actually achieving to the database drive?
> (MB/s and iops - "iostat -kxt 2" will tell you this)
> 
> How much ram does the server have?
> How much swap?
> how much Swap activity is there?
> How much swap is in use?
> 
> Have you tuned your MySQL?
> is MySQL writing lots of temp files?
> Are you using MyISAM or InnoDB?

Suggestion: http://bacula.us/tuning/

Regards,
=== 
Heitor Medrado de Faria - LPIC-III | ITIL-F | Bacula Systems Certified 
Administrator II 
Do you need Bacula training? http://bacula.us/video-classes/ 
+55 61 8268-4220 
Site: http://bacula.us FB: heitor.faria 
=== 

--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Bacula backup speed

2015-12-15 Thread Lewis, Dave 
> -Original Message-
> From: Alan Brown [mailto:a...@mssl.ucl.ac.uk]
> Sent: Tuesday, December 15, 2015 8:08 AM
> To: Lewis, Dave; bacula-users@lists.sourceforge.net
> Subject: Re: [Bacula-users] Bacula backup speed
...
> What size is your database? ("select count(*) from File;") What write
> speeds are you actually achieving to the database drive?
> (MB/s and iops - "iostat -kxt 2" will tell you this)

Enter SQL query: SELECT COUNT(*) FROM File;
+--+
| COUNT(*) |
+--+
|  659,172 |
+--+

I'll run iostat next time I test Bacula. (It's not installed on this server -- 
thanks for the suggestion and the command.)


> How much ram does the server have?
> How much swap?
> how much Swap activity is there?
> How much swap is in use?

It's got 16 GB RAM and 16 GB swap space. I didn't check if it was using a lot 
of swap space during the test backup. However the database size is around 200 
MB, so I wouldn't think that swapping would be a problem. I'll check next time 
I test Bacula to be sure I'm not missing something.


> Have you tuned your MySQL?
> is MySQL writing lots of temp files?
> Are you using MyISAM or InnoDB?

We're using InnoDB. I haven't tuned MySQL.

I don't know how to check if MySQL is writing lots of temp files.


> If the MySQL is larger than 8-10 million entries, why aren't you using
> Postgresql?
>
> What is the network environment? (speeds? switches? hubs? subnets?
> Routers?)
>
> 700kB/sec is an abysmal rate for backup to disk unless you're running
> on 10Mb/s thinnet.
> Why is it so awful?
>
> Solve that first, THEN look at the attribute despooling issue.

I'm currently testing just local backups to disk, in order to eliminate issues 
of the network and the tape drive. The Bacula / MySQL server has gigabit 
Ethernet and is connected to a 10 Gbps switch, as are most of the other servers 
that we will be backing up.

Thanks,
Dave

IMPORTANT NOTICE: This e-mail is meant only for the use of the intended 
recipient. It may contain confidential information which is legally privileged 
or otherwise protected by law. If you received this e-mail in error or from 
someone who is not authorized to send it to you, you are strictly prohibited 
from reviewing, using, disseminating, distributing or copying the e-mail. 
PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AND DELETE THIS 
MESSAGE FROM YOUR SYSTEM. Thank you for your cooperation.

--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Bacula backup speed

2015-12-15 Thread Lewis, Dave 
> From: Josh Fisher [mailto:jfis...@pvct.com]
> Sent: Tuesday, December 15, 2015 6:57 AM
> To: bacula-users@lists.sourceforge.net
> Subject: Re: [Bacula-users] Bacula backup speed
>
...
>
> What else is writing to this same disk when the metadata is being
> written?

Probably not much. The database is on the same disk as the OS. The server is 
also a DICOM server and receives a few GB of medical images each day. It stores 
them on a separate disk. However, it also writes information to a log file on 
the OS disk, but the total time is probably less than 30 minutes. But I should 
check next time I test Bacula.

Thanks,
Dave

IMPORTANT NOTICE: This e-mail is meant only for the use of the intended 
recipient. It may contain confidential information which is legally privileged 
or otherwise protected by law. If you received this e-mail in error or from 
someone who is not authorized to send it to you, you are strictly prohibited 
from reviewing, using, disseminating, distributing or copying the e-mail. 
PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AND DELETE THIS 
MESSAGE FROM YOUR SYSTEM. Thank you for your cooperation.

--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Bacula backup speed

2015-12-15 Thread Bryn Hughes 
On 2015-12-15 04:50 PM, Lewis, Dave wrote:
>> -Original Message-
>> From: Uwe Schuerkamp [mailto:uwe.schuerk...@nionex.net]
>> Sent: Tuesday, December 15, 2015 4:47 AM
>> To: Lewis, Dave
>> Cc: bacula-users@lists.sourceforge.net
>> Subject: Re: [Bacula-users] Bacula backup speed
>>
> ...
>> Hi Dave,
>>
>> how large is your catalog database? How many entries do you have in
>> your File table, for instance? Attribute despooling should be much
>> faster than what you're seeing even on SATA disks.
> Hi Uwe,
>
> I don't know much about databases, but I'm learning.
>
> We have 659,172 entries in the File table.
>
>
>> I guess your mysql setup could do with some optimization w/r to buffer
>> pool size (I hope you're using InnoDB as the backend db engine) and
>> lock / write strategies.
> The command
>  SHOW TABLE STATUS;
> shows that we're using InnoDB.
>
>
>> As your DB runs on the director machine, I'd assign at last 50% of the
>> available RAM if your catalog has a similar size.
>>
>> A quick google search came up with the following query to determine
>> your catalog db size:
>>
>> SELECT table_schema "DB Name",
>> Round(Sum(data_length + index_length) / 1024 / 1024, 1) "DB Size in MB"
>> FROM information_schema.tables GROUP BY table_schema;
>>
>> All the best, Uwe
> The above command gave
> ++---+
> | DB Name| DB Size in MB |
> ++---+
> | bacula | 216.6 |
> | information_schema | 0.0   |
> ++---+
>
> To assign 50% of RAM (we have 16 GB total) I suppose I should add the line
>  innodb_buffer_pool_size = 8G
> in /etc/mysql/my.cnf, then I assume restart MySQL. But maybe we don't need it 
> that big at this time, since the database is much smaller.
>
> Our my.cnf doesn't currently have a line for innodb_buffer_pool_size; I don't 
> know what it uses by default.
>
> Thanks,
> Dave
>
MySQL is clever enough that it won't assign memory until it actually 
needs it.  Since your DB is only 216MB it shouldn't end up taking the 
full 8GB no matter what happens.  However during attribute despooling 
the buffer pool isn't really coming in to play that much; you aren't 
doing any SELECT queries during an insert so cached data isn't going to 
help.  On restore however the buffer pool will be handy.

One other thing you may wish to look at is adding this line to your my.cnf:

innodb_flush_log_at_trx_commit=2

By default MySQL is trying to write each INSERT to disk one at a time 
which isn't really necessary with something like bacula.  It makes more 
sense in the case of financial transactions or something like that.  The 
above command will have MySQL flush out writes in batches once per 
second rather than trying to hit the disk (and wait) for each one.  This 
can make a significant improvement in attribute spooling.  A single 7200 
RPM disk can't handle more than about 90 transactions per second, so the 
fewer individual disk transactions that are occurring the better.

Bryn

--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Bacula backup speed

2015-12-15 Thread Gary R. Schmidt 
Hi Dave,

On 2015-12-16 12:39, Lewis, Dave wrote:
>> -Original Message-
>> From: Alan Brown [mailto:a...@mssl.ucl.ac.uk]
>> Sent: Tuesday, December 15, 2015 8:08 AM
>> To: Lewis, Dave; bacula-users@lists.sourceforge.net
>> Subject: Re: [Bacula-users] Bacula backup speed
> ...
>> What size is your database? ("select count(*) from File;") What write
>> speeds are you actually achieving to the database drive?
>> (MB/s and iops - "iostat -kxt 2" will tell you this)
> 
> Enter SQL query: SELECT COUNT(*) FROM File;
> +--+
> | COUNT(*) |
> +--+
> |  659,172 |
> +--+
> 

This is nothing.

I have an LTO-6 running on a Solaris 10 x64 system with 8Gb of RAM, with 
141734865 File entries.

This system drives the LTO-6 at near its maximum speed, but it does use 
fibre-channel, so a lot of interface-related speed problems go away.  
(Previously it ran an LTO-4 using UW-SCSI, it was fast enough but 
occasionally just flaked out, FC is the bees knees!!)

Also, ignore the guff about needing SSD's to feed the tape, my system 
runs on a ZFS pool of 3 * 1Tb disks to spool on, and the MySQL InnoDB 
files also live on this pool, in ZFS file systems configured for the 
best performance of MySQL.

Fix your network problems, first, as other ahve said.  It could be 
anything, from dodgy NICs, or badly configured switches.  Or just *one* 
10meg switch stuck somewhere that nobody knows about!  (This happened to 
me a couple of years ago, the Preventors of Information Services in 
Networking insisted that it was all 100Mb, eventually a real network 
engineer and I did the "trace the physical cables" and found that 
someone had put an ancient 10Meg switch in one of the cabinets.  Cue 
complete denial and "It doesn't exist" from the eejits, we just swapped 
a couple of cables and I got the speed I wanted, perhaps someone lost 
some!)

I prefer Intel NICs for machines that have a need for network 
performance, even my peecees at home have them in preference to the 
on-board RealTeks or whatever.

Tune your database.  I used the script at http://mysqltuner.pl a few 
years ago, it's been fine since.

Make sure that the temporary file space al

Did you build Bacula yourself, or are you using some sort of 
pre-packaged version?

If you built it yourself, did you enable batch inserts on the database?  
If it's pre-packaged, ask the package maintainer.

And check that it really does have batch mode available.

And that it is spooling attributes as well.  (You may have already 
answered this.)

TL;DR - go over your network with a fine-tooth comb, and follow the 
advice from the mysqltuner.pl script.

 Cheers,
 GaryB-)


--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Bacula backup speed

2015-12-14 Thread Bryn Hughes 
Sounds pretty clear that you have some performance issues on your database.

What are you running (MySQL/Postgresql/Sqlite/etc) for your DB? Is it 
running on the same server as your director?  What kind of disk storage 
do you have under your database?

Bryn

On 2015-12-14 01:12 PM, Lewis, Dave wrote:
> Hi,
>
> Thanks. I ran it again with attribute spooling. That sped up the backup of 
> data to the disk pool - instead of 6 hours it took less than 2 - but writing 
> the file metadata afterwards took nearly 6 hours.
>
> 12-Dec 18:24 jubjub-sd JobId 583: Job write elapsed time = 01:51:55, Transfer 
> rate = 703.0 K Bytes/second
> 12-Dec 18:24 jubjub-sd JobId 583: Sending spooled attrs to the Director.  
> Despooling 120,266,153 bytes ...
> 13-Dec 00:11 jubjub-dir JobId 583: Bacula jubjub-dir 5.2.6 (21Feb12):
>Elapsed time:   7 hours 39 mins 13 secs
>FD Files Written:   391,552
>SD Files Written:   391,552
>FD Bytes Written:   4,486,007,552 (4.486 GB)
>SD Bytes Written:   4,720,742,979 (4.720 GB)
>Rate:   162.8 KB/s
>Software Compression:   None
>Encryption: yes
>Accurate:   no
>
> So the transfer rate increased from about 200 KB/s to about 700 KB/s, but the 
> total elapsed time increased.
>
> Thanks,
> Dave
>
>
> -Original Message-
> From: Christian Manal [mailto:moen...@informatik.uni-bremen.de]
> Sent: Thursday, December 10, 2015 6:14 AM
> To: bacula-users@lists.sourceforge.net
> Subject: Re: [Bacula-users] Bacula backup speed
>
> On 10.12.2015 01:06, Lewis, Dave wrote:
>> Does anyone know what's causing the OS backups to be so slow and what
>> I can do to speed them up?
> Hi,
>
> the problem might be number of files, as in, writing all the file metadata to 
> the catalog could very well be your bottle neck.
>
> Try enabling attribute spooling, so all the metadata is collected and 
> commited to the DB in one go instead of file by file.
>
>
> Regards,
> Christian Manal
>
> --
> ___
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
> IMPORTANT NOTICE: This e-mail is meant only for the use of the intended 
> recipient. It may contain confidential information which is legally 
> privileged or otherwise protected by law. If you received this e-mail in 
> error or from someone who is not authorized to send it to you, you are 
> strictly prohibited from reviewing, using, disseminating, distributing or 
> copying the e-mail. PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN 
> E-MAIL AND DELETE THIS MESSAGE FROM YOUR SYSTEM. Thank you for your 
> cooperation.
>
> --
> ___
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users


--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Bacula backup speed

2015-12-14 Thread Lewis, Dave 
We are running MySQL, and the database is on the same server as the director. 
The disk that the database is on is a 7200 RPM, 3 Gb/s SATA disk.

Thanks,
Dave


-Original Message-
From: Bryn Hughes [mailto:li...@nashira.ca]
Sent: Monday, December 14, 2015 4:37 PM
To: bacula-users@lists.sourceforge.net
Subject: Re: [Bacula-users] Bacula backup speed

Sounds pretty clear that you have some performance issues on your database.

What are you running (MySQL/Postgresql/Sqlite/etc) for your DB? Is it running 
on the same server as your director?  What kind of disk storage do you have 
under your database?

Bryn

On 2015-12-14 01:12 PM, Lewis, Dave wrote:
> Hi,
>
> Thanks. I ran it again with attribute spooling. That sped up the backup of 
> data to the disk pool - instead of 6 hours it took less than 2 - but writing 
> the file metadata afterwards took nearly 6 hours.
>
> 12-Dec 18:24 jubjub-sd JobId 583: Job write elapsed time = 01:51:55,
> Transfer rate = 703.0 K Bytes/second 12-Dec 18:24 jubjub-sd JobId 583: 
> Sending spooled attrs to the Director.  Despooling 120,266,153 bytes ...
> 13-Dec 00:11 jubjub-dir JobId 583: Bacula jubjub-dir 5.2.6 (21Feb12):
>Elapsed time:   7 hours 39 mins 13 secs
>FD Files Written:   391,552
>SD Files Written:   391,552
>FD Bytes Written:   4,486,007,552 (4.486 GB)
>SD Bytes Written:   4,720,742,979 (4.720 GB)
>Rate:   162.8 KB/s
>Software Compression:   None
>Encryption: yes
>Accurate:   no
>
> So the transfer rate increased from about 200 KB/s to about 700 KB/s, but the 
> total elapsed time increased.
>
> Thanks,
> Dave
>
>
> -Original Message-
> From: Christian Manal [mailto:moen...@informatik.uni-bremen.de]
> Sent: Thursday, December 10, 2015 6:14 AM
> To: bacula-users@lists.sourceforge.net
> Subject: Re: [Bacula-users] Bacula backup speed
>
> On 10.12.2015 01:06, Lewis, Dave wrote:
>> Does anyone know what's causing the OS backups to be so slow and what
>> I can do to speed them up?
> Hi,
>
> the problem might be number of files, as in, writing all the file metadata to 
> the catalog could very well be your bottle neck.
>
> Try enabling attribute spooling, so all the metadata is collected and 
> commited to the DB in one go instead of file by file.
>
>
> Regards,
> Christian Manal
>
> --
>  ___
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
> IMPORTANT NOTICE: This e-mail is meant only for the use of the intended 
> recipient. It may contain confidential information which is legally 
> privileged or otherwise protected by law. If you received this e-mail in 
> error or from someone who is not authorized to send it to you, you are 
> strictly prohibited from reviewing, using, disseminating, distributing or 
> copying the e-mail. PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN 
> E-MAIL AND DELETE THIS MESSAGE FROM YOUR SYSTEM. Thank you for your 
> cooperation.
>
> --
>  ___
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users


--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
IMPORTANT NOTICE: This e-mail is meant only for the use of the intended 
recipient. It may contain confidential information which is legally privileged 
or otherwise protected by law. If you received this e-mail in error or from 
someone who is not authorized to send it to you, you are strictly prohibited 
from reviewing, using, disseminating, distributing or copying the e-mail. 
PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AND DELETE THIS 
MESSAGE FROM YOUR SYSTEM. Thank you for your cooperation.

--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Bacula backup speed

2015-12-14 Thread Lewis, Dave 
Hi,

Thanks. I ran it again with attribute spooling. That sped up the backup of data 
to the disk pool - instead of 6 hours it took less than 2 - but writing the 
file metadata afterwards took nearly 6 hours.

12-Dec 18:24 jubjub-sd JobId 583: Job write elapsed time = 01:51:55, Transfer 
rate = 703.0 K Bytes/second
12-Dec 18:24 jubjub-sd JobId 583: Sending spooled attrs to the Director.  
Despooling 120,266,153 bytes ...
13-Dec 00:11 jubjub-dir JobId 583: Bacula jubjub-dir 5.2.6 (21Feb12):
  Elapsed time:   7 hours 39 mins 13 secs
  FD Files Written:   391,552
  SD Files Written:   391,552
  FD Bytes Written:   4,486,007,552 (4.486 GB)
  SD Bytes Written:   4,720,742,979 (4.720 GB)
  Rate:   162.8 KB/s
  Software Compression:   None
  Encryption: yes
  Accurate:   no

So the transfer rate increased from about 200 KB/s to about 700 KB/s, but the 
total elapsed time increased.

Thanks,
Dave


-Original Message-
From: Christian Manal [mailto:moen...@informatik.uni-bremen.de]
Sent: Thursday, December 10, 2015 6:14 AM
To: bacula-users@lists.sourceforge.net
Subject: Re: [Bacula-users] Bacula backup speed

On 10.12.2015 01:06, Lewis, Dave wrote:
> Does anyone know what's causing the OS backups to be so slow and what
> I can do to speed them up?

Hi,

the problem might be number of files, as in, writing all the file metadata to 
the catalog could very well be your bottle neck.

Try enabling attribute spooling, so all the metadata is collected and commited 
to the DB in one go instead of file by file.


Regards,
Christian Manal

--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
IMPORTANT NOTICE: This e-mail is meant only for the use of the intended 
recipient. It may contain confidential information which is legally privileged 
or otherwise protected by law. If you received this e-mail in error or from 
someone who is not authorized to send it to you, you are strictly prohibited 
from reviewing, using, disseminating, distributing or copying the e-mail. 
PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AND DELETE THIS 
MESSAGE FROM YOUR SYSTEM. Thank you for your cooperation.

--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Bacula backup speed

2015-12-10 Thread Christian Manal 
On 10.12.2015 01:06, Lewis, Dave wrote:
> Does anyone know what’s causing the OS backups to be so slow and what I
> can do to speed them up?

Hi,

the problem might be number of files, as in, writing all the file
metadata to the catalog could very well be your bottle neck.

Try enabling attribute spooling, so all the metadata is collected and
commited to the DB in one go instead of file by file.


Regards,
Christian Manal

--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Bacula backup speed

2015-12-10 Thread Uwe Schuerkamp 
On Thu, Dec 10, 2015 at 12:06:42AM +, Lewis, Dave wrote:
> Hi,
> 
> I'm configuring Bacula backups and sometimes it is very slow to back up to 
> disk or tape, around 1 MB/s and sometimes slower. I'm wondering why it is 
> sometimes so slow and if there is something I can do differently that will 
> speed up the backups. I want to do backups of about 1 TB (or more) of user 
> data, and 1 MB/s is far too slow. I also want to back up operating systems of 
> various Linux servers and imaging data (currently stored locally).
> 
> As a test, I ran a Bacula backup of several operating system directories of 
> the backup computer, and it took about 6 hours. Here are details:
> The directories were /bin, /boot, /etc, /lib, /lib64, /opt, /root, /sbin, 
> /srv, /usr
> Level = Full
> Disk pool
> Computed SHA1 signature
> >From the log file:
> 02-Dec 20:16 jubjub-sd JobId 547: Job write elapsed time = 06:03:29, Transfer 
> rate = 216.4 K Bytes/second
> Elapsed time:   6 hours 13 mins 54 secs
> FD Files Written:   391,549
> SD Files Written:   391,549
> FD Bytes Written:   4,486,000,544 (4.486 GB)
> SD Bytes Written:   4,720,733,845 (4.720 GB)
> Rate:   200.0 KB/s
> Software Compression:   None
> Encryption: yes
> Accurate:   no
> 

Hello Dave,

well, it depends. ;-) On a lot of things, actually. What DB backend
are you using? Is the db optimized for bacula usage? How fast are your
disks? Are you using attribute / job spooling? What's the hardware
spec of the director / sd machine? What's your connection / max
throughput to the clients?

All the best, Uwe

-- 








--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Bacula backup speed

2015-12-10 Thread Lewis, Dave 
Hi Uwe,

We are using MySQL. It hasn't been optimized for bacula usage. I installed both 
bacula and mysql via apt-get. We aren't using spooling. These are just local 
backups. The director / sd machine was bought in 2009 and has 2 Intel Xeon 
E5410, 2.33 GHz CPUs and 16 GB memory. Disks are SATA. I'm out of town today 
and tomorrow and will try to find other specs tonight or this weekend.

I ran another test: I backed up the imaging data tarfiles to the same disk pool 
as I used for the operating system test backup. The rate was 23 MB/s, same as 
backup of the imaging data tarfiles to tape.

Thanks!
Dave


From: Uwe Schuerkamp [uwe.schuerk...@nionex.net]
Sent: Thursday, December 10, 2015 6:30 AM
To: Lewis, Dave
Cc: bacula-users@lists.sourceforge.net
Subject: Re: [Bacula-users] Bacula backup speed

On Thu, Dec 10, 2015 at 12:06:42AM +, Lewis, Dave wrote:
> Hi,
>
> I'm configuring Bacula backups and sometimes it is very slow to back up to 
> disk or tape, around 1 MB/s and sometimes slower. I'm wondering why it is 
> sometimes so slow and if there is something I can do differently that will 
> speed up the backups. I want to do backups of about 1 TB (or more) of user 
> data, and 1 MB/s is far too slow. I also want to back up operating systems of 
> various Linux servers and imaging data (currently stored locally).
>
> As a test, I ran a Bacula backup of several operating system directories of 
> the backup computer, and it took about 6 hours. Here are details:
> The directories were /bin, /boot, /etc, /lib, /lib64, /opt, /root, /sbin, 
> /srv, /usr
> Level = Full
> Disk pool
> Computed SHA1 signature
> >From the log file:
> 02-Dec 20:16 jubjub-sd JobId 547: Job write elapsed time = 06:03:29, Transfer 
> rate = 216.4 K Bytes/second
> Elapsed time:   6 hours 13 mins 54 secs
> FD Files Written:   391,549
> SD Files Written:   391,549
> FD Bytes Written:   4,486,000,544 (4.486 GB)
> SD Bytes Written:   4,720,733,845 (4.720 GB)
> Rate:   200.0 KB/s
> Software Compression:   None
> Encryption: yes
> Accurate:   no
>

Hello Dave,

well, it depends. ;-) On a lot of things, actually. What DB backend
are you using? Is the db optimized for bacula usage? How fast are your
disks? Are you using attribute / job spooling? What's the hardware
spec of the director / sd machine? What's your connection / max
throughput to the clients?

All the best, Uwe

--







IMPORTANT NOTICE: This e-mail is meant only for the use of the intended 
recipient. It may contain confidential information which is legally privileged 
or otherwise protected by law. If you received this e-mail in error or from 
someone who is not authorized to send it to you, you are strictly prohibited 
from reviewing, using, disseminating, distributing or copying the e-mail. 
PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AND DELETE THIS 
MESSAGE FROM YOUR SYSTEM. Thank you for your cooperation.

--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users