Hi,
Sorry to warm up this slightly old discussion, but since I'm suffering
from a similar problem, I just stumpled upon this thread while
searching for a solution.
In my setting, it's a disk-to-disk-to-tape setup, I'm writing the data
from my clients to a RAID-6 storage (15 x 1,5TB storage system). Via a
Copy job the full backups are to be copied to a Tandberg 24-slot LTO-4
changer (one drive).
According to "btape speed", this drive can have rates up to 214 MB per
second with default data, and about 104 MB per second with the random
data test.
When copying file volumes with dd, I get up to 90 MB per second throughput.
The copy job itself does only write with speeds between 5 and 20 MB
per second according to the bacula job output, while reading about 180
MB per second from the storage disk.
I'm very concerned about this, because I got to manage 130 clients
with a overall volume of 5 Terabyte, and with that low copy speed, it
takes almost more time than the schedule interval for the full backups
has to offer, so I'm open for any hints on speeding up this issue.
My setting is quite simple. All incremental jobs are in the
FileStorage-Default pool, all full jobs are in the FileStorage-Full
pool with TapeCopyPool as nextpool reference, and the third pool is
the TapeCopyPool, where the tapes reside. Then there is one copy job
with "PoolUncopiedJobs" set.
So, AFAIK quite simple, but not completely working as I expected.
2010/6/22 Lukas Kolbe <l-lists AT einfachkaffee DOT de>:
> Am Montag, den 21.06.2010, 11:27 -0400 schrieb John Drescher:
>> On Mon, Jun 21, 2010 at 7:35 AM, Lukas Kolbe <l-lists AT einfachkaffee DOT
>> de> wrote:
>> > Am Montag, den 21.06.2010, 11:06 +0100 schrieb Alan Brown:
>> >> On 21/06/10 10:56, Lukas Kolbe wrote:
>> >> >
>> >> > For comparison, I dd'ed a volume to /dev/null while the copy job was
>> >> > running:
>> >> > [root@shepherd ~]# dd if=/var/bacula/dp/fs1/Vol0070 of=/dev/null bs=1M
>> >> > 9175040000 bytes (9.2 GB) copied, 12.0225 seconds, 763 MB/s
>> >> >
>> >> > But dd'ing it to another file reveals a problem with the storage
>> >> > subsystem I believe:
>> >> >
>> >> > [root@shepherd ~]# dd if=/var/bacula/dp/fs1/Vol0070
>> >> > of=/var/bacula/dp/fs2/xxx bs=1M
>> >> > 849346560 bytes (849 MB) copied, 32.665 seconds, 26.0 MB/s
>> >> >
>>
>> Do you have a hardware raid controller without a BBunit and thus the
>> write cache is disabled to protect corruption that could occur if the
>> machine crashed or lost power?
>
> We have a BBU and the write cache is enabled. Puzzling is that the now,
> and repeatedly, the same dd during the copy job works with
> 350MiB/second. That dd slowness must have been a one-off.
>
> I skimmed the bacula-sd code (mac.c and block.c) and do see why it is
> not so simple to change the way copy jobs work, though.
>
>> John
>
> --
> Lukas
--
Le deagh dhùraghd,
Frank Altpeter
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
