Re: LTO8 tape profile - amtapetype

[Luc Lalonde]

Here's mine:

define tapetype LTO8-compoff {
    comment "Created by amtapetype; compression disabled"
    comment "/usr/sbin/amtapetype -f -b 1024k /dev/nst2"
    length 11732915200 kbytes
    filemark 5006 kbytes
    speed 172710 kps
    blocksize 1024 kbytes
}

It's an FC drive on a Dell ML3 Tape Library.

On 2021-09-28 3:00 p.m., Chris Hoogendyk wrote:
You should get substantially faster. That said, throughput to the tape 
will depend on a lot of things about your system and where the 
bottleneck actually is. The maximum throughput of dual SAS2 is 
6Gbit/s, which would be 750MB/s. So, you aren't likely to come close 
to the 900MB/s for compressible data that LTO8 is rated for. If there 
are other things going on using the SAS bandwidth, like your hard 
drive systems, then that bites into what's available for pushing out 
to tape. Then there is the cpu for generating the data stream.


I've only gotten up to LTO7. However, it took some tweaking of my 
supermicro servers to approach the rated speed for the LTO7. The tape 
drives are on a dedicated SAS card. The disk drives are on a separate 
SAS card. My servers have two cpus with I think 16 core each, and 64GB 
memory. So, even though they are doing a lot of other stuff, Amanda 
can still push the LTO7 approaching its rated speed.



On 9/28/21 5:10 AM, David Simpson wrote:


Just ran amtapetype against an LTO8 tape + HP MSL3040 (with SAS 
drives). Debian 11.


Some observations:

-compression on, expected
-length looks ok

-speed .. should I have expected more? Seemed a bit low I thought..

-no LEOM.. I don’t know if it’s the hardware or the Debian 11 kernel 
or both, though understand this is not essential




Checking for FSF_AFTER_FILEMARK requirement

Applying heuristic check for compression.

Wrote random (uncompressible) data at 96137551.7377049 bytes/sec

Wrote fixed (compressible) data at 167554018.742857 bytes/sec

Compression: enabled

Writing one file to fill the volume.

Wrote 12011529469952 bytes at 94902 kb/sec

Writing smaller files (120115265536 bytes) to determine filemark.

define tapetype unknown-tapetype {

comment "Created by amtapetype; compression enabled"

length 11730009248 kbytes

filemark 4132 kbytes

speed 94902 kps

blocksize 32 kbytes

}

# LEOM is not supported for this drive and kernel





-

David Simpson - Senior Systems Engineer

ARCCA, Redwood Building,

King Edward VII Avenue,

Cardiff, CF10 3NB

David Simpson - peiriannydd uwch systemau

ARCCA, Adeilad Redwood,

King Edward VII Avenue,

Caerdydd, CF10 3NB

simpso...@cardiff.ac.uk <mailto:simpso...@cardiff.ac.uk>

+44 29208 74657


--
Luc Lalonde, analyste
-
Département de génie informatique:
École polytechnique de MTL
(514) 340-4711 x5049
luc.lalo...@polymtl.ca
-




OpenPGP_signature
Description: OpenPGP digital signature

Tape partitionning

[Luc Lalonde]

Hello Folks,

Since LTO-4, we're supposed to be able to partition the tapes.

Is this supported by Amanda?   If so, what tools are you using to 
partition the tapes?


Thank You!

--
Luc Lalonde, analyste
-
Département de génie informatique:
École polytechnique de MTL
(514) 340-4711 x5049
luc.lalo...@polymtl.ca
-




OpenPGP_signature
Description: OpenPGP digital signature

Re: tape device order in amanda.conf

[Luc Lalonde]

Ok, thanks for the tip:

[root@ulysses ~]# su amandabackup -c '/usr/sbin/amtape Mensuel-LTO7 verify'
GOOD : Drive 0 is device tape:/dev/nst1
GOOD : Drive 1 is device tape:/dev/nst0
property "TAPE-DEVICE" "0=tape:/dev/nst1" "1=tape:/dev/nst0"

Best regards, Luc.


On 2018-01-15 08:10 AM, Jean-Louis Martineau wrote:

Luc,

The assignment of 'Data Transfer Element 0' to '/dev/nst1' and 'Data
Transfer Element 1' to '/dev/nst0' is done by the kernel.

You can use the 'amtape CONF verify' command to check if you correctly
configured amanda.

Jean-Louis


On 13/01/18 06:40 PM, Luc Lalonde wrote:
> Hello Folks,
>
> I’m getting a strange result when I do an ‘amcheck’:
>
> slot 3: Tape device /dev/nst1 is not ready or is empty
> slot 4:Slot 4, label '000279L7', mismatch barcode between changer 
'000280L7' and tapelist file '000279L7'
> ERROR: Slot 4, label '000279L7', mismatch barcode between changer 
'000280L7' and tapelist file ‘000279L7'

>
> Here’s what I have in my config file:
>
> define changer spectra-robot {
> tapedev "chg-robot:/dev/changer"
> property "tape-device” "0=tape:/dev/nst0"
> property append "tape-device” "1=tape:/dev/nst1"
> device-property "BLOCK_SIZE" "512k"
> property "use-slots" "1-47”
> }
>
> To get rid of the problem, I reverse the tape device order:
>
> define changer spectra-robot {
> tapedev "chg-robot:/dev/changer"
> property "tape-device" "1=tape:/dev/nst0"
> property append "tape-device" "0=tape:/dev/nst1"
> device-property "BLOCK_SIZE" "512k"
> property "use-slots" "1-47”
> }
>
> Here’s the pertinent lines of the ‘amcheck’ after having made this 
change:

>
> slot 3: volume '000279L7'
> Will write to volume '000279L7' in slot 3.
>
> What going on? If it can help, here’s the output of ‘lsscsi -g’ (I 
removed the non-tape + changer lines):

>
> [1:0:4:0] tape IBM ULTRIUM-HH7 G9Q1 /dev/st0 /dev/sg10
> [2:0:4:0] tape IBM ULTRIUM-HH7 G9Q1 /dev/st1 /dev/sg13
> [2:0:4:1] mediumx SPECTRA PYTHON 2000 /dev/sch0 /dev/sg14
>
> And here’s an output of the first few lines of the command ‘mtx status’:
> Data Transfer Element 0
>
> Storage Changer /dev/changer:2 Drives, 48 Slots ( 1 Import/Export )
> Data Transfer Element 0:Empty
> Data Transfer Element 1:Full (Storage Element 3 Loaded):VolumeTag = 
000279L7

> Storage Element 1:Full :VolumeTag=000277L7
> Storage Element 2:Full :VolumeTag=000278L7
> Storage Element 3:Empty
> Storage Element 4:Full :VolumeTag=000280L7
>
> I’m using a 50 slot SpectraLogic T50e library with two LTO7 IBM drives.
>
> Thanks!
>
>
>
>
>


*Disclaimer*

This message is the property of *CARBONITE, INC.* 
<http://www.carbonite.com> and may contain confidential or privileged 
information.


If this message has been delivered to you by mistake, then do not copy 
or deliver this message to anyone. Instead, destroy it and notify me 
by reply e-mail.




--
Luc Lalonde, analyste
-
Département de génie informatique:
École polytechnique de MTL
(514) 340-4711 x5049
luc.lalo...@polymtl.ca
-

tape device order in amanda.conf

[Luc Lalonde]

Hello Folks,

I’m getting a strange result when I do an ‘amcheck’:

slot 3: Tape device /dev/nst1 is not ready or is empty
slot 4:Slot 4, label '000279L7', mismatch barcode between changer '000280L7' 
and tapelist file '000279L7'
ERROR: Slot 4, label '000279L7', mismatch barcode between changer '000280L7' 
and tapelist file ‘000279L7'

Here’s what I have in my config file:

define changer spectra-robot {
tapedev "chg-robot:/dev/changer"
property "tape-device” "0=tape:/dev/nst0"
property append "tape-device” "1=tape:/dev/nst1"
device-property "BLOCK_SIZE" "512k"
property "use-slots" "1-47”
}

To get rid of the problem, I reverse the tape device order:

define changer spectra-robot {
tapedev "chg-robot:/dev/changer"
property "tape-device" "1=tape:/dev/nst0"
property append "tape-device" "0=tape:/dev/nst1"
device-property "BLOCK_SIZE" "512k"
property "use-slots" "1-47”
}

Here’s the pertinent lines of the ‘amcheck’ after having made this change:

slot 3: volume '000279L7'
Will write to volume '000279L7' in slot 3.

What going on?  If it can help, here’s the output of ‘lsscsi -g’ (I removed the 
non-tape + changer lines):

[1:0:4:0]tapeIBM  ULTRIUM-HH7  G9Q1  /dev/st0   /dev/sg10
[2:0:4:0]tapeIBM  ULTRIUM-HH7  G9Q1  /dev/st1   /dev/sg13
[2:0:4:1]mediumx SPECTRA  PYTHON   2000  /dev/sch0  /dev/sg14

And here’s an output of the first few lines of the command ‘mtx status’:

Storage Changer /dev/changer:2 Drives, 48 Slots ( 1 Import/Export )
Data Transfer Element 0:Empty
Data Transfer Element 1:Full (Storage Element 3 Loaded):VolumeTag = 000279L7

  Storage Element 1:Full :VolumeTag=000277L7
  Storage Element 2:Full :VolumeTag=000278L7
  Storage Element 3:Empty
  Storage Element 4:Full :VolumeTag=000280L7

I’m using a 50 slot SpectraLogic T50e library with two LTO7 IBM drives.

Thanks!

Re: Amtapetype wrongly reporting compression?

[Luc Lalonde]

Hello Gene,

Would a variant like this:

    /usr/sbin/mtx load 1 0;
    /usr/bin/mt -f /dev/st0 compression 0;
    /usr/bin/mt -f /dev/st0 setblk 524288;
    /usr/bin/dd if=/dev/zero of=/dev/st0 bs=512k count=1;
    su amandabackup -c "/usr/sbin/amlabel -f Monthly-LTO7 000321L7 
slot 1";

    /usr/sbin/mtx unload 1 0;

work?

During my tests with this, the hardware compression stays disabled when 
I load a new tape.


Thanks!


On 2018-01-11 10:51 PM, Gene Heskett wrote:

1. rewind the tape.
1a. Do NOT remove tape from drive, or cause it to read the tape other
than what I write here until after step 5.
2. read the label out to a 32k file.
3. rewind the tape.
4. Turn the compression off, probably with mt.
5. Immediately re-write that label while the tape is rewound, and the
hidden tape id block in front of the label will get rewritten too, with
that compression flag off.


--
Luc Lalonde, analyste
-
Département de génie informatique:
École polytechnique de MTL
(514) 340-4711 x5049
luc.lalo...@polymtl.ca
-

Re: Amtapetype wrongly reporting compression?

[Luc Lalonde]

Hello Jean-Louis and Debra,

I'll re-run the 'amtapetype' with 512k blocksize and get back to soon 
(depending on how long it takes)


Thanks your your help, Luc.


On 2018-01-11 03:31 PM, Debra S Baddorf wrote:

After research, I started using 512k blocks,  3 years ago,  for LTO5 tapes.
For LTO7  I might have to research even more, but certainly 512k or bigger.

Debra Baddorf
Fermilab




On Jan 11, 2018, at 2:09 PM, Jean-Louis Martineau <jmartin...@carbonite.com> 
wrote:

Luc,

amtapetype use speed heuristic to detect if the drive is in compressed
mode, it might not be good for newer drives.

Why you didn't post the complete amtapetype output? I can't tell you why
the heuristic is bad without those numbers.

The default block size of 32k was good 15 years ago, but it is really
bad for new drives. You should really think about increasing it a lot.

Jean-Louis

On 11/01/18 02:56 PM, Luc Lalonde wrote:

I sent the wrong output in the last email Here's the correct
'tapeinfo':

Product Type: Tape Drive
Vendor ID: 'IBM '
Product ID: 'ULTRIUM-HH7 '
Revision: 'G9Q1'
Attached Changer API: No
SerialNumber: '123456789A'
MinBlock: 1
MaxBlock: 8388608
SCSI ID: 4
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: 0x78
Density Code: 0x5c
BlockSize: 32768
DataCompEnabled: no
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0xff
DeCompType: 0xff
BOP: yes
Block Position: 0
Partition 0 Remaining Kbytes: -1
Partition 0 Size in Kbytes: -1
ActivePartition: 0
EarlyWarningSize: 0
NumPartitions: 0
MaxPartitions: 3

Further, here's my '/etc/stinit.def':

manufacturer="IBM" model = "ULTRIUM-HH7" {
scsi2logical=1
can-bsr=1
auto-lock=1
two-fms=0
drive-buffering=1
buffer-writes
read-ahead=1
async-writes=1
can-partitions=1
fast-mteom=0
sysv=1
timeout=180
long-timeout=14400
mode1 blocksize=32768 compression=1
mode2 blocksize=32768 compression=0
mode3 disabled=1
mode4 disabled=1

Sorry, about that!

On 2018-01-11 02:43 PM, Luc Lalonde wrote:

Hello Folks,

I'm wondering if there's a bug with 'Amtapetype' (version 3.5.1).

We're migrating from LTO5 to LTO7 and I'm getting strange results
when I run 'amtapetype'.

Here's what I get after roughly 35 hours:

define tapetype LTO7 {
comment "Created by amtapetype; compression enabled"
length 5874932832 kbytes
filemark 1813 kbytes
speed 118310 kps
blocksize 32 kbytes
}

Why is it saying that it can write roughly 6Tb if it's supposedly
hardware compressed? LTO7 is supposed to give a compression ration
of 2.5 to 1.

I've disabled compression... Here's the ouptut of 'tapeinfo:

[root@ulysses ~]# tapeinfo -f /dev/sg12
Product Type: Tape Drive
Vendor ID: 'IBM '
Product ID: 'ULTRIUM-HH7 '
Revision: 'G9Q1'
Attached Changer API: No
SerialNumber: '123456789A'
MinBlock: 1
MaxBlock: 8388608
SCSI ID: 4
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: 0x78
Density Code: 0x5c
BlockSize: 32768
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0xff
DeCompType: 0xff
Block Position: 2
Partition 0 Remaining Kbytes: -1
Partition 0 Size in Kbytes: -1
ActivePartition: 0
EarlyWarningSize: 0
NumPartitions: 0
MaxPartitions: 3

Am I missing something?

Thanks!|



Disclaimer

This message is the property of CARBONITE, INC. and may contain confidential or 
privileged information.

If this message has been delivered to you by mistake, then do not copy or 
deliver this message to anyone. Instead, destroy it and notify me by reply 
e-mail.





--
Luc Lalonde, analyste
-
Département de génie informatique:
École polytechnique de MTL
(514) 340-4711 x5049
luc.lalo...@polymtl.ca
-

Re: Amtapetype wrongly reporting compression?

[Luc Lalonde]

I sent the wrong output in the last email Here's the correct 'tapeinfo':

Product Type: Tape Drive
Vendor ID: 'IBM '
Product ID: 'ULTRIUM-HH7 '
Revision: 'G9Q1'
Attached Changer API: No
SerialNumber: '123456789A'
MinBlock: 1
MaxBlock: 8388608
SCSI ID: 4
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: 0x78
Density Code: 0x5c
BlockSize: 32768
DataCompEnabled: no
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0xff
DeCompType: 0xff
BOP: yes
Block Position: 0
Partition 0 Remaining Kbytes: -1
Partition 0 Size in Kbytes: -1
ActivePartition: 0
EarlyWarningSize: 0
NumPartitions: 0
MaxPartitions: 3

Further, here's my '/etc/stinit.def':

manufacturer="IBM" model = "ULTRIUM-HH7" {
scsi2logical=1
can-bsr=1
auto-lock=1
two-fms=0
drive-buffering=1
buffer-writes
read-ahead=1
async-writes=1
can-partitions=1
fast-mteom=0
sysv=1
timeout=180
long-timeout=14400
mode1 blocksize=32768 compression=1
mode2 blocksize=32768 compression=0
mode3 disabled=1
mode4 disabled=1

Sorry, about that!

On 2018-01-11 02:43 PM, Luc Lalonde wrote:

Hello Folks,

I'm wondering if there's a bug with 'Amtapetype' (version 3.5.1).

We're migrating from LTO5 to LTO7 and I'm getting strange results when 
I run 'amtapetype'.


Here's what I get after roughly 35 hours:

define tapetype LTO7 {
    comment "Created by amtapetype; compression enabled"
    length 5874932832 kbytes
    filemark 1813 kbytes
    speed 118310 kps
    blocksize 32 kbytes
}

Why is it saying that it can write roughly 6Tb if it's supposedly 
hardware compressed?  LTO7 is supposed to give a compression ration of 
2.5 to 1.


I've disabled compression... Here's the ouptut of 'tapeinfo:

[root@ulysses ~]# tapeinfo -f /dev/sg12
Product Type: Tape Drive
Vendor ID: 'IBM '
Product ID: 'ULTRIUM-HH7 '
Revision: 'G9Q1'
Attached Changer API: No
SerialNumber: '123456789A'
MinBlock: 1
MaxBlock: 8388608
SCSI ID: 4
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: 0x78
Density Code: 0x5c
BlockSize: 32768
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0xff
DeCompType: 0xff
Block Position: 2
Partition 0 Remaining Kbytes: -1
Partition 0 Size in Kbytes: -1
ActivePartition: 0
EarlyWarningSize: 0
NumPartitions: 0
MaxPartitions: 3

Am I missing something?

Thanks!|



--
Luc Lalonde, analyste
-
Département de génie informatique:
École polytechnique de MTL
(514) 340-4711 x5049
luc.lalo...@polymtl.ca
-

Amtapetype wrongly reporting compression?

[Luc Lalonde]

Hello Folks,

I'm wondering if there's a bug with 'Amtapetype' (version 3.5.1).

We're migrating from LTO5 to LTO7 and I'm getting strange results when I 
run 'amtapetype'.


Here's what I get after roughly 35 hours:

define tapetype LTO7 {
comment "Created by amtapetype; compression enabled"
length 5874932832 kbytes
filemark 1813 kbytes
speed 118310 kps
blocksize 32 kbytes
}

Why is it saying that it can write roughly 6Tb if it's supposedly 
hardware compressed?  LTO7 is supposed to give a compression ration of 
2.5 to 1.


I've disabled compression... Here's the ouptut of 'tapeinfo:

[root@ulysses ~]# tapeinfo -f /dev/sg12
Product Type: Tape Drive
Vendor ID: 'IBM '
Product ID: 'ULTRIUM-HH7 '
Revision: 'G9Q1'
Attached Changer API: No
SerialNumber: '123456789A'
MinBlock: 1
MaxBlock: 8388608
SCSI ID: 4
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: 0x78
Density Code: 0x5c
BlockSize: 32768
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0xff
DeCompType: 0xff
Block Position: 2
Partition 0 Remaining Kbytes: -1
Partition 0 Size in Kbytes: -1
ActivePartition: 0
EarlyWarningSize: 0
NumPartitions: 0
MaxPartitions: 3

Am I missing something?

Thanks!|

--
Luc Lalonde, analyste
-
Département de génie informatique:
École polytechnique de MTL
(514) 340-4711 x5049
luc.lalo...@polymtl.ca
-

amreport: ERROR error: the mailer '/bin/Mail': No such file or directory

[Luc Lalonde]

Hey folks,

This is a weird error mesage:

amreport: ERROR error: the mailer '/bin/Mail': No such file or directory

Why the capital 'M'?   It should be '/bin/mail':

[root@backupserver ~]# ls -la /bin/mail
lrwxrwxrwx 1 root root 5 Nov  8 07:24 /bin/mail -> mailx

Can anyone explain this one?

Thanks!

--
Luc Lalonde, analyste
-
Département de génie informatique:
École polytechnique de MTL
(514) 340-4711 x5049
luc.lalo...@polymtl.ca
-

Amcheck fails for several clients if one of them is not reachable

[Luc Lalonde]

Hello Folks,

I think that this is an old bug that has come back in version 3.4.5.

If one of the clients is not reachable for an ‘amcheck’, then I get multiple 
errors:

#
[root@beagle amandad]# su amandabackup -c '/usr/sbin/amcheck Journalier-VTAPE'
Amanda Tape Server Host Check
-
NOTE: Holding disk '/amanda/stage/Journalier-VTAPE': 6194409472 KB disk space 
available, using 1048576000 KB as requested
Searching for label 'vtape-4':found in slot 4: volume 'vtape-4'
Will write to volume 'vtape-4' in slot 4.
NOTE: skipping tape-writable test
Server check took 0.260 seconds
Amanda Backup Client Hosts Check

ERROR: trinidad: selfcheck request failed: error sending REQ: write error to: 
Broken pipe
ERROR: ada: selfcheck request failed: error sending REQ: write error to: Broken 
pipe
ERROR: moe-alt: selfcheck request failed: error sending REQ: write error to: 
Broken pipe
ERROR: moe-180: selfcheck request failed: error sending REQ: write error to: 
Broken pipe
ERROR: ldap1: selfcheck request failed: error sending REQ: write error to: 
Broken pipe
ERROR: nanofs: selfcheck request failed: error sending REQ: write error to: 
Broken pipe
ERROR: bonne: selfcheck request failed: Connection timed out
Client check: 14 hosts checked in 392.043 seconds.  7 problems found.
(brought to you by Amanda 3.4.5)
#

The last client ‘bonne’ is down and not reachable on the network.  I remove the 
entry for that client in the ‘disklist’ and everything works fine:

#
[root@beagle amandad]# su amandabackup -c '/usr/sbin/amcheck Journalier-VTAPE'
Amanda Tape Server Host Check
-
NOTE: Holding disk '/amanda/stage/Journalier-VTAPE': 6194409472 KB disk space 
available, using 1048576000 KB as requested
Searching for label 'vtape-4':found in slot 4: volume 'vtape-4'
Will write to volume 'vtape-4' in slot 4.
NOTE: skipping tape-writable test
Server check took 0.271 seconds
Amanda Backup Client Hosts Check

Client check: 13 hosts checked in 2.175 seconds.  0 problems found.
(brought to you by Amanda 3.4.5)
#

We were using 3.3.7 not so long ago and I don’t seem to remember having this 
kind of problem when an amanda client was down.

Is this a known bug?

Thank You!

Re: Labelstr issues with 3.4.3

[Luc Lalonde]

Salut Jean-Louis,

I can confirm that the patch version 3.4.4 solves the ‘labelstr’ bug mentioned 
below.

Thank You!

> On May 3, 2017, at 4:17 AM, Stefan G. Weichinger  wrote:
> 
> Am 2017-05-02 um 15:21 schrieb Jean-Louis Martineau:
>> Bonjour Luc,
>> 
>> You found a bug, In 3.4, amanda automatically prepend a '^' and append a
>> '$' to the labelstr, It should be done only when using the autolabel
>> template.
>> 
>> I applied the attached patch to fix the issue.
>> 
>> The work around is to set labelstr to "000[0-9][0-9][0-9].*"
> 
> What about a new release like 3.4.4 or so?
> 9 weeks since 3.4.3 and quite some list of fixes since then in git.
> 
> Stefan
> 
> 

Labelstr issues with 3.4.3

[Luc Lalonde]

Hello Folks,

Since upgrading to 3.4.3 I seem to having problems with Amanda recognizing my 
tapes.

Here’s the ‘labelstr’ directive in my ‘amanda.conf’:

labelstr "^000[0-9][0-9][0-9]*”

This worked fine when I was running version 3.3.4-1…  But now, I’m getting 
errors.

Here are examples of some of my labels:

000253L5
000254L5
000276L5
000267L5
000228L
000213L
000219L

I commented out the ‘labelstr’ directive and things are working fine…  I just 
have one Amanda config using tapes…

Can someone explain what changed?

Thank You!

Balancing dumps automatically?

[Luc Lalonde]

Hello folks,

Is there a way to get Amanda to balance automatically the full dumps for a 
given configuration?

I'm using version 3.1.3 and here's a 'amadmin config balance' output:

due-date  #fsorig kB out kB   balance
--
 4/19 Tue   25  232452650  232452650   +107.4%
 4/20 Wed   21   90997530   90997530-18.8%
 4/21 Thu   20   39760030   39760030-64.5%
 4/22 Fri   21  135107180  135107180+20.5%
 4/23 Sat   20   39760030   39760030-64.5%
 4/24 Sun   20   39760030   39760030-64.5%
 4/25 Mon   20   39760030   39760030-64.5%
 4/26 Tue   21   67242650   67242650-40.0%
 4/27 Wed   21  298396590  298396590   +166.2%
 4/28 Thu   22  109601030  109601030 -2.2%
 4/29 Fri   22   65933810   65933810-41.2%
 4/30 Sat   21   50985370   50985370-54.5%
 5/01 Sun   28   78124620   78124620-30.3%
 5/02 Mon   29  281192170  281192170   +150.9%
--
TOTAL  311 1569073720 1569073720 112076694
DISTINCT51 1052193330 1052193330
  (estimated 14 runs per dumpcycle)
 (20 filesystems overdue. The most being overdue 1 day.)

Here's the pertinent section of my 'amanda.conf':

inparallel 10
netusage  100 mbps
maxdumps 2

dumpcycle 2 weeks
runspercycle 14 
tapecycle 16 tapes

bumpsize 20 Mb
bumpdays 1
bumpmult 4


I suppose that I could manually force a full dump on days were none or not many 
full dumps are scheduled...  But I thought that I'd ask the question if there 
was a way of getting amanda do that automatically.

Thanks!


-- 
Luc Lalonde, analyste
-
Département de génie informatique:
École polytechnique de Montréal
(514) 340-4711 x5049
luc.lalo...@polymtl.ca
-

Re: Balancing dumps automatically?

[Luc Lalonde]

Hello Jean-Louis,

I've not done a 'force' in a long time...  However, I've added some new DLE's 
recently.  So by default they've entered the cycle with a 'level 0'.

Maybe that's why the backups are not balanced...  It still strange that Amanda 
plans to do 311 full dumps during the cycle!

Any ideas why I'm getting this?

And 'maxpromoteday' is not specified in my configuration.  So it must be using 
the default value of '1000'.

Bye.   

- Original Message -
From: Jean-Louis Martineau martin...@zmanda.com
To: Luc Lalonde luc.lalo...@polymtl.ca
Cc: amanda-users@amanda.org
Sent: Tuesday, April 19, 2011 4:15:50 PM GMT -05:00 US/Canada Eastern
Subject: Re: Balancing dumps automatically?

Luc Lalonde wrote:
 Hello folks,

 Is there a way to get Amanda to balance automatically the full dumps for a 
 given configuration?
   

Amanda do it by default.
 I'm using version 3.1.3 and here's a 'amadmin config balance' output:

 due-date  #fsorig kB out kB   balance
 --
  4/19 Tue   25  232452650  232452650   +107.4%
  4/20 Wed   21   90997530   90997530-18.8%
  4/21 Thu   20   39760030   39760030-64.5%
  4/22 Fri   21  135107180  135107180+20.5%
  4/23 Sat   20   39760030   39760030-64.5%
  4/24 Sun   20   39760030   39760030-64.5%
  4/25 Mon   20   39760030   39760030-64.5%
  4/26 Tue   21   67242650   67242650-40.0%
  4/27 Wed   21  298396590  298396590   +166.2%
  4/28 Thu   22  109601030  109601030 -2.2%
  4/29 Fri   22   65933810   65933810-41.2%
  4/30 Sat   21   50985370   50985370-54.5%
  5/01 Sun   28   78124620   78124620-30.3%
  5/02 Mon   29  281192170  281192170   +150.9%
 --
 TOTAL  311 1569073720 1569073720 112076694
 DISTINCT51 1052193330 1052193330
   (estimated 14 runs per dumpcycle)
  (20 filesystems overdue. The most being overdue 1 day.)
   
amanda can't balance if the tape size is too small, you could increase 
runtapes.
amanda can't balance if maxpromoteday is set to a small value.
amanda might have some problem balancing the bigger dle, manual force 
can help.

You have 51 dles and amanda plan 311 full in the next dumpcycle days!!! 
Do you have dles that you force full more often?

Jean-Louis


-- 
Luc Lalonde, analyste
-
Département de génie informatique:
École polytechnique de Montréal
(514) 340-4711 x5049
luc.lalo...@polymtl.ca
-

amidxtaped v3.1.3 bug (critical (fatal): Modification of non-creatable array value attempted)

[Luc Lalonde]

Hello Dustin,

I've been re-bitten by the bug described below while doing an 'amrecover' with 
version 3.1.3

I used the same patch that you provided me for 3.1.1 on 3.1.3 and it fixed it.

My question is this:  Should this patch not be already included in '3.1.3' ???

Thanks!
- Original Message -
From: Luc Lalonde luc.lalo...@polymtl.ca
To: Dustin J. Mitchell dus...@zmanda.com
Cc: amanda-users@amanda.org
Sent: Tuesday, August 10, 2010 2:39:19 PM GMT -05:00 US/Canada Eastern
Subject: Re: amidxtaped v3.1.1 bug (critical (fatal): Modification of 
non-creatable array value attempted)

Fantastic!  That did the trick.

Will you be including this in 3.1.2?  For the moment, I patched the RPMSRC from 
the Zmanda binary repo and it works great with your modifications.

Thank you very much!

- Original Message -
From: Dustin J. Mitchell dus...@zmanda.com
To: Luc Lalonde luc.lalo...@polymtl.ca
Cc: amanda-users@amanda.org
Sent: Monday, August 9, 2010 5:53:55 PM GMT -05:00 US/Canada Eastern
Subject: Re: amidxtaped v3.1.1 bug (critical (fatal): Modification of  
non-creatable array value attempted)

Ok, I took a look at the logfiles, and they're *very* old-school.  It
looks like there's been a longstanding bug in find.c that mis-parsed
some of these log entries, and now that we're up and running with
Amanda::DB::Catalog, that mis-parsing causes failures.

I managed to reproduce this by excerpting and anonymizing a tiny bit
of a logfile.  This patch
  http://github.com/djmitche/amanda/commit/z11690.patch
passes my tests.  Can you let me know if it works for you?

Dustin

-- 
Open Source Storage Engineer
http://www.zmanda.com

-- 
Luc Lalonde, analyste
-
Département de génie informatique:
École polytechnique de Montréal
(514) 340-4711 x5049
luc.lalo...@polymtl.ca
-

-- 
Luc Lalonde, analyste
-
Département de génie informatique:
École polytechnique de Montréal
(514) 340-4711 x5049
luc.lalo...@polymtl.ca
-
From 9b62c53f9157a536082a8c7188c547b1d9515b1e Mon Sep 17 00:00:00 2001
From: Dustin J. Mitchell dus...@zmanda.com
Date: Mon, 9 Aug 2010 16:50:19 -0500
Subject: [PATCH] parse old-school 'SUCCESS taper' lines, getting partnum correct

---
 installcheck/Amanda_DB_Catalog.pl |   20 ++--
 perl/Amanda/DB/Catalog.pm |6 --
 server-src/find.c |4 +++-
 3 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/installcheck/Amanda_DB_Catalog.pl b/installcheck/Amanda_DB_Catalog.pl
index 91b3160..d29f4b7 100644
--- a/installcheck/Amanda_DB_Catalog.pl
+++ b/installcheck/Amanda_DB_Catalog.pl
@@ -208,10 +208,12 @@ Amanda::DB::Catalog::_clear_cache();
 # Test the timestamps
 
 is_deeply([ Amanda::DB::Catalog::get_write_timestamps(), ],
-[ '2008011100', '200802', '2008031313', '2008041414', '2008051515', '2008061616' ],
+[ '2008011100', '200802', '2008031313',
+  '2008041414', '2008051515', '2008061616',
+  '2010072200' ],
 get_write_timestamps returns all logfile datestamps in proper order, with zero-padding);
 
-is(Amanda::DB::Catalog::get_latest_write_timestamp(), '2008061616',
+is(Amanda::DB::Catalog::get_latest_write_timestamp(), '2010072200',
 get_latest_write_timestamp correctly returns the latest write timestamp);
 
 ##
@@ -1038,3 +1040,17 @@ START taper datestamp 2008061616 label Conf-008 tape 1
 #:part somebox_lib_2008061616 somebox_lib_2008061616 Conf-008 1 1 OK 0.000370 20 20
 PART taper Conf-008 1 somebox /lib 2008061616 2/2 1 [sec 0.000370 kb 20 kps 54054.054054 orig-kb 20]
 DONE taper somebox /lib 2008061616 1 1 [sec 0.000370 kb 20 kps 54054.054054 orig-kb 20]
+
+# an old-school logfile
+::: log.20100722.0
+:timestamp 2010072200
+:tapelist 20100722 Conf-009
+DISK planner lovelace /home/ada
+START taper datestamp 20100722 label Conf-009 tape 0
+SUCCESS dumper lovelace /home/ada 20100722 3 [sec 19.271 kb 166951 kps 8663.1 orig-kb 208420]
+SUCCESS chunker lovelace /home/ada 20100722 3 [sec 19.298 kb 166951 kps 8652.7]
+STATS driver estimate lovelace /home/ada 20100722 3 [sec 30 nkb 208422 ckb 32640 kps 1081]
+:dump lovelace_home_ada_20100722 2010072200 lovelace /home/ada 3 OK  1 0.883 166976 0
+:part lovelace_home_ada_20100722 lovelace_home_ada_20100722 Conf-009 1 1 OK 0.883 166976 0
+SUCCESS taper lovelace /home/ada 20100722 3 [sec 0.883 kb 166976 kps 188922.8 {wr: writers 5219 rdwait 0.001 wrwait 0.710 filemark 0.000}]
+INFO taper tape Conf-009 kb 166976 fm 1 [OK]
diff --git a/perl/Amanda/DB/Catalog.pm b/perl/Amanda/DB/Catalog.pm
index c73855e..2879240 100644
--- a/perl/Amanda/DB/Catalog.pm
+++ b/perl/Amanda/DB/Catalog.pm
@@ -656,6 +656,8 @@ sub get_parts_and_dumps

Re: Connection refused, timed out, successfully retried (v3.1.3)

[Luc Lalonde]

Hello Jean-Louis,

Two days of backups and no more deconnection errors...  Will this patch be 
included in the next version (v3.1.4)?

Thanks again!

On 2010-11-19, at 8:22 AM, Jean-Louis Martineau wrote:

 Bonjour Luc,
 
 It's a known bug in 3.1.3
 The attached patch fix it.
 
 Jean-Louis
 
 Luc Lalonde wrote:
 Hello Folks,
 
 Since I've upgraded from Amanda-2.5.2p1 to Amanda-3.1.x, I've been getting 
 connection errors almost every day...
 
 Here's a snipet of the type of errors I'm getting:
 
 ### Begin ###
 These dumps were to tape vtape-14.
 The next tape Amanda expects to use is: vtape-15.
 FAILURE DUMP SUMMARY:
  chunker: FATAL startup_chunker failed: error accepting header stream: 
 Connection timed out
  server1 /etc lev 1  FAILED [Can't open data output stream: Connection 
 refused]
  server1 /etc lev 1  FAILED [error accepting data stream: Connection timed 
 out]
  server1 /etc lev 1  was successfully retried
  server2 /root lev 1  FAILED [port open: Connection refused]
  server2 /root lev 1  was successfully retried
 ### End  ###
 
 Here are my config files:
 
 ### Begin amanda.conf ##
 inparallel 10
 netusage  100 mbps
 maxdumps 2
 
 dumpcycle 2 weeks
 runspercycle 14 tapecycle 16 tapes
 
 bumpsize 20 Mb
 bumpdays 1
 bumpmult 4
 
 etimeout -21600
 dtimeout 10800
 
 autoflush yes
 
 runtapes 1
 tpchanger chg-disk:/amanda/VTAPE/slots
 
 tapetype HARDDISK
 define tapetype HARDDISK {
 length 204800 mbytes
 }
 
 holdingdisk hd1 {
comment main holding disk
directory /amanda/stage/Journalier-VTAPE
use 1000 Gb
chunksize 1Gb
}
 
 columnspec 
 Hostname=0:8,Disk=1:14,OrigKB=1:10,OutKB=1:10,DumpRate=1:7,TapeRate=1:7
 
 infofile /amanda/home/Journalier-VTAPE/curinfo
 logdir   /amanda/home/Journalier-VTAPE
 indexdir /amanda/home/Journalier-VTAPE/index
 
 # dumptypes
 
 define dumptype global {
comment Global definitions
index yes
record yes
auth bsdtcp
 }
 
 define dumptype full-tar {
global
program GNUTAR
comment Full tar of this filesystem always
compress client fast
priority high
dumpcycle 0
 }
 
 define dumptype exclude-tar {
global
program GNUTAR
comment root partitions dumped with tar
compress client fast
exclude list /etc/amanda/exclude.gtar
priority low
 }
 
 define dumptype enseign-tar {
global
program GNUTAR
comment root partitions dumped with tar
compress client fast
priority low
 }
 
 define dumptype server-estimate {
global
program GNUTAR
comment root partitions dumped with tar
compress client fast
estimate server
priority low
 }
 
 define dumptype root-tar {
global
program GNUTAR
comment root partitions dumped with tar
compress client fast
priority low
 }
 
 
 # network interfaces
 
 define interface local {
comment a local disk
use 20 mbps
 }
 
 define interface eth2 {
comment 1000 Mbps ethernet
use 1000 mbps
 }
 ### End amanda.conf  ##
 
  Begin /etc/xinetd.d/amandaserver #
 service amanda
 {
disable = no
socket_type = stream
protocol= tcp
wait= no
user= amandabackup
group   = disk
groups  = yes
server  = /usr/libexec/amanda/amandad
server_args = -auth=bsdtcp amdump amindexd amidxtaped
 }
  End /etc/xinetd.d/amandaserver   #
 
  Begin /etc/xinetd.d/amandaclient #
 service amanda
 {
disable = no
socket_type = stream
protocol= tcp
wait= no
user= amandabackup
group   = disk
groups  = yes
server  = /usr/libexec/amanda/amandad
server_args = -auth=bsdtcp amdump
 }
  End /etc/xinetd.d/amandaclient  #
 
 And finally, here's a snippet of a pertinent dumper debug:
 
 ## begin dump debug #
 Wed Nov 17 23:34:44 2010: dumper: security_streaminit(stream=0x1b64d110, 
 driver=0x3414c66520 (BSDTCP))
 Wed Nov 17 23:34:44 2010: dumper: security_streaminit(stream=0x1b655170, 
 driver=0x3414c66520 (BSDTCP))
 Wed Nov 17 23:34:44 2010: dumper: security_streaminit(stream=0x1b65d1d0, 
 driver=0x3414c66520 (BSDTCP))
 Wed Nov 17 23:34:44 2010: dumper: security_close(handle=0x1b643760, 
 driver=0x3414c66520 (BSDTCP))
 Wed Nov 17 23:34:44 2010: dumper: security_stream_close(0x1b644760)
 Wed Nov 17 23:34:44 2010: dumper: Building type FILE header of 32768-32768 
 bytes with name='server1' disk='/etc' dumplevel=1 and blocksize=32768
 Wed Nov 17 23:34:44 2010: dumper: Sending data to 127.0.0.1:11039
 Wed Nov 17 23:34:44 2010: dumper: make_socket opening socket with family 2
 Wed Nov 17 23:34:44 2010: dumper: connect_port: Try  port 11004

Re: Connection refused, timed out, successfully retried (v3.1.3)

[Luc Lalonde]

I've patched and installed the new version on my server-clients...  

I'll send an update to the list tomorow once tonight's backup run finishes to 
confirm that this fixes the problem.

Merci!   

- Original Message -
From: Jean-Louis Martineau martin...@zmanda.com
To: Luc Lalonde luc.lalo...@polymtl.ca
Cc: amanda-users@amanda.org, Technique GIGL gigl-techni...@polymtl.ca
Sent: Friday, November 19, 2010 8:22:07 AM GMT -05:00 US/Canada Eastern
Subject: Re: Connection refused, timed out, successfully retried (v3.1.3)

Bonjour Luc,

It's a known bug in 3.1.3
The attached patch fix it.

Jean-Louis

Luc Lalonde wrote:
 Hello Folks,

 Since I've upgraded from Amanda-2.5.2p1 to Amanda-3.1.x, I've been getting 
 connection errors almost every day...

 Here's a snipet of the type of errors I'm getting:

 ### Begin ###
 These dumps were to tape vtape-14.
 The next tape Amanda expects to use is: vtape-15.
 FAILURE DUMP SUMMARY:
   chunker: FATAL startup_chunker failed: error accepting header stream: 
 Connection timed out
   server1 /etc lev 1  FAILED [Can't open data output stream: Connection 
 refused]
   server1 /etc lev 1  FAILED [error accepting data stream: Connection timed 
 out]
   server1 /etc lev 1  was successfully retried
   server2 /root lev 1  FAILED [port open: Connection refused]
   server2 /root lev 1  was successfully retried
 ### End  ###

 Here are my config files:

 ### Begin amanda.conf ##
 inparallel 10
 netusage  100 mbps
 maxdumps 2

 dumpcycle 2 weeks
 runspercycle 14 
 tapecycle 16 tapes

 bumpsize 20 Mb
 bumpdays 1
 bumpmult 4

 etimeout -21600
 dtimeout 10800

 autoflush yes

 runtapes 1
 tpchanger chg-disk:/amanda/VTAPE/slots

 tapetype HARDDISK
 define tapetype HARDDISK {
 length 204800 mbytes
 }

 holdingdisk hd1 {
 comment main holding disk
 directory /amanda/stage/Journalier-VTAPE
 use 1000 Gb
 chunksize 1Gb
 }

 columnspec 
 Hostname=0:8,Disk=1:14,OrigKB=1:10,OutKB=1:10,DumpRate=1:7,TapeRate=1:7

 infofile /amanda/home/Journalier-VTAPE/curinfo
 logdir   /amanda/home/Journalier-VTAPE
 indexdir /amanda/home/Journalier-VTAPE/index

 # dumptypes

 define dumptype global {
 comment Global definitions
 index yes
 record yes
 auth bsdtcp
 }

 define dumptype full-tar {
 global
 program GNUTAR
 comment Full tar of this filesystem always
 compress client fast
 priority high
 dumpcycle 0
 }

 define dumptype exclude-tar {
 global
 program GNUTAR
 comment root partitions dumped with tar
 compress client fast
 exclude list /etc/amanda/exclude.gtar
 priority low
 }

 define dumptype enseign-tar {
 global
 program GNUTAR
 comment root partitions dumped with tar
 compress client fast
 priority low
 }

 define dumptype server-estimate {
 global
 program GNUTAR
 comment root partitions dumped with tar
 compress client fast
 estimate server
 priority low
 }

 define dumptype root-tar {
 global
 program GNUTAR
 comment root partitions dumped with tar
 compress client fast
 priority low
 }


 # network interfaces

 define interface local {
 comment a local disk
 use 20 mbps
 }

 define interface eth2 {
 comment 1000 Mbps ethernet
 use 1000 mbps
 }
 ### End amanda.conf  ##

  Begin /etc/xinetd.d/amandaserver #
 service amanda
 {
 disable = no
 socket_type = stream
 protocol= tcp
 wait= no
 user= amandabackup
 group   = disk
 groups  = yes
 server  = /usr/libexec/amanda/amandad
 server_args = -auth=bsdtcp amdump amindexd amidxtaped
 }
  End /etc/xinetd.d/amandaserver   #

  Begin /etc/xinetd.d/amandaclient #
 service amanda
 {
 disable = no
 socket_type = stream
 protocol= tcp
 wait= no
 user= amandabackup
 group   = disk
 groups  = yes
 server  = /usr/libexec/amanda/amandad
 server_args = -auth=bsdtcp amdump
 }
  End /etc/xinetd.d/amandaclient  #

 And finally, here's a snippet of a pertinent dumper debug:

 ## begin dump debug #
 Wed Nov 17 23:34:44 2010: dumper: security_streaminit(stream=0x1b64d110, 
 driver=0x3414c66520 (BSDTCP))
 Wed Nov 17 23:34:44 2010: dumper: security_streaminit(stream=0x1b655170, 
 driver=0x3414c66520 (BSDTCP))
 Wed Nov 17 23:34:44 2010: dumper: security_streaminit(stream=0x1b65d1d0, 
 driver=0x3414c66520 (BSDTCP))
 Wed Nov 17 23:34:44 2010: dumper: security_close(handle=0x1b643760, 
 driver=0x3414c66520 (BSDTCP))
 Wed Nov 17 23:34:44 2010: dumper: security_stream_close(0x1b644760)
 Wed

Connection refused, timed out, successfully retried (v3.1.3)

[Luc Lalonde]

 0.0.0.0.11002 
failed: Connection refused
Wed Nov 17 23:34:44 2010: dumper: connect_portrange: connect to 127.0.0.1.11039 
failed: Connection refused
Wed Nov 17 23:34:44 2010: dumper: stream_client: Could not bind to port in 
range 11000-11040.
Wed Nov 17 23:34:44 2010: dumper: security_stream_close(0x1b64d110)
Wed Nov 17 23:34:44 2010: dumper: security_stream_close(0x1b655170)
Wed Nov 17 23:34:44 2010: dumper: security_stream_close(0x1b65d1d0)
Wed Nov 17 23:34:44 2010: dumper: putresult: 10 FAILED
Wed Nov 17 23:39:45 2010: dumper: getcmd: PORT-DUMP 02-00036 11023 server1 
9efefbff01 /etc NODEVICE 1 2010:11:17:4:0:3 GNUTAR 
bsdtcp AMANDA 12
7.0.0.1:11024 |  authbsdtcp/auth\n  compressFAST/compress\n  
recordYES/record\n  indexYES/index\n  datapathAMANDA/datapath\n  
exclude\nlis
t/etc/amanda/exclude.gtar/list\n  /exclude\n
Wed Nov 17 23:39:45 2010: dumper: Sending header to localhost:11023

Wed Nov 17 23:39:45 2010: dumper: make_socket opening socket with family 2
Wed Nov 17 23:39:45 2010: dumper: connect_port: Try  port 11004: available - 
Success
Wed Nov 17 23:39:45 2010: dumper: connected to 127.0.0.1.11023
Wed Nov 17 23:39:45 2010: dumper: our side is 0.0.0.0.11004
Wed Nov 17 23:39:45 2010: dumper: try_socksize: send buffer size is 65536
Wed Nov 17 23:39:45 2010: dumper: send request:
## end dump debug   #

Anyone have ideas on how to resolve this problem?  

Thanks!
-- 
Luc Lalonde, analyste
-
Département de génie informatique:
École polytechnique de Montréal
(514) 340-4711 x5049
luc.lalo...@polymtl.ca
-

Re: amidxtaped v3.1.1 bug (critical (fatal): Modification of non-creatable array value attempted)

[Luc Lalonde]

Fantastic!  That did the trick.

Will you be including this in 3.1.2?  For the moment, I patched the RPMSRC from 
the Zmanda binary repo and it works great with your modifications.

Thank you very much!

- Original Message -
From: Dustin J. Mitchell dus...@zmanda.com
To: Luc Lalonde luc.lalo...@polymtl.ca
Cc: amanda-users@amanda.org
Sent: Monday, August 9, 2010 5:53:55 PM GMT -05:00 US/Canada Eastern
Subject: Re: amidxtaped v3.1.1 bug (critical (fatal): Modification of  
non-creatable array value attempted)

Ok, I took a look at the logfiles, and they're *very* old-school.  It
looks like there's been a longstanding bug in find.c that mis-parsed
some of these log entries, and now that we're up and running with
Amanda::DB::Catalog, that mis-parsing causes failures.

I managed to reproduce this by excerpting and anonymizing a tiny bit
of a logfile.  This patch
  http://github.com/djmitche/amanda/commit/z11690.patch
passes my tests.  Can you let me know if it works for you?

Dustin

-- 
Open Source Storage Engineer
http://www.zmanda.com

-- 
Luc Lalonde, analyste
-
Département de génie informatique:
École polytechnique de Montréal
(514) 340-4711 x5049
luc.lalo...@polymtl.ca
-

Re: amidxtaped v3.1.1 bug (critical (fatal): Modification of non-creatable array value attempted)

[Luc Lalonde]

Hello Dustin,

Apart from what I've already sent, I can't seem find anything else...

All I can say is that I don't get this problem using 2.6.1p2 only 3.1.1 on the 
server side.

Thanks.
- Original Message -
From: Dustin J. Mitchell dus...@zmanda.com
To: Luc Lalonde luc.lalo...@polymtl.ca
Cc: amanda-users@amanda.org
Sent: Saturday, August 7, 2010 8:03:38 PM GMT -05:00 US/Canada Eastern
Subject: Re: amidxtaped v3.1.1 bug (critical (fatal): Modification of  
non-creatable array value attempted)

On Fri, Aug 6, 2010 at 1:34 PM, Luc Lalonde luc.lalo...@polymtl.ca wrote:
 amidxtaped: Modification of non-creatable array value attempted, subscript -1 
 at /usr/lib/perl5/site_perl/5.8.8/Amanda/DB/Catalog.pm line 636.

Here is the suspect line in Amanda/DB/Catalog.pm:

 636 $dump-{'parts'}[$part{'partnum'}] = \%part;

so the problem is that $part{'partnum'} is -1.  Looking at the code
above, that can only be from $find_result containing a partnum of -1.
The only way I can see for that to happen is if you have a PART or
PARTPARTIAL trace log line with -1/ in it.  This could be in any
logfile with a datestamp of 20100803 or earlier.  (There's also
search_holding_disk, but Amanda::DB::Catalog does not call that
function, even indirectly)

Can you take a look in the logfiles and see if you find anything funny-looking?

Dustin

-- 
Open Source Storage Engineer
http://www.zmanda.com

-- 
Luc Lalonde, analyste
-
Département de génie informatique:
École polytechnique de Montréal
(514) 340-4711 x5049
luc.lalo...@polymtl.ca
-

amidxtaped v3.1.1 bug (critical (fatal): Modification of non-creatable array value attempted)

[Luc Lalonde]

Hello Folks,

I'm moving my stuff to the new version of Amanda (v3.1.1)... from 2.5.2p1.

I'm trying testing amrecover-v3.1.1 with a VTAPE configuration and I get this 
error:

##
Fri Aug  6 14:20:18 2010: amidxtaped: pid 16100 ruid 515 euid 515 version 
3.1.1: start at Fri Aug  6 14:20:18 2010
Fri Aug  6 14:20:18 2010: amidxtaped: CTL  FEATURES=9efefbff01
Fri Aug  6 14:20:18 2010: amidxtaped: CTL  CONFIG=Journalier-VTAPE
Fri Aug  6 14:20:18 2010: amidxtaped: CTL  LABEL=vtape-8:33
Fri Aug  6 14:20:18 2010: amidxtaped: CTL  FSF=33
Fri Aug  6 14:20:18 2010: amidxtaped: CTL  HEADER
Fri Aug  6 14:20:18 2010: amidxtaped: CTL  DEVICE=chg-disk:/amanda/VTAPE/slots
Fri Aug  6 14:20:18 2010: amidxtaped: CTL  HOST=^moe-180$
Fri Aug  6 14:20:18 2010: amidxtaped: CTL  DISK=^/store/homes/jl$
Fri Aug  6 14:20:18 2010: amidxtaped: CTL  DATESTAMP=20100803
Fri Aug  6 14:20:18 2010: amidxtaped: CTL  END
Fri Aug  6 14:20:18 2010: amidxtaped: pid 16100 ruid 515 euid 515 version 
3.1.1: rename at Fri Aug  6 14:20:18 2010
Fri Aug  6 14:20:18 2010: amidxtaped: critical (fatal): Modification of 
non-creatable array value attempted, subscript -1 at 
/usr/lib/perl5/site_perl/5.8.8/Amanda/DB/Catalog.pm line 636.

amidxtaped: Modification of non-creatable array value attempted, subscript -1 
at /usr/lib/perl5/site_perl/5.8.8/Amanda/DB/Catalog.pm line 636.

/usr/lib64/amanda/libamanda-3.1.1.so[0x331c8268c6]
/lib64/libglib-2.0.so.0(g_logv+0x26f)[0x3ed1434d5f]
/lib64/libglib-2.0.so.0(g_log+0x83)[0x3ed1434f33]
/usr/lib/perl5/site_perl/5.8.8/auto/Amanda/MainLoop/libMainLoop.so[0x2baa25e6c9db]
/lib64/libglib-2.0.so.0[0x3ed142d2bb]
/lib64/libglib-2.0.so.0(g_main_context_dispatch+0x1b4)[0x3ed142cdb4]
/lib64/libglib-2.0.so.0[0x3ed142fc0d]
/lib64/libglib-2.0.so.0(g_main_loop_run+0x1ca)[0x3ed142ff1a]
/usr/lib/perl5/site_perl/5.8.8/auto/Amanda/MainLoop/libMainLoop.so(_wrap_run_c+0x77)[0x2baa25e6be27]
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so(Perl_pp_entersub+0x3f6)[0x3ecd490a96]
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so(Perl_runops_standard+0xe)[0x3ecd48a33e]
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so(perl_run+0x30a)[0x3ecd43808a]
/usr/bin/perl(main+0xfc)[0x4017bc]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x3ecc41d994]
/usr/bin/perl[0x401609]
##

On the client, I get this output

##
Load tape vtape-8 now
Continue [?/Y/n/s/d]? Y
Got no header and data from server, check in amidxtaped.*.debug and 
amandad.*.debug files on server
Extracting files using tape drive chg-disk:/amanda/VTAPE/slots on host 
localhost.
##

Any ideas?

-- 
Luc Lalonde, analyste
-
Département de génie informatique:
École polytechnique de Montréal
(514) 340-4711 x5049
luc.lalo...@polymtl.ca
-

LTO4 library recomendations

[Luc Lalonde]

Hello Folks,

I'm considering buying one of these models:

- HP MSL4048 (2 FC LTO4 drives, redundant power supply, 48 slots)
- Spectra T50e (2 FC LTO4 drives, redundant power supply, 50 slots)
- Dell PowerVault TL4000/IBM TS3200 (2 FC LTO4 drives, redundant power supply, 
48 slots)
- Sun-Oracle StorageTek SL500 (2 FC LTO4 drives, redundant power supply, 50 
slots)

I'd be interested in reading some of your comments regarding these units...   
Which one would you recommend above all others?  Do they behave well with 
Amanda, mtx, etc.

Thanks!
-- 
Luc Lalonde, analyste
-
Département de génie informatique:
École polytechnique de Montréal
(514) 340-4711 x5049
luc.lalo...@polymtl.ca
-

Re: selfcheck request failed: timeout waiting for ACK (with secondary addr on eth0 only)

[Luc Lalonde]

Thanks, that did the trick (added bind address)...

­Force the listen address in the relevant xinetd.d file. This will do the
 trick.

--
Luc Lalonde, analyste
-
Département de génie informatique:
Éole polytechnique de Montréal
(514) 340-4711 x5049
[EMAIL PROTECTED]
-
If God intended people to be naked, they would be born that way.
-- Oscar Wilde
- 

selfcheck request failed: timeout waiting for ACK (with secondary addr on eth0 only)

[Luc Lalonde]

Hello folks,

I'm finally upgrading from the Amanda v2.4.x series to v2.5.2p1.   My 
configuration worked fine with the old v2.4.x series...  However, I'm 
having some strangeness with the new version... in particular with 
clients that have a primary and secondary ipaddr on the same interface 
(eth0).   Here's an example:


2: eth0: BROADCAST,MULTICAST,UP,1 mtu 1500 qdisc pfifo_fast qlen 100
   link/ether 00:04:23:e0:65:46 brd ff:ff:ff:ff:ff:ff
   inet 192.168.1.23/26 brd 192.168.1.63 scope global eth0
   inet 192.168.1.25/26 brd 192.168.1.63 scope global secondary eth0
   inet6 fe80::204:23ff:fee0:6546/64 scope link
  valid_lft forever preferred_lft forever

When I do an amcheck on the primary addr (192.168.1.23) , all is 
fine... However, if I do it with the secondary addr (192.168.1.25), I 
get this message:


WARNING: secon-ip: selfcheck request failed: timeout waiting for ACK

Where, secon-ip is 192.168.1.25.   I did a tcpdump -A -v -v udp port 
10080 and it confirms that the Amanda server is sending a request from 
the secondary address, but getting an answer from the primary address... 
and it doesn't seem to like it:


 clip ###
22:58:30.256184 IP (tos 0x0, ttl  62, id 0, offset 0, flags [DF], proto 
17, length: 153) amanda-server.909  secon-ip.amanda: UDP, length 125
[EMAIL PROTECTED].r...'`..?.Amanda 2.5 REQ HANDLE 000- SEQ 
1204141709

 end clip  ###
 clip further down ###
23:02:51.877040 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto 
17, length: 119) prim-ip.amanda  amanda-server.577: UDP, length 91
[EMAIL PROTECTED]@.p.'`.A.c..Amanda 2.5 REP HANDLE 000- SEQ 
1204602504

 end clip  ###

I'd really like to get this to work... I use the secondary address in a 
dual-node cluster with Heartbeat-DRBD configuration.  The secondary 
address is used for failover.


Thanks in advance for your help.

Luc Lalonde.

Re: Amanda migration from SGI-Irix to Linux

[Luc Lalonde]

Hello Jean-François,

I changed the SCSI card.   Upon investigation I found that the Qlogic 
card (QLA1240D) driver in Linux too flaky for my taste.   Instead I got 
a couple of used DualPort-Adaptec HVD cards that work just great 
(AHA-3944AUWD) from eBay ;-)


I also had to change de default blocksize (mentionned by J. Labadie, thx 
Jon ;-) with 'mt':


mt -f /dev/nst0 setblk 32768

Bye.
PS:  Hope you server room move went well ;-)

Luc Lalonde wrote:

Hello Jean-François,

I seem to be having problems with the SCSI controller:

st0: Error 8 (sugg. bt 0x0, driver bt 0x0, host bt 0x8).
scsi(0): Resetting Cmnd=0x01008229b6c0, Handle=0x0202, 
action=0x2

scsi(0:0:6:0): Queueing device reset command.

Are your LTO drives HVD or LVD... and what controller are you using?   
I'm using the same model (QLA1240) that was on the SGI... with no luck 
it seems.


Bye.


Luc Lalonde wrote:

Hello Jean-François,

I think I found the problem.   I have another old binary 'mt' in the 
PATH that is causing the problem.   After removing I get the same 
output as you do:


[EMAIL PROTECTED] ~]# mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 512 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (4101):
BOT ONLINE IM_REP_EN
[EMAIL PROTECTED] bin]# /bin/mt -f /dev/nst1 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 512 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (4101):
BOT ONLINE IM_REP_EN

When I do an amcheck I get this error (changerdev /dev/sg0):

scsi(0): Resetting Cmnd=0x01000b06b880, 
Handle=0x0202, action=0x2

scsi(0:0:6:0): Queueing device reset command.

So the changer seems to be struggling...

I'm  continuing my investigations...
Thanks again for your input...

Luc Lalonde wrote:

Hello Jean-François,

I'm getting this weird message with 'mt':

[EMAIL PROTECTED] ~]# mt -f /dev/nst0 status
Unknown tape drive type (0x72):
  residual= 0   ds = 200   er = 0
  file no= 0   block no= 0

What I don't understand is that it seems to be correctly recognized 
by the system:


[EMAIL PROTECTED] ~]# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 06 Lun: 00
 Vendor: STK  Model: L40  Rev: 0215
 Type:   Medium Changer   ANSI SCSI revision: 03
Host: scsi0 Channel: 00 Id: 15 Lun: 00
 Vendor: SEAGATE  Model: ULTRIUM06242-XXX Rev: 1619
 Type:   Sequential-AccessANSI SCSI revision: 03
Host: scsi0 Channel: 01 Id: 15 Lun: 00
 Vendor: SEAGATE  Model: ULTRIUM06242-XXX Rev: 1619
 Type:   Sequential-AccessANSI SCSI revision: 03

Any ideas?   By the way, the jukebox is connected to the server via 
a Qlogic QLA1240.   What are you using on your Linux box?


Thanks again.
PS:  'mtx -f /dev/sg0 status' seems to work fine.  I get a full 
report of the contents of my library.


Jean-Francois Malouin wrote:

* Luc Lalonde [EMAIL PROTECTED] [20060811 11:52]:
 

Hello Folks,

I'm getting this error when I try to use the tapes (LTO1) on a 
StorageTek L40 Jukebox:


st1: Block limits 1 - 16777215 bytes.
st1: Incorrect block size.
st1: Incorrect block size.
scsi(0): Resetting Cmnd=0x01004a871b00, 
Handle=0x0202, action=0x2

scsi(0:1:15:0): Queueing device reset command.
st1: Error with sense data: Current st1: sense key Not Ready
Additional sense: Logical unit not ready, cause not reportable

I'm in the process of migrating Amanda from a SGI (Origin 300) 
server to a Linux server.   I'm hoping that I don't have to 
re-label all my tapes and lose the backups created with the old 
SGI Amanda server.



I'm in the middle of relocating our entire computer room so I'll be
brief :) I have a bunch of LTO1s in a L80 hooked to a O3k so that's
essentially what you have. I'll be moving this to a Debian system soon
and in my testings I could drive the library and tape drives with mtx
and mt no problem except for the hardware compression bit on the
drive: after much mucking around with stinit I couldn't disable it but
seems the for LTO that's not a problem. Still looking for a way to
disable it though.

To your problem: what does 'mt status' says?

Here's what I got on a Debian system running 2.6.x

~# mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 512 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (4101):
 BOT ONLINE IM_REP_EN

~# ./amtapetype -o -f /dev/nst0 -e 100g
Writing 1024 Mbyte   compresseable data:  35 sec
Writing 1024 Mbyte uncompresseable data:  69 sec
WARNING: Tape drive has hardware compression enabled
Estimated time to write 2 * 102400 Mbyte: 13800 sec = 3 h 50 min
wrote 3178496 32Kb blocks in 97 files in 6880 seconds (short write)
wrote 3194880 32Kb blocks in 195 files in 6886 seconds (short write)
define

Re: Amanda migration from SGI-Irix to Linux

[Luc Lalonde]

Hello Jean-François,

I seem to be having problems with the SCSI controller:

st0: Error 8 (sugg. bt 0x0, driver bt 0x0, host bt 0x8).
scsi(0): Resetting Cmnd=0x01008229b6c0, Handle=0x0202, 
action=0x2

scsi(0:0:6:0): Queueing device reset command.

Are your LTO drives HVD or LVD... and what controller are you using?   
I'm using the same model (QLA1240) that was on the SGI... with no luck 
it seems.


Bye.


Luc Lalonde wrote:

Hello Jean-François,

I think I found the problem.   I have another old binary 'mt' in the 
PATH that is causing the problem.   After removing I get the same 
output as you do:


[EMAIL PROTECTED] ~]# mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 512 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (4101):
BOT ONLINE IM_REP_EN
[EMAIL PROTECTED] bin]# /bin/mt -f /dev/nst1 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 512 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (4101):
BOT ONLINE IM_REP_EN

When I do an amcheck I get this error (changerdev /dev/sg0):

scsi(0): Resetting Cmnd=0x01000b06b880, Handle=0x0202, 
action=0x2

scsi(0:0:6:0): Queueing device reset command.

So the changer seems to be struggling...

I'm  continuing my investigations...
Thanks again for your input...

Luc Lalonde wrote:

Hello Jean-François,

I'm getting this weird message with 'mt':

[EMAIL PROTECTED] ~]# mt -f /dev/nst0 status
Unknown tape drive type (0x72):
  residual= 0   ds = 200   er = 0
  file no= 0   block no= 0

What I don't understand is that it seems to be correctly recognized 
by the system:


[EMAIL PROTECTED] ~]# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 06 Lun: 00
 Vendor: STK  Model: L40  Rev: 0215
 Type:   Medium Changer   ANSI SCSI revision: 03
Host: scsi0 Channel: 00 Id: 15 Lun: 00
 Vendor: SEAGATE  Model: ULTRIUM06242-XXX Rev: 1619
 Type:   Sequential-AccessANSI SCSI revision: 03
Host: scsi0 Channel: 01 Id: 15 Lun: 00
 Vendor: SEAGATE  Model: ULTRIUM06242-XXX Rev: 1619
 Type:   Sequential-AccessANSI SCSI revision: 03

Any ideas?   By the way, the jukebox is connected to the server via a 
Qlogic QLA1240.   What are you using on your Linux box?


Thanks again.
PS:  'mtx -f /dev/sg0 status' seems to work fine.  I get a full 
report of the contents of my library.


Jean-Francois Malouin wrote:

* Luc Lalonde [EMAIL PROTECTED] [20060811 11:52]:
 

Hello Folks,

I'm getting this error when I try to use the tapes (LTO1) on a 
StorageTek L40 Jukebox:


st1: Block limits 1 - 16777215 bytes.
st1: Incorrect block size.
st1: Incorrect block size.
scsi(0): Resetting Cmnd=0x01004a871b00, 
Handle=0x0202, action=0x2

scsi(0:1:15:0): Queueing device reset command.
st1: Error with sense data: Current st1: sense key Not Ready
Additional sense: Logical unit not ready, cause not reportable

I'm in the process of migrating Amanda from a SGI (Origin 300) 
server to a Linux server.   I'm hoping that I don't have to 
re-label all my tapes and lose the backups created with the old SGI 
Amanda server.



I'm in the middle of relocating our entire computer room so I'll be
brief :) I have a bunch of LTO1s in a L80 hooked to a O3k so that's
essentially what you have. I'll be moving this to a Debian system soon
and in my testings I could drive the library and tape drives with mtx
and mt no problem except for the hardware compression bit on the
drive: after much mucking around with stinit I couldn't disable it but
seems the for LTO that's not a problem. Still looking for a way to
disable it though.

To your problem: what does 'mt status' says?

Here's what I got on a Debian system running 2.6.x

~# mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 512 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (4101):
 BOT ONLINE IM_REP_EN

~# ./amtapetype -o -f /dev/nst0 -e 100g
Writing 1024 Mbyte   compresseable data:  35 sec
Writing 1024 Mbyte uncompresseable data:  69 sec
WARNING: Tape drive has hardware compression enabled
Estimated time to write 2 * 102400 Mbyte: 13800 sec = 3 h 50 min
wrote 3178496 32Kb blocks in 97 files in 6880 seconds (short write)
wrote 3194880 32Kb blocks in 195 files in 6886 seconds (short write)
define tapetype unknown-tapetype {
comment just produced by tapetype prog (hardware compression on)
length 99584 mbytes
filemark 0 kbytes
speed 14815 kps
}

HTH
jf

 

Thanks!






--
Luc Lalonde, analyste
-
Département de génie informatique:
Éole polytechnique de Montréal
(514) 340-4711 x5049
[EMAIL PROTECTED

Re: Amanda migration from SGI-Irix to Linux

[Luc Lalonde]

CentOs 4.3 with kernel 2.6.9-34.0.2.ELsmp (x86_64):

[EMAIL PROTECTED] ~]# uname -a
Linux abel 2.6.9-34.0.2.ELsmp #1 SMP Fri Jul 7 18:22:55 CDT 2006 x86_64
x86_64 x86_64 GNU/Linux

Here's what I get when you I cat the device entry in proc:

[EMAIL PROTECTED] ~]# cat /proc/scsi/qla1280/0
QLogic PCI to SCSI Adapter for ISP 1280/12160:
 Firmware version: 8.15.00, Driver version 3.24.4
SCSI Host Adapter Information: QLA1240
Request Queue count= 0x100, Response Queue count= 0x10
Number of pending commands = 0x0
Number of free request entries = 237

Strange thing though, I get garbage every second time I try to view the
contents of this file


Jean-Francois Malouin wrote:

  * Luc Lalonde [EMAIL PROTECTED] [20060814 12:08]:
  
  
Hello Jean-Franois,

I seem to be having problems with the SCSI controller:

st0: Error 8 (sugg. bt 0x0, driver bt 0x0, host bt 0x8).
scsi(0): Resetting Cmnd=0x01008229b6c0, Handle=0x0202, 
action=""
scsi(0:0:6:0): Queueing device reset command.

Are your LTO drives HVD or LVD... and what controller are you using?   
I'm using the same model (QLA1240) that was on the SGI... with no luck 
it seems.

  
  
My LTO1s are all HVD. Controllers are the same as you have.
I suspect you're being bitten by your driver and/or kernel combo...
On what box are you doing this?


  
  
    Bye.


Luc Lalonde wrote:


  Hello Jean-Franois,

I think I found the problem.   I have another old binary 'mt' in the 
PATH that is causing the problem.   After removing I get the same 
output as you do:

[EMAIL PROTECTED] ~]# mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 512 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (4101):
BOT ONLINE IM_REP_EN
[EMAIL PROTECTED] bin]# /bin/mt -f /dev/nst1 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 512 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (4101):
BOT ONLINE IM_REP_EN

When I do an amcheck I get this error (changerdev "/dev/sg0"):

scsi(0): Resetting Cmnd=0x01000b06b880, Handle=0x0202, 
action=""
scsi(0:0:6:0): Queueing device reset command.

So the changer seems to be struggling...

I'm  continuing my investigations...
Thanks again for your input...

Luc Lalonde wrote:
  
  
Hello Jean-Franois,

I'm getting this weird message with 'mt':

[EMAIL PROTECTED] ~]# mt -f /dev/nst0 status
Unknown tape drive type (0x72):
 residual= 0   ds = 200   er = 0
 file no= 0   block no= 0

What I don't understand is that it seems to be correctly recognized 
by the system:

[EMAIL PROTECTED] ~]# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 06 Lun: 00
Vendor: STK  Model: L40  Rev: 0215
Type:   Medium Changer   ANSI SCSI revision: 03
Host: scsi0 Channel: 00 Id: 15 Lun: 00
Vendor: SEAGATE  Model: ULTRIUM06242-XXX Rev: 1619
Type:   Sequential-AccessANSI SCSI revision: 03
Host: scsi0 Channel: 01 Id: 15 Lun: 00
Vendor: SEAGATE  Model: ULTRIUM06242-XXX Rev: 1619
Type:   Sequential-AccessANSI SCSI revision: 03

Any ideas?   By the way, the jukebox is connected to the server via a 
Qlogic QLA1240.   What are you using on your Linux box?

Thanks again.
PS:  'mtx -f /dev/sg0 status' seems to work fine.  I get a full 
report of the contents of my library.

Jean-Francois Malouin wrote:
    
    
  * Luc Lalonde [EMAIL PROTECTED] [20060811 11:52]:

  
  
Hello Folks,

I'm getting this error when I try to use the tapes (LTO1) on a 
StorageTek L40 Jukebox:

st1: Block limits 1 - 16777215 bytes.
st1: Incorrect block size.
st1: Incorrect block size.
scsi(0): Resetting Cmnd=0x01004a871b00, 
Handle=0x0202, action=""
scsi(0:1:15:0): Queueing device reset command.
st1: Error with sense data: Current st1: sense key Not Ready
Additional sense: Logical unit not ready, cause not reportable

I'm in the process of migrating Amanda from a SGI (Origin 300) 
server to a Linux server.   I'm hoping that I don't have to 
re-label all my tapes and lose the backups created with the old SGI 
Amanda server.
   

  
  I'm in the middle of relocating our entire computer room so I'll be
brief :) I have a bunch of LTO1s in a L80 hooked to a O3k so that's
essentially what you have. I'll be moving this to a Debian system soon
and in my testings I could drive the library and tape drives with mtx
and mt no problem except for the hardware compression bit on the
drive: after much mucking around with stinit I couldn't disable it but
seems the for LTO that's not a problem. Still looking for a way to
disable it though.

To your problem: what does 'mt status' says?

Here's what I got on a Debian system running 2.6.x

~# mt -f /dev/nst0 status
SCSI 2

Re: Amanda migration from SGI-Irix to Linux

[Luc Lalonde]

Hello Jean-François,

I think I found the problem.   I have another old binary 'mt' in the 
PATH that is causing the problem.   After removing I get the same output 
as you do:


[EMAIL PROTECTED] ~]# mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 512 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (4101):
BOT ONLINE IM_REP_EN
[EMAIL PROTECTED] bin]# /bin/mt -f /dev/nst1 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 512 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (4101):
BOT ONLINE IM_REP_EN

When I do an amcheck I get this error (changerdev /dev/sg0):

scsi(0): Resetting Cmnd=0x01000b06b880, Handle=0x0202, 
action=0x2

scsi(0:0:6:0): Queueing device reset command.

So the changer seems to be struggling...

I'm  continuing my investigations... 


Thanks again for your input...

Luc Lalonde wrote:

Hello Jean-François,

I'm getting this weird message with 'mt':

[EMAIL PROTECTED] ~]# mt -f /dev/nst0 status
Unknown tape drive type (0x72):
  residual= 0   ds = 200   er = 0
  file no= 0   block no= 0

What I don't understand is that it seems to be correctly recognized by 
the system:


[EMAIL PROTECTED] ~]# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 06 Lun: 00
 Vendor: STK  Model: L40  Rev: 0215
 Type:   Medium Changer   ANSI SCSI revision: 03
Host: scsi0 Channel: 00 Id: 15 Lun: 00
 Vendor: SEAGATE  Model: ULTRIUM06242-XXX Rev: 1619
 Type:   Sequential-AccessANSI SCSI revision: 03
Host: scsi0 Channel: 01 Id: 15 Lun: 00
 Vendor: SEAGATE  Model: ULTRIUM06242-XXX Rev: 1619
 Type:   Sequential-AccessANSI SCSI revision: 03

Any ideas?   By the way, the jukebox is connected to the server via a 
Qlogic QLA1240.   What are you using on your Linux box?


Thanks again.
PS:  'mtx -f /dev/sg0 status' seems to work fine.  I get a full report 
of the contents of my library.


Jean-Francois Malouin wrote:

* Luc Lalonde [EMAIL PROTECTED] [20060811 11:52]:
 

Hello Folks,

I'm getting this error when I try to use the tapes (LTO1) on a 
StorageTek L40 Jukebox:


st1: Block limits 1 - 16777215 bytes.
st1: Incorrect block size.
st1: Incorrect block size.
scsi(0): Resetting Cmnd=0x01004a871b00, 
Handle=0x0202, action=0x2

scsi(0:1:15:0): Queueing device reset command.
st1: Error with sense data: Current st1: sense key Not Ready
Additional sense: Logical unit not ready, cause not reportable

I'm in the process of migrating Amanda from a SGI (Origin 300) 
server to a Linux server.   I'm hoping that I don't have to re-label 
all my tapes and lose the backups created with the old SGI Amanda 
server.



I'm in the middle of relocating our entire computer room so I'll be
brief :) I have a bunch of LTO1s in a L80 hooked to a O3k so that's
essentially what you have. I'll be moving this to a Debian system soon
and in my testings I could drive the library and tape drives with mtx
and mt no problem except for the hardware compression bit on the
drive: after much mucking around with stinit I couldn't disable it but
seems the for LTO that's not a problem. Still looking for a way to
disable it though.

To your problem: what does 'mt status' says?

Here's what I got on a Debian system running 2.6.x

~# mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 512 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (4101):
 BOT ONLINE IM_REP_EN

~# ./amtapetype -o -f /dev/nst0 -e 100g
Writing 1024 Mbyte   compresseable data:  35 sec
Writing 1024 Mbyte uncompresseable data:  69 sec
WARNING: Tape drive has hardware compression enabled
Estimated time to write 2 * 102400 Mbyte: 13800 sec = 3 h 50 min
wrote 3178496 32Kb blocks in 97 files in 6880 seconds (short write)
wrote 3194880 32Kb blocks in 195 files in 6886 seconds (short write)
define tapetype unknown-tapetype {
comment just produced by tapetype prog (hardware compression on)
length 99584 mbytes
filemark 0 kbytes
speed 14815 kps
}

HTH
jf

 

Thanks!

Amanda migration from SGI-Irix to Linux

[Luc Lalonde]

Hello Folks,

I'm getting this error when I try to use the tapes (LTO1) on a 
StorageTek L40 Jukebox:


st1: Block limits 1 - 16777215 bytes.
st1: Incorrect block size.
st1: Incorrect block size.
scsi(0): Resetting Cmnd=0x01004a871b00, Handle=0x0202, 
action=0x2

scsi(0:1:15:0): Queueing device reset command.
st1: Error with sense data: Current st1: sense key Not Ready
Additional sense: Logical unit not ready, cause not reportable

I'm in the process of migrating Amanda from a SGI (Origin 300) server to 
a Linux server.   I'm hoping that I don't have to re-label all my tapes 
and lose the backups created with the old SGI Amanda server.


Thanks!

--
Luc Lalonde, analyste
-
Département de génie informatique:
Éole polytechnique de Montréal
(514) 340-4711 x5049
[EMAIL PROTECTED]
-
Never try to teach a pig to sing. It wastes your time, and it annoys 
the pig.
- 

Re: Amanda migration from SGI-Irix to Linux

[Luc Lalonde]

Hello Jean-François,

I'm getting this weird message with 'mt':

[EMAIL PROTECTED] ~]# mt -f /dev/nst0 status
Unknown tape drive type (0x72):
  residual= 0   ds = 200   er = 0
  file no= 0   block no= 0

What I don't understand is that it seems to be correctly recognized by 
the system:


[EMAIL PROTECTED] ~]# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 06 Lun: 00
 Vendor: STK  Model: L40  Rev: 0215
 Type:   Medium Changer   ANSI SCSI revision: 03
Host: scsi0 Channel: 00 Id: 15 Lun: 00
 Vendor: SEAGATE  Model: ULTRIUM06242-XXX Rev: 1619
 Type:   Sequential-AccessANSI SCSI revision: 03
Host: scsi0 Channel: 01 Id: 15 Lun: 00
 Vendor: SEAGATE  Model: ULTRIUM06242-XXX Rev: 1619
 Type:   Sequential-AccessANSI SCSI revision: 03

Any ideas?   By the way, the jukebox is connected to the server via a 
Qlogic QLA1240.   What are you using on your Linux box?


Thanks again.
PS:  'mtx -f /dev/sg0 status' seems to work fine.  I get a full report 
of the contents of my library.


Jean-Francois Malouin wrote:

* Luc Lalonde [EMAIL PROTECTED] [20060811 11:52]:
  

Hello Folks,

I'm getting this error when I try to use the tapes (LTO1) on a 
StorageTek L40 Jukebox:


st1: Block limits 1 - 16777215 bytes.
st1: Incorrect block size.
st1: Incorrect block size.
scsi(0): Resetting Cmnd=0x01004a871b00, Handle=0x0202, 
action=0x2

scsi(0:1:15:0): Queueing device reset command.
st1: Error with sense data: Current st1: sense key Not Ready
Additional sense: Logical unit not ready, cause not reportable

I'm in the process of migrating Amanda from a SGI (Origin 300) server to 
a Linux server.   I'm hoping that I don't have to re-label all my tapes 
and lose the backups created with the old SGI Amanda server.



I'm in the middle of relocating our entire computer room so I'll be
brief :) I have a bunch of LTO1s in a L80 hooked to a O3k so that's
essentially what you have. I'll be moving this to a Debian system soon
and in my testings I could drive the library and tape drives with mtx
and mt no problem except for the hardware compression bit on the
drive: after much mucking around with stinit I couldn't disable it but
seems the for LTO that's not a problem. Still looking for a way to
disable it though.

To your problem: what does 'mt status' says?

Here's what I got on a Debian system running 2.6.x

~# mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 512 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (4101):
 BOT ONLINE IM_REP_EN

~# ./amtapetype -o -f /dev/nst0 -e 100g
Writing 1024 Mbyte   compresseable data:  35 sec
Writing 1024 Mbyte uncompresseable data:  69 sec
WARNING: Tape drive has hardware compression enabled
Estimated time to write 2 * 102400 Mbyte: 13800 sec = 3 h 50 min
wrote 3178496 32Kb blocks in 97 files in 6880 seconds (short write)
wrote 3194880 32Kb blocks in 195 files in 6886 seconds (short write)
define tapetype unknown-tapetype {
comment just produced by tapetype prog (hardware compression on)
length 99584 mbytes
filemark 0 kbytes
speed 14815 kps
}

HTH
jf

  

Thanks!

Re: split disklist aphabetically

[Luc Lalonde]

I can't seem to get 'amcheck' to accept your suggestion.

Here's what I have in my 'disklist':

zeus /store/homes/students/ag /store/homes/students {
 # all directories that start with [a-g]
 exclude-tar
 include "./[a-g]*"
 } 1

When I do an 'amcheck', I get this error:

Amanda Backup Client Hosts Check

ERROR: zeus: [Can't open disk '/store/homes/students']
ERROR: zeus: [No include for '/store/homes/students/ag']
Client check: 8 hosts checked in 20.072 seconds, 2 problems found

(brought to you by Amanda 2.4.5)

Should I ignore this message?

Thanx.

Jon LaBadie wrote:

  On Thu, May 12, 2005 at 12:50:02PM -0400, Luc Lalonde wrote:
  
  
Hello Folks,

What are your recommendations for spliting directories with excludes 
without having to reorganize directories in a partition that I want to 
backup?

Basically, I want:

client   /foo/a*   dumptype-a
client  /foo/b*dumptype-b
.
client /foo/z*  dumptype-z


  
  
define dumptype common-stuff {
	...
}

client 	FooA	/foo	{
	common-stuff
	include file "./a*"
}

client	FooZ	/foo	{
	common-stuff
	include file "./z*"
}

  

Re: split disklist aphabetically

[Luc Lalonde]

The Amanda operator did not have the proper permissions...  The problem 
is now fixed.

Thanks.
Paul Bijnens wrote:
Luc Lalonde wrote:
I can't seem to get 'amcheck' to accept your suggestion.
Here's what I have in my 'disklist':
zeus /store/homes/students/ag /store/homes/students {
# all directories that start with [a-g]
exclude-tar
include ./[a-g]*
} 1
When I do an 'amcheck', I get this error:
Amanda Backup Client Hosts Check

ERROR: zeus: [Can't open disk '/store/homes/students']
ERROR: zeus: [No include for '/store/homes/students/ag']
Client check: 8 hosts checked in 20.072 seconds, 2 problems found
(brought to you by Amanda 2.4.5)
Should I ignore this message?

No.
Is the directory /store/homes/students readable by user amanda?

split disklist aphabetically

[Luc Lalonde]

Hello Folks,
What are your recommendations for spliting directories with excludes 
without having to reorganize directories in a partition that I want to 
backup?

Basically, I want:
client   /foo/a*   dumptype-a
client  /foo/b*dumptype-b
.
.
.
client /foo/z*  dumptype-z
Is this something that can be done?   What are the problems associated 
with this aproach?

Thanks in advance for any help you can offer.
PS:  I seem to remember someone else asking the same question on this 
mailing-list.   However, I can't seem to find the reference.

--
Luc Lalonde, analyste
-
Département de génie informatique:
École polytechnique de Montréal
(514) 340-4711 x5049
[EMAIL PROTECTED]
-
Never try to teach a pig to sing. It wastes your time, and it annoys 
the pig.
- 

Re: AMANDA Documentation at www.oops.co.at (SGI Irix additions)

[Luc Lalonde]

I think that it should go into the SGI-Irix section...
Stefan G. Weichinger wrote:
Hi, Luc Lalonde,
on Donnerstag, 05. August 2004 at 04:09 you wrote to amanda-users:
LL Hello Stefan,
LL Thanks for the enormous work that you've done putting together this
LL document.
Thank you ...
LL I've to some Irix (6.5.x) notes:
LL 1)  If you use a jukebox, you must set the ownership of the 
LL robot-changer device to the Amanda operator:group in /etc/ioperms.
LL Here's my configure:

LL /etc/ioperms: /dev/scsi/sc8d6l0 0600 amanda backup
LL Otherwise the ownership:group is changed to root:sys after each reboot.
LL 2)  When you do upgrades, check the file /var/sysgen/master.d/scsi to
LL see if it has changed.   Otherwise your jukebox could be rendered 
LL unuseable.   In particular, check if it has been replaced by a new
LL version and renamed to 'scsi.O'.

LL If you use the Amanda package provided by freeware.sgi.com, you are not
LL affected by the first question since at compile time the Amanda operator
LL is root:sys.
You have already thought about where one would prefer to find that
infos?
I assume this should go into the current chapter 9 AMANDA Tape
Changer Support ...
 

--
Luc Lalonde, analyste
-
Département de génie informatique:
École polytechnique de Montréal
(514) 340-4711 x5049
[EMAIL PROTECTED]
-
War is good for business, invest your son!
- 

Re: AMANDA Documentation at www.oops.co.at (SGI Irix additions)

[Luc Lalonde]

Hello Stefan,
No not the email.   There are a few corrections in the text I resent 
you.   You changed the format of the text and I corrected the wording to 
ajust to your changes...

Thanks.
Stefan G. Weichinger wrote:
Hi, Luc,
on Donnerstag, 05. August 2004 at 15:59 you wrote to amanda-users:
LL Hello Stefan,
LL Here's a few corrections (in blue):
LL Cut Here**
LL Luc Lalonde [EMAIL PROTECTED]
LL mailto:[EMAIL PROTECTED] 

You mean the email-adress?? The format is pretty strict in my XML-DTD.
Or do I miss the point again?
best regards,
Stefan.
 

--
Luc Lalonde, analyste
-
Département de génie informatique:
École polytechnique de Montréal
(514) 340-4711 x5049
[EMAIL PROTECTED]
-
War is good for business, invest your son!
- 

Re: AMANDA Documentation at www.oops.co.at (SGI Irix additions)

[Luc Lalonde]

Hello Stefan,
Thanks for the enormous work that you've done putting together this 
document.

I've to some Irix (6.5.x) notes:
1)  If you use a jukebox, you must set the ownership of the 
robot-changer device to the Amanda operator:group in /etc/ioperms.   
Here's my configure:

/etc/ioperms: /dev/scsi/sc8d6l0 0600 amanda backup
Otherwise the ownership:group is changed to root:sys after each reboot.
2)  When you do upgrades, check the file /var/sysgen/master.d/scsi to 
see if it has changed.   Otherwise your jukebox could be rendered 
unuseable.   In particular, check if it has been replaced by a new 
version and renamed to 'scsi.O'.

If you use the Amanda package provided by freeware.sgi.com, you are not 
affected by the first question since at compile time the Amanda operator 
is root:sys.

Bye.
Stefan G. Weichinger wrote:
Hello, amanda-users,
about one month has gone now, since I put a pre-release of The
Official AMANDA Documentation online at
http://www.oops.co.at/AMANDA-docs/index.html
This was just meant as a ground for discussion (for
amanda-core-members), but it seems to hit the needs of several more
people:
The hits at www.oops.co.at have risen since then, and still rise.
No problem with that, just some thoughts:
- The current info is just equivalent to the infos in the (in some
parts outdated and incorrect :-( ) AMANDA-docs.
- The current formatting is far from being complete, there is much
potential for improvement (think XML-tags, indexing, ...)
Given the fact that I am more than busy with other
documentation-related tasks I just want to tell all of you that:
- every kind of correction is welcome.
- every kind of addition is welcome.
Feel free to express your thoughts, I will try the best to transform
your input into contributions to AMANDA.
best regards,
Stefan G. Weichinger
 

--
Luc Lalonde, analyste
-
Département de génie informatique:
École polytechnique de Montréal
(514) 340-4711 x5049
[EMAIL PROTECTED]
-
War is good for business, invest your son!
- 

Rsync, Amanda's best friend

[Luc Lalonde]

Hey Folks,
I'm sure I'm not the first one to think of doing this...
In case of backup server failure, I 'rsync' all my configuration files 
in /etc with the Amanda index files onto another server.   If my server 
crashes or becomes unavailable, I have instantaneaous access to my 
backup indices and configurations without mucking about and trying to 
find it on the backup tapes without an online Amanda setup.

I just thought I'd put my two cents worth after reading the message 
about Gavin Henry's backup server crash.

Bye.
--
Luc Lalonde, analyste
-
Département de génie informatique:
École polytechnique de Montréal
(514) 340-4711 x5049
[EMAIL PROTECTED]
-
War is good for business, invest your son!
- 

UDP and TCP portrange directives

[Luc Lalonde]

Hello Folks,

If Amanda is configured with the --with-portrange, --with-tcpportrange, 
--with-udpportrange on the client, are you obligated to recompile on the 
server with these directives also?

The reason I'm asking is that the client has a firewall installed...but 
not the server.  I also have other clients that do not have the strict 
UDP and TCP portranges established at compile time.

Thank You.

--
Luc Lalonde, analyste
-
Département de génie informatique:
École polytechnique de Montréal
(514) 340-4711 x5049
[EMAIL PROTECTED]
-
War is good for business, invest your son!
- 

client-side enforced excludes

[Luc Lalonde]

Hello Folks,

Would there be a way to force excludes from the client side?  I want to 
enforce an exclude list regardless of wether the exclude directive states on 
the server amanda.conf file.

One way I thought of doing this is by writting a shell wrapper for tar on the 
client and using it in the configure script:

./configure --prefix=/opt/amanda --with-user=amanda --with-group=backup \
--with-gnutar=/opt/bin/tar-wrapper

 The wrapper would have a line like:

/bin/tar -exclude-from /etc/amanda/exclude.gtar $@

Any other suggestions?

Cheers.
-- 
Luc Lalonde, analyste
-
Département de génie informatique:
École polytechnique de Montréal
(514) 340-4711 x5049
[EMAIL PROTECTED]
-
War is good for business, invest your son!
- 

Re: chg-scsi: dev and scsitapedev on IRIX

[Luc Lalonde]

Hello Eric,

Thanks for your kind help.   This was the one of the first things that I 
tried to get it to work.  I don't think that there's such a thing as a 
non-blocking device in IRIX...at least I can't seem to find any 
reference to it.

Also, I think that the chg-scsi has broken support for IRIX in 
Amanda-2.4.3.  Everything worked fine when I used chg-scsi in 2.4.2p2.

I'm willing to help the people who are maintaining the chg-scsi in 
Amanda to get it back in working order for IRIX.  For know I'm using 
chg-zd-mtx.

Cheers, Luc.

Eric Schnoebelen wrote:

Luc Lalonde writes:
- What would be the difference between dev and scsitapedev?  Would 
- dev be the tape device name and scsitapedev be the scsi controller 
- device name?

   dev is the blocking tape device name (/dev/nrst0), while
scstapedev is the non blocking (control) device name
(/dev/enrst0 on NetBSD, I'm not sure there is something
comparable on IRIX, there wasn't the last time I plaed with it,
circa 1995)

   Try leaving scsitapedev unset.

--
Eric Schnoebelen   [EMAIL PROTECTED]   http://www.cirr.com
   Beneath revolution (Linux) there's also evolution (*BSD) 
   -- Andre Oppermann, Apr. 1998
  

chg-scsi: dev and scsitapedev on IRIX

[Luc Lalonde]

Hello folks,

What would be the difference between dev and scsitapedev?  Would 
dev be the tape device name and scsitapedev be the scsi controller 
device name?

I'm trying to use the chg-scsi from amanda-2.4.3 and am  having no 
success.  My chg-scsi.conf works fine with amanda-2.4.2.  Would someone 
who has a working config on IRIX show me their config file please?

Cheers, Luc.

chg-scsi error after upgrade from 2.4.2p2 to 2.4.3

[Luc Lalonde]

Hello Folks,

I have a working chg-scsi.conf with 2.4.2p2 under IRIX with a StorageTek 
L40.  However, when I try to upgrade to 2.4.3, I get this error:

amcheck-server: could not get changer info: could not read result from 
/opt/amanda/libexec/chg-scsi

I'd like to take advantage of the new changer features in amrecover ;-\  


## begin chg-scsi.conf 
number_configs  1
eject   1   # Tapedrives need an eject command
sleep   5   # Seconds to wait until the tape gets ready
cleanmax20  # How many times could a cleaning tape get used
changerdev  /dev/scsi/sc8d6l0
#
# data for drive 0
#
config  0
drivenum0
dev /hw/tape/tps8d15nrnsv
startuse0
enduse  19
statfile/etc/amanda/Journalier/tape-slot
#cleancart  40
cleanfile   /etc/amanda/Journalier/tape-clean
usagecount  /etc/amanda/Journalier/totaltime
tapestatus  /etc/amanda/Journalier/tapestatus
labelfile   /etc/amanda/Journalier/tapelabels
## end chg-scsi.conf 

Thanks, Luc.

Re: Manual Tape changing

[Luc Lalonde]

Hello John,

Thanks for your prompt help!

Everything seems to work great.   One thing remains though.  I find it
strange that I get this line in the backup report:

###
These dumps were to tapes Monthly-03, Monthly-04.
The next 2 tapes Amanda expects to used are: a new tape, a new tape.
###

The next tapes in the tapelist file clearly indicate the sequence of empty
tapes:

###
20010630 Monthly-04 no-reuse
20010630 Monthly-03 no-reuse
20010519 Monthly-02 no-reuse
0 Monthly-13 reuse
0 Monthly-12 reuse
0 Monthly-11 reuse
0 Monthly-10 reuse
0 Monthly-09 reuse
0 Monthly-08 reuse
0 Monthly-07 reuse
0 Monthly-06 reuse
0 Monthly-05 reuse
###

Why is it not asking for Montly-05 and Monthly-06  for the next backup?

Also, I accidently did an amrmtape of Monthly-01.   What are the steps to
recover the indexes?

Thanks.



John R. Jackson wrote:

 When we change the request() in src/changer-src/chg-manual.sh.in to
 include notification every 60 minutes will AMDUMP automatically detect
 the inserted tape and continue the backup?  ...

 That depends on how you changed request().  :-)

 If you took the code in the comments and put that in the changer.conf
 file so it overrides the builtin request, it will check for the tape being
 mounted every minute (not every hour).  As soon as the drive goes ready,
 amdump (or amcheck, etc) will continue.

 The one hour timer in the script is for the E-mail notification only.

 Also, suppose that I want I don't want to be mailed every hour but
 instead I want Amanda to dump to the holding disk and wait for me to
 make the next tape available in the morning.  How would I change the
 request()?

 I think you'll have to do more than just change request() to accomplish
 this.  Here's how I'd try it:

   * Change request to set tape to skip (or some non-/dev name)
 after an hour.

   * Change the code in loadslot that calls request() to look for $tape
 being skip after the call, and if so, return an error back to the
 caller (e.g. look at how eject() handles an error).  Amanda will
 handle this and do the rest of the dumps in degraded mode (into the
 holding disk).

 My understanding of the need for the changer.conf file is for automatic
 tape changers...is this correct?

 Not necessarily.  Contents of the changer.conf file (or files) is entirely
 up to the changer.  For most, it is configuration information, such as
 the range of slots, and other hardware characteristics.  For chg-manual,
 the file is sourced into the script, which means it can do things like
 override the request() function.

 Finally, do I need to put some special label sequence on the tapes for
 this configuration (ie Monthly-XXX-Slot-X)?  ...

 No, although it might make your life easier.  As long as you know what
 slot 14 is when the changer asks for it, Amanda doesn't care what the
 actual label is on the tape.

 Actually, the slot number is pretty meaningless to chg-manual.  As long
 as you load the next tape Amanda wants, the slot number itself is not
 used for anything.  In fact, if you do an amtape config eject after
 each run, the slot number will be reset to zero.  If you do an amadmin
 config tape before the run, slot zero means the first tape, slot 1
 means the second and so on.

 Luc Lalonde

 John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]

--
Luc Lalonde, Responsable du reseau GIREF

Telephone: (418) 656-2131 poste 6623
Courriel: [EMAIL PROTECTED]




begin:vcard 
n:Lalonde;Luc
x-mozilla-html:FALSE
org:Universite Laval;GIREF
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Administateur de reseau
x-mozilla-cpt:;0
fn:Luc Lalonde
end:vcard

Manual Tape changing

[Luc Lalonde]

Hello Folks,

When we change the request() in src/changer-src/chg-manual.sh.in to
include notification every 60 minutes will AMDUMP automatically detect
the inserted tape and continue the backup?  I assume that it will do so
on the next hourly check from what I can understand in the src.

Also, suppose that I want I don't want to be mailed every hour but
instead I want Amanda to dump to the holding disk and wait for me to
make the next tape available in the morning.  How would I change the
request()?

My understanding of the need for the changer.conf file is for automatic
tape changers...is this correct?

Finally, do I need to put some special label sequence on the tapes for
this configuration (ie Monthly-XXX-Slot-X)?  Or can I just use
Monthly-XXX?  Basically I just want to know if I need to use the slot
argument for the amlabel if I change the tape manually.  

I'm using a Daily config with great success (Thanks!).  However, I can't
fit the Monthly full dumps on one tape.

Cheers.
-- 
Luc Lalonde, Responsable du reseau GIREF

Telephone: (418) 656-2131 poste 6623
Courriel: [EMAIL PROTECTED]

Monthly config

[Luc Lalonde]

Hey folks,

I've got a Daily config running fine with the following settings:

dumpcycle 1 weeks
runspercycle 5
tapecycle 17 tapes

I'd like to have a second config called "Monthly".  However, I'm not
sure what to put as
values for the above parameters.   Here's what I was able to find from
various information sources:

dumpcycle 0 weeks
runspercycle ???
tapecycle 1000 tapes

I want to keep the tapes and not overwrite them...hence the high number
in the tapecyle.  Also, I want full dumps
everytime.But what do I put as "runspercycle"?   If I have the
"Daily" and "Monthly" running on two seperate configs, what
will there be conflicts with /etc/dumpdates and /etc/amandates?  Is
there an other potential conflicts that I should know about?

Cheers.

--
Luc Lalonde, Responsable du reseau GIREF

Telephone: (418) 656-2131 poste 6623
Courriel: [EMAIL PROTECTED]




begin:vcard 
n:Lalonde;Luc
x-mozilla-html:FALSE
org:Universite Laval;GIREF
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Administateur de reseau
x-mozilla-cpt:;0
fn:Luc Lalonde
end:vcard

Monthly config

[Luc Lalonde]

Hello Folks,

What can I say...WOW.  Thanks for all the advice and warnings for
creating a Montly backup concurrently with a Daily backup.

I didn't expect to get an answer so quickly.  John, FYI, I'm using
2.4.2p1.   I try to keep up with the latest versions.  I'll try the
strategic noinc.

Cheers.

--
Luc Lalonde, Responsable du reseau GIREF

Telephone: (418) 656-2131 poste 6623
Courriel: [EMAIL PROTECTED]




begin:vcard 
n:Lalonde;Luc
x-mozilla-html:FALSE
org:Universite Laval;GIREF
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Administateur de reseau
x-mozilla-cpt:;0
fn:Luc Lalonde
end:vcard

Hardware Compression and tape capacity

[Luc Lalonde]

Hello Folks,

Many thanks to John R. Jackson and Yura Pismerov for their answers
concerning estimating the tape size by hand for hardware compression.

Regards...

--
Luc Lalonde, Responsable du reseau GIREF

Telephone: (418) 656-2131 poste 6623
Courriel: [EMAIL PROTECTED]




begin:vcard 
n:Lalonde;Luc
x-mozilla-html:FALSE
org:Universite Laval;GIREF
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Administateur de reseau
x-mozilla-cpt:;0
fn:Luc Lalonde
end:vcard

Re: Amanda and xinetd

[Luc Lalonde]

Here's my working version:

service amanda
{
socket_type = dgram
protocol = udp
wait = yes
user = amanda
group = backup
groups = yes
server = /opt/libexec/amandad
}

service amandaidx
{
socket_type = dgram
protocol = tcp
wait = yes
user = amanda
group = backup
groups = yes
server = /opt/libexec/amindexd
}

service amidxtape
{
socket_type = dgram
protocol = tcp
wait = yes
user = amanda
group = backup
groups = yes
server = /opt/libexec/amidxtaped
}

Make sure you have the proper entries in /etc/services

Raymond Bramwell wrote:

 Hi there!

 I was just wondering if anyone has successfully configured amanda to
 backup clients running xinetd rather than inetd!
 If so could someone let me know what you need to put in /etc/xinetd.conf
 'cos I'm really stumped, I've tried the following:

 service amanda
 {
 flags   = REUSE NAMEINARGS
 socket_type = dgram
 protocol= udp
 wait= yes
 user= backup
 server  = /usr/local/libexec/amandad
 server_args = amandad
 }

 And tried permutations of missing out the flags and server_args
 arguments.  In all these cases when I run amcheck on the amanda
 server it fails on this client with permission denied errors for each
 disk and the dumpdates file.  Before you ask, no its not
 a permissions problem because when I use inetd with:

 amanda dgram udp wait backup /usr/local/libexec/amandad amandad

 in /etc/inetd.conf it works fine!  The thing is I need to be using
 xinetd and not inetd.  Can anyone help?

 Ray.

--
Luc Lalonde, Responsable du reseau GIREF

Telephone: (418) 656-2131 poste 6623
Courriel: [EMAIL PROTECTED]




begin:vcard 
n:Lalonde;Luc
x-mozilla-html:FALSE
org:Universite Laval;GIREF
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Administateur de reseau
x-mozilla-cpt:;0
fn:Luc Lalonde
end:vcard

amdump and eject

[Luc Lalonde]

Hey folks,

Is this safe to put in the Amanda crontab?

/usr/sbin/amdump Daily; /usr/bin/mt -f /dev/nst0 eject

I'm just wondering if "amdump" spawns other jobs that need to be executed before 
quitting and then ejecting the

tape.

Cheers, Luc.

PS: Amanda is really great.  I've only one complaint though.  I can't seem to get 
estimates from Solaris 2.7.  "sensize" takes forever with "tar".

I eventually have to kill it.  I just bypass the problem and use "ufsdump".  Is this 
one of the bugs that is fixed in 2.4.2p1?

--
Luc Lalonde, Responsable du reseau GIREF

Telephone: (418) 656-2131 poste 6623
Courriel: [EMAIL PROTECTED]




begin:vcard 
n:Lalonde;Luc
x-mozilla-html:FALSE
org:Universite Laval;GIREF
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Administateur de reseau
x-mozilla-cpt:;0
fn:Luc Lalonde
end:vcard

Re: selfcheck permission weirdness (Linux ok, but not Solaris)

[Luc Lalonde]

Hello Ben,

That was it.  Geez Amanda installation sure isn't for the faint of heart!

Could this also be why my sendsize wouldn't work either when I used "tar"?

Cheers, Luc.

Ben Hyatt wrote:

  checking disk /home: device /dev/rdsk/c0t0d0s7: Permission denied
   
 what does ls -la on c0t0d0s7 look like?

 For example:

  ls -la ../../devices/pci@1f,4000/scsi@3/sd@0,0:h,raw
 crw-r-   1 root sys   32,  7 Jan 22 14:15
 ../../devices/pci@1f,4000/scsi@3/sd@0,0:h,raw

 Make sure the user amanda runs as has read permission on the raw device.

  Luc Lalonde, Responsable du reseau GIREF

 -Ben

--
Luc Lalonde, Responsable du reseau GIREF

Telephone: (418) 656-2131 poste 6623
Courriel: [EMAIL PROTECTED]




begin:vcard 
n:Lalonde;Luc
x-mozilla-html:FALSE
org:Universite Laval;GIREF
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Administateur de reseau
x-mozilla-cpt:;0
fn:Luc Lalonde
end:vcard

Solaris timeouts with 2.4.2, slowness with Linux clients

[Luc Lalonde]

Hello Folks,


I'm getting weird timeouts with Solaris 2.7 clients but not with Linux
clients.  Here's the debug message:

Amanda 2.4 NAK HANDLE 005-80C20708 SEQ 980329506
ERROR amandad busy

Also, I'm finding that the backups are very slow compared to when done
manually.  I used to mount the directories by NFS and tar everything. 
It used to take only around 4 hours.  With Amanda, 8 hours have gone by
and it's still not half done.

I've got the server and clients using the Amanda executibles from the
same NFS mount.  Would it speed things up if I installed everything
locally on the client machines?  Would this also get rid of the Solaris
errors mentionned above?  Here's a status output:

SUMMARY  part real estimated
  size  size
partition   :  32
estimated   :  19   37468030k
failed  :  21   17689270k   ( 47.21%)
wait for dumping:   18293590k   ( 22.14%)
dumping to tape :   0  0k   (  0.00%)
dumping :   1  1292480k  3481650k ( 37.12%) (  3.45%)
dumped  :   9  8004064k  8003520k (100.01%) ( 21.36%)
wait for writing:   00k0k (  0.00%) (  0.00%)
writing to tape :   00k0k (  0.00%) (  0.00%)
failed to tape  :   00k0k (  0.00%) (  0.00%)
taped   :   9  8004064k  8003520k (100.01%) ( 21.36%)
3 dumpers idle  : no-diskspace
taper idle
network free kps: 1970
holding space   :  4906784k ( 58.49%)
 dumper0 busy   :  0:01:46  (  0.71%)
 dumper1 busy   :  0:02:14  (  0.90%)
 dumper2 busy   :  0:03:06  (  1.25%)
 dumper3 busy   :  3:17:35  ( 79.61%)
   taper busy   :  0:51:53  ( 20.91%)
 0 dumpers busy :  0:50:25  ( 20.31%)no-diskspace:  0:50:25 
(100.00%)
 1 dumper busy  :  3:14:40  ( 78.43%)no-diskspace:  3:14:40 
(100.00%)
 2 dumpers busy :  0:00:48  (  0.33%)no-diskspace:  0:00:48 
(100.00%)
 3 dumpers busy :  0:00:48  (  0.33%)no-diskspace:  0:00:44  (
90.57%)
   start-wait:  0:00:04  ( 
9.43%)
 4 dumpers busy :  0:01:30  (  0.60%)  no-dumpers:  0:01:15  (
83.67%)
 not-idle:  0:00:14  (
16.33%)

Re: Solaris: suid root stuff

[Luc Lalonde]

Hello John,

You put your finger right on the solution!   The former admin put
a"nosuid" mount on the partition that had Amanda installed!   I removed it
and it corrected the problem.

Thanks!

Luc Lalonde


"John R. Jackson" wrote:

 I can't seem to figure this one out.  I've got my Linux host running
 Amanda-2.4.2 and all the Linux clients working allright but not my
 Ultra10's running Solaris 2.7.
 ...
 Is there a Solaris patch I should know about?

 I don't think so.  I have several Solaris 2.7 machines, both Sparc and
 Ultra, and they are working fine.

 Here's a listing of runtar:
 -rwsr-x--- 1 root  backup 216808 Jan 20 21:19 runtar
 
 And here's the error I get in /tmp/amanda/sendsize.debug:
 runtar: error [must be setuid root]

 I assume the "ls -l" and sendsize*debug came from the same client host?

 Is there any NFS going on, like is runtar being served from some other
 machine?  If so, you'll need to change the client mount command (or
 automount, etc) and possibly the server (e.g. dfstab) to allow setuid
 across the NFS mount.  See "man mount_nfs" and "man dfstab_nfs".

 Here's a small patch to log what effective UID runtar thinks it is,
 which might shed some more light on things.

 Luc.

 John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]

   
  Name: runtar.diff
runtar.diff   Type: unspecified type (application/octet-stream)
   Description: runtar.diff

--
Luc Lalonde, Responsable du reseau GIREF

Telephone: (418) 656-2131 poste 6623
Courriel: [EMAIL PROTECTED]




begin:vcard 
n:Lalonde;Luc
x-mozilla-html:FALSE
org:Universite Laval;GIREF
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Administateur de reseau
x-mozilla-cpt:;0
fn:Luc Lalonde
end:vcard

Solaris: suid root stuff

[Luc Lalonde]

Hey folks,

I can't seem to figure this one out.  I've got my Linux host running
Amanda-2.4.2 and all the Linux clients working allright but not my
Ultra10's running Solaris 2.7.

Here's a listing of runtar:
-rwsr-x---  1 root  backup 216808 Jan 20 21:19 runtar

And here's the error I get in /tmp/amanda/sendsize.debug:
runtar: error [must be setuid root]

The amcheck runs fine for this client.  I tried adding amanda to the sys
group to see if it was read permissions...but to no avail ;-\

Is there a Solaris patch I should know about?

Cheers, Luc.