From: yesi [mailto:yesi AT altern DOT org]
Sent: Wednesday, February 02, 2011 11:21 AM
To: John Drescher
Cc: Bacula-users AT lists.sourceforge DOT net
Subject: Re: [Bacula-users] IBM 3573-TL, LTO5, speed

On Tue, Feb 1, 2011 at 6:56 PM, John Drescher <drescherjm AT gmail DOT com> wrote:

5.0.3 would be better since it has several bug fixes for problems in
5.0.2 and earlier.

> I use the tape library TS3100 with a IBM 3573-TL.
>
> Questions:
> 1) mount a tape to the drive 2
> 2) speed up the backup with LTO5
>
>
> 1)
> And i've got 2 drives.
> A drive 1 is mounted with a tape e.g. LT00X.
> And i'd like to use the drive 2. So i've mounted it with a tape : LT00Y.
> Then, the drive 2 is loaded with the tape - LT00Y-, but it is said that
> drive is mounted with the tape LT00X !
>
>> *mount drive=1 storage=Drive-2
>> slot=9
>> 3301 Issuing autochanger "loaded? drive 1"
>> command.
>> 3302 Autochanger "loaded? drive 1", result: nothing
>> loaded.
>> 3304 Issuing autochanger "load slot 9, drive 1"
>> command.
>> 3305 Autochanger "load slot 9, drive 1", status is
>> OK.
>> 3902 Cannot mount Volume on Storage Device "Drive-2" (/dev/nst1)
>> because:
>> label.c:239 Could not reserve volume LT1002L5 on "Drive-2"
>> (/dev/nst1)
>> 3001 Device "Drive-2" (/dev/nst1) is already mounted with Volume
>> "LT1002L5"
>
>
>>
>>  Device "Drive-1" (/dev/nst0) is mounted with:
>>     Volume:      LT1002L5
>>     Pool:        *unknown*
>>     Media type:  LTO-5
>>     Slot 2 is loaded in drive 0.
>>     Total Bytes=96,637,943,808 Blocks=1,497,983 Bytes/block=64,512
>>     Positioned at File=8 Block=9,896
>> Device "Drive-2" (/dev/nst1) is mounted with:
>>     Volume:      LT1002L5
>>     Pool:        *unknown*
>>     Media type:  LTO-5
>>     Slot 9 is loaded in drive 1.
>>     Total Bytes Read=64,512 Blocks Read=1 Bytes/block=64,512
>>     Positioned at File=0 Block=0
>
> The drive 2 should have mounted with LT00Y but not LT00X !
> Could someone explain me about this behaviour, please ?
>
>

I can say that sometimes the status storage is not up to date
especially when it lists "unknown" for the pool.

>
> Here's my bacula-sd.conf
>
>> Autochanger {
>>   Name = Autochanger
>>   Device =
>> Drive-1
>>   Device =
>> Drive-2
>>   Changer Command = "/etc/bacula/scripts/mtx-changer %c %o %S %a %d"
>>   Changer Device = /dev/sg3
>> }
>>
>> Device {
>>   Name = Drive-1                      #
>>   Drive Index = 0
>>   Media Type = LTO-5                            # Library 3573-TL
>>   Archive Device = /dev/nst0
>>   AutomaticMount = yes;               # when device opened, read it
>>   AlwaysOpen = yes;
>>   RemovableMedia = yes;
>>   RandomAccess = no;
>>   AutoChanger = yes
>>   Maximum File Size = 12GB
>>   Spool Directory = "/data/spool"
>>   Maximum Spool Size = 100gb
>>   Maximum Job Spool Size = 60gb
>>   Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'"
>> }
>>
>> Device {
>>   Name = Drive-2                      #
>>   Drive Index = 1
>>   Media Type = LTO-5                    # Library 3573-TL
>>   Archive Device = /dev/nst1
>>   AutomaticMount = yes;               # when device opened, read it
>>   AlwaysOpen = yes;
>>   RemovableMedia = yes;
>>   RandomAccess = no;
>>   AutoChanger = yes
>>   Maximum File Size = 12GB
>>   Spool Directory = "/data/spool"
>>   Maximum Spool Size = 100gb
>>   Maximum Job Spool Size = 60gb
>> Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'"
>> }
>
>
>
> 2) The speed of my backup is not very fast:
> Rate:                   43362.5 KB/s

That is fast to me with LTO2. Consider the following:
1. spooling and despooling are not concurrent so when it is spooling
it is not writing to tape and when it is writing to tape the backup is
paused on the client.

2. Look at the despool rate for actual disk to tape speed not the
finished job speed.

3. Unless you are reading from a fast raid 43 MB/s is actually pretty
fast considering backing up causes heavy thrashing and is very seek
oriented.

4. If this is not a "Full" backup expect slow raw rates because bacula
spends most of the time searching for the files that have changed.

Even with #1 I still recommend leaving spooling on and maximizing your
throughput by using concurrent backups with more than 1 client at a
time.

John