Help! amdump must be run as user bin - Amanda 2.4.1

2000-11-21 Thread Christopher P. Mills

I am trying to install amanda on a new server and am trying to have it run
as a user other than bin. I configured amanda --with-user=amanda.

amcheck now works fine, but if I try and run amdump as 'amanda' then it all
goes pear shaped. I get the 'amdump: must be run as user bin' message. If I
change to user 'bin', I get a whole new batch of problems as all the amanda
binaries are owned by 'amanda'.

Please help.

Thanks in advance

Chris Mills
Web/Network Development Officer
Cranfield University
RMCS Shrivenham

P.S.Sorry if this is an FAQ, but I respect the ability of the people on
this list and I am sure someone will come up with the answer very quickly.
;-)




RE: Help! amdump must be run as user bin - Amanda 2.4.1

2000-11-21 Thread Christopher P. Mills

Doh!

Sorry. Just found the problem. Copied the config from the old server which
was using the user 'bin'. There is an option on about line 2 of amanda.conf
which tells the system which user to run the dump as. It was set to 'bin'
not 'amanda'!

Sorry!

Chris Mills

 -Original Message-
From:   Christopher P. Mills [mailto:[EMAIL PROTECTED]]
Sent:   21 November 2000 09:05
To: '[EMAIL PROTECTED]'
Subject:Help! amdump must be run as user bin - Amanda 2.4.1

I am trying to install amanda on a new server and am trying to have it run
as a user other than bin. I configured amanda --with-user=amanda.

amcheck now works fine, but if I try and run amdump as 'amanda' then it all
goes pear shaped. I get the 'amdump: must be run as user bin' message. If I
change to user 'bin', I get a whole new batch of problems as all the amanda
binaries are owned by 'amanda'.

Please help.

Thanks in advance

Chris Mills
Web/Network Development Officer
Cranfield University
RMCS Shrivenham

P.S.Sorry if this is an FAQ, but I respect the ability of the people on
this list and I am sure someone will come up with the answer very quickly.
;-)




5Gb partition-what is wrong?

2000-11-21 Thread Longina Przybyszewska


Hi,
I can not figure out  reason for error conditions during the backup of 5Gb
partition on  Linux RedHat7:

==
FAILURE AND STRANGE DUMP SUMMARY:
  despinahda7 lev 0 FAILED [data timeout]
  despinahda7 lev 0 FAILED [dump to tape failed]


STATISTICS:
  Total   Full  Daily
      
Estimate Time (hrs:min)0:08
Run Time (hrs:min) 6:43
Dump Time (hrs:min)6:42   6:10   0:32
Output Size (meg)6568.0 6406.3  161.7
Original Size (meg) 13080.112429.5  650.6
Avg Compressed Size (%)48.2   49.4   24.8   (level:#disks ...)
Filesystems Dumped   56 21 35   (1:34 2:1)
Avg Dump Rate (k/s)   279.1  295.4   87.6

Tape Time (hrs:min)4:49   4:46   0:03
Tape Size (meg)  7916.0 7753.3  162.8
Tape Used (%)  67.5   66.21.4   (level:#disks ...)
Filesystems Taped57 22 35   (1:34 2:1)
Avg Tp Write Rate (k/s)   466.9  462.3  888.6
.
.
despina  hda70 N/A1378624   --N/A   N/A   63:09 363.9
.


=

output from amadmin:

2000-11-17 despina hda7  0 --- 0 FAILED (driver) [dump to tape
failed]
2000-11-17 despina hda7  0 --- 0 FAILED (dumper) [data
timeout]
2000-11-17 despina hda7  0 Daily5456 OK
2000-11-20 despina hda7  0 --- 0 FAILED (driver) [dump to tape
failed]
2000-11-20 despina hda7  0 --- 0 FAILED (dumper) [data
timeout]
2000-11-20 despina hda7  0 Daily5553 OK
2000-11-21 despina hda7  0 --- 0 FAILED (driver) [dump to tape
failed]
2000-11-21 despina hda7  0 --- 0 FAILED (dumper) [data
timeout]
2000-11-21 despina hda7  0 Daily5956 OK

==

Size of partiton is about 5Gb - and it seems that only 1.3Gb is written to
the tape.
Why amanda reports fail and then OK - if it is _NOT OK_?

REgards
longina 




--
Longina Przybyszewska, system programmerPhone:   +45 6550 2359
Dept. of Math.  Comp. Sci.
SDU, Odense University, Campusvej 55Email:[EMAIL PROTECTED]
DK-5230 Odense M, Denmark   
--





amanda using ssh

2000-11-21 Thread Edwin Peer

Hi Guys,

Is it possible to have amanda do backups of remote workstations using ssh?
At the moment I'm toying with doing a VPN over ssh using pppd and running
the backups over that link - but it's messy.

Cheers,
   Edwin




Re: amanda using ssh

2000-11-21 Thread Alexandre Oliva

On Nov 21, 2000, Edwin Peer [EMAIL PROTECTED] wrote:

 Is it possible to have amanda do backups of remote workstations using ssh?

It *might* be possible with the new security API in the CVS tree.

 At the moment I'm toying with doing a VPN over ssh using pppd and running
 the backups over that link - but it's messy.

How about CIPE?  This will probably work without messing up with the
Amanda protocol.  CIPE will take care of the VPN encryption in the IP
level, so both UDP and TCP, used by Amanda, will work.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me



Need guidelines

2000-11-21 Thread Siavosh Akhtary

Hi All,

I have setup amanda to backup some file systems in a Linux network (RH
7.0 and 6.1).
The hardware is from HP, A SureStore 818 autoloader with a DLT 8000
drive.

The network has about 180 GB disk which should be backed up. I wonder if
someone can help me with tuning of such a solution.

All ideas are welcomed
Many thanks :-)



begin:vcard 
n:Akhtary;Siavosh
tel;cell:+46 70 569 72 61
tel;fax:+46 31 745 00 10
tel;work:+46 31 745 01 10
x-mozilla-html:FALSE
org:Teraport Aktiebolag
adr:;;Lilla Bommen 6;Gothenburg;;SE-411 04;Sweden
version:2.1
email;internet:[EMAIL PROTECTED]
title:TAM
fn:Siavosh Akhtary
end:vcard



Re: Can DLT7000 inter-operate with DLT4000?

2000-11-21 Thread David McCall

I've receintly upgraded from the 20/40 to the 40/80.
backward read compatability is fine, however, you can NOT relabel the
80 gig tapes that were previously labeled in 40 gig mode.  The tapes need
to be bulk erased 1st.  I tried bulk erasing with the most powerful
magnetic field we had in the media dept. to no avail.  Amanda still
read the labels.

fyi

David Wolfskill wrote:

 From: Alexandre Oliva [EMAIL PROTECTED]
 Date: 18 Nov 2000 05:51:47 -0200

 (i) in case the DLT4000 robot fails, the DLT7000 tape drive will be
 able to read backups done with it, and

 (ii) after the DLT4000 robot is fixed, it will be able to read tapes
 written by the DLT7000 drive.

 The autoloader with which I started using amanda was a 7-slot ADIC
 device with a DLT 4000 drive (August, 1998).

 I had told my manager that sometime around spring of this year, we
 should plan on going to a DLT 8000 drive.  We did this (though it took
 longer than expected); it arrived in mid-October, just before I went on
 a 2-week vacation (for the first time in years).

 Since we have a dedicated amanda server, it isn't being used when the
 backups aren't running (and I'm not tweaking it); I was able to swap the
 devices and do some preliminary testing.  Basically, the drive worked
 just fine without making any changes to the amanda configuration --
 though we weren't making optimal use of its capabilities.

 Given that I was going to be out of the office for a while, I chose to
 leave well enough alone until my return.

 After I got back, I found that amanda had run trouble-free; given that,
 I started making changes to take advantage of the DLT 8000 -- briefly,
 it holds twice as much (40 GB vs. 20 GB native) and writes as much as
 four times (6 MB/s vs. 1.5 MB/s) the DLT 4000 drive.  (Tape writing
 speed is nowhere near the bottleneck now.)

 From this, we may observe that the DLT 8000 drive had no trouble reading
 the tapes that had been written with the DLT 4000 drive -- I did not
 need to re-label the tapes (via amlabel), for example.  And I believe I
 did a restore or two, using the DLT 8000 drive, from backups that had
 been written with the DLT 4000 drive.

 Although I have not tested it, I would not expect that the DLT 4000
 could read tapes written by the DLT 8000, though -- unless there's some
 way to force the DLT 8000 to *write* in DLT 4000 mode, which I doubt.

 I would expect similar considerations to apply to a DLT 7000.

 Cheers,
 david
 --
 David Wolfskill  [EMAIL PROTECTED]   UNIX System Administrator
 Desk: 650/577-7158   TIE: 8/499-7158   Cell: 650/759-0823


begin:vcard 
n:McCall;David
tel;cell:707-592-6056
tel;home:707-792-0482
tel;work:707-664-3099
x-mozilla-html:FALSE
url:http://veronica.sonoma.edu/
org:Sonoma State University;Information Technology/Computer Operations
adr:;;1801 E. Cotati Avenue;Rohnert Park;California;94928-3609;California
version:2.1
email;internet:[EMAIL PROTECTED]
title:Operating Systems Analyst
x-mozilla-cpt:;1
fn:David McCall
end:vcard



dumper: FATAL must be run setuid root to communicate correctly

2000-11-21 Thread Blohm, Matthias (init)



Hello,

Doesanybody 
know why I got that Problems?
And what I am doing 
wrong ?
There are no more 
Infos in the amdump file.
--

*** THE DUMPS DID NOT FINISH PROPERLY!

*** A TAPE ERROR OCCURRED: [cannot overwrite active 
tapeTESTTAPE].*** PERFORMED ALL 
DUMPS TO HOLDING DISK.

THESE DUMPS WERE TO DISK. Flush them onto a 
new tape.Tonight's dumps should go onto 1 tape: a new tape.

FAILURE AND STRANGE DUMP SUMMARY: 
fileserer1 /usr/local/cvsroot lev 0 FAILED 
[fileserver1: [hostfileserver1.domain.com: port 2107 not secure] 
fileserver1 /home lev 0 FAILED 
[fileserver1: [host fileserver1.domain.com: port 2107 not secure] 
fileserver1 /etc lev 0 FAILED 
[fileserver1: [host fileserver1.domain.com: port 2107 not secure] 
dumper: FATAL must be run setuid root to communicate correctly dumper: 
FATAL must be run setuid root to communicate correctly dumper: FATAL 
must be run setuid root to communicate correctly dumper: FATAL must be 
run setuid root to communicate correctly



Thanks in 
advance
Matthias


Re: dumper: FATAL must be run setuid root to communicate correctly

2000-11-21 Thread Alexandre Oliva

On Nov 21, 2000, "Blohm, Matthias (init)" [EMAIL PROTECTED] wrote:

 Does anybody know why I got that Problems?

Did you `make install' as root?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me



AW: dumper: FATAL must be run setuid root to communicate correctly

2000-11-21 Thread Blohm, Matthias (init)

Yes, I Did so !


-Ursprüngliche Nachricht-
Von: Alexandre Oliva [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 21. November 2000 15:42
An: Blohm, Matthias (init)
Cc: '[EMAIL PROTECTED]'
Betreff: Re: dumper: FATAL must be run setuid root to communicate
correctly


On Nov 21, 2000, "Blohm, Matthias (init)" [EMAIL PROTECTED]
wrote:

 Does anybody know why I got that Problems?

Did you `make install' as root?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me



Re: dumper: FATAL must be run setuid root to communicate correctly

2000-11-21 Thread Blohm, Matthias (init)



Thanks for 
helping,
but the other 
Problem I have is that following :
--
FAILURE AND STRANGE DUMP SUMMARY: 
fileserer1 /usr/local/cvsroot lev 0 FAILED 
[fileserver1: [hostfileserver1.domain.com: port 2107 not secure] 
fileserver1 /home lev 0 FAILED 
[fileserver1: [host fileserver1.domain.com: port 2107 not secure] 
fileserver1 /etc lev 0 FAILED 
[fileserver1: [host fileserver1.domain.com: port 2107 not secure]
---
Did anybody the 
reason.
Thanks in 
advance
Matthias


RE: Problem with Amcheck

2000-11-21 Thread Bort, Paul
Title: RE: Problem with Amcheck





The part of this that concerns me is the status bits BOT (beginning of tape) and DR_OPEN (door open) being on at the same time. On my 8505, DR_OPEN means that there is no tape in the drive, and if there is no tape, how can it be at the beginning? 

I would suggest a proper shutdown for the server, including switching off the power. While the server is off, switch off all the external SCSI devices. Then turn the externals on one at a time, followed by the server. 

If it's still confused about the tape drive, my guess is that it's a hardware/firmware problem in the tape drive. 



-Original Message-
From: Shane T. Ferguson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 21, 2000 10:19 AM
To: Amanda-Users
Subject: Problem with Amcheck



Hi,


I have a strange problem with my backup system. Everything worked the other
day - until I rebooted the server. The system consists of Redhat 5.2,
amanda-2.4.1p1, Exabyte 8700.


Here is the output of mt status:


[bin@mail sbin]$ mt status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (4005):
BOT DR_OPEN IM_REP_EN


dmesg:


(scsi0) Adaptec AHA-2940A Ultra SCSI host adapter found at PCI 10/0
(scsi0) Narrow Channel, SCSI ID=7, 3/255 SCBs
(scsi0) Warning - detected auto-termination
(scsi0) Please verify driver detected settings are correct.
(scsi0) If not, then please properly set the device termination
(scsi0) in the Adaptec SCSI BIOS by hitting CTRL-A when prompted
(scsi0) during machine bootup.
(scsi0) Cables present (Int-50 NO, Ext-50 YES)
(scsi0) Downloading sequencer code... 419 instructions downloaded
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.2/3.2.4
 Adaptec AHA-2940A Ultra SCSI host adapter
scsi : 1 host.
 Vendor: EXABYTE Model: EXB-8505 Rev: 0051
 Type: Sequential-Access ANSI SCSI revision: 02
Detected scsi tape st0 at scsi0, channel 0, id 2, lun 0
(scsi0:0:2:0) Synchronous at 5.0 Mbyte/sec, offset 11.
scsi : 0 hosts.
st: Unloaded.


However, when I run Amcheck:


[bin@mail sbin]$ ./amcheck seascape
Amanda Tape Server Host Check
-
/var/amanda/spool: 6608043 KB disk space available, that's plenty.
insert tape into slot 11 and press return


It appears not to detect a tape in the drive (any tape i put in there). All
the tapes are labeled correctly (recently been used). I don't know if I
might have a hardware problem or an amanda configuration problem.


The backup system wasn't configured by me -- it was already setup when I
took over the position. Any suggestions appreciated.



Shane









Re: Can DLT7000 inter-operate with DLT4000?

2000-11-21 Thread Bill Carlson

On Tue, 21 Nov 2000, David McCall wrote:

 I've receintly upgraded from the 20/40 to the 40/80.
 backward read compatability is fine, however, you can NOT relabel the
 80 gig tapes that were previously labeled in 40 gig mode.  The tapes need
 to be bulk erased 1st.  I tried bulk erasing with the most powerful
 magnetic field we had in the media dept. to no avail.  Amanda still
 read the labels.


A testament to the use of DLT!

From what I remember during my research on DLT4000 vs DLT7000, the drive
lays down some tracks that specify the media and format.

In order to get a newer drive to write in older format, you first had to
get it "formatted" in the older format. In amanda terms, that would mean
labelling it in the DLT4000.

Quantum's site would have the best information, but make sure to verify it
all works as advertised before relying on it.

I seem to remember there being a way to get tapes setup for 20/40 to be
written at 35/70, but I can't remember if that was using a specific
software package or just using the certain buttons on the drive.

HTH,

Bill Carlson
-- 
Systems Programmer[EMAIL PROTECTED]|  Opinions are mine,
Virtual Hospital  http://www.vh.org/|  not my employer's.
University of Iowa Hospitals and Clinics|




Re: dumper: FATAL must be run setuid root to communicate correctl y

2000-11-21 Thread Alexandre Oliva

On Nov 21, 2000, "Blohm, Matthias (init)" [EMAIL PROTECTED] wrote:

   fileserver1 /home lev 0 FAILED [fileserver1: [host
 fileserver1.domain.com: port 2107 not secure]

 Did anybody the reason.

At least planner, dumper and amcheck must be setuid-root.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me



RE: Problem with Amcheck

2000-11-21 Thread Shane T. Ferguson

I did a full shutdown of the server and the devices as you mentioned --
still having the same problem. However, I do have an Exabyte 8700 tape drive
and this is what is detected:

Nov 21 12:29:02 mail kernel:   Vendor: EXABYTE   Model: EXB-8505
Rev: 0051
Nov 21 12:29:02 mail kernel:   Type:   Sequential-Access
ANSI SCSI revision: 02
Nov 21 12:29:04 mail kernel: Detected scsi tape st0 at scsi0, channel 0, id
2, lun 0
Nov 21 12:29:04 mail kernel: (scsi0:0:2:0) Synchronous at 5.0 Mbyte/sec,
offset 11.

My tapetype in the amanda.conf file is set to 8700 parameters:

tapetype EXB-8700

define tapetype EXB-8700 {
comment "Exabyte EXB-8700 drive"
length 7000 mbytes
filemark 48 kbytes
speed 575 kbytes
}

I also have my symbolic link between /dev/tape and /dev/nst0 -- notice above
it detects scsi tape st0 (not nst0) -- would this be an issue?

Shane

-Original Message-
From: Bort, Paul [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 21, 2000 12:08 PM
To: 'Shane T. Ferguson'; Amanda-Users
Subject: RE: Problem with Amcheck


The part of this that concerns me is the status bits BOT (beginning of tape)
and DR_OPEN (door open) being on at the same time. On my 8505, DR_OPEN means
that there is no tape in the drive, and if there is no tape, how can it be
at the beginning?
I would suggest a proper shutdown for the server, including switching off
the power. While the server is off, switch off all the external SCSI
devices. Then turn the externals on one at a time, followed by the server.
If it's still confused about the tape drive, my guess is that it's a
hardware/firmware problem in the tape drive.


-Original Message-
From: Shane T. Ferguson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 21, 2000 10:19 AM
To: Amanda-Users
Subject: Problem with Amcheck


Hi,
I have a strange problem with my backup system. Everything worked the other
day - until I rebooted the server. The system consists of Redhat 5.2,
amanda-2.4.1p1, Exabyte 8700.
Here is the output of mt status:
[bin@mail sbin]$ mt status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (4005):
 BOT DR_OPEN IM_REP_EN
dmesg:
(scsi0) Adaptec AHA-2940A Ultra SCSI host adapter found at PCI 10/0
(scsi0) Narrow Channel, SCSI ID=7, 3/255 SCBs
(scsi0) Warning - detected auto-termination
(scsi0) Please verify driver detected settings are correct.
(scsi0) If not, then please properly set the device termination
(scsi0) in the Adaptec SCSI BIOS by hitting CTRL-A when prompted
(scsi0) during machine bootup.
(scsi0) Cables present (Int-50 NO, Ext-50 YES)
(scsi0) Downloading sequencer code... 419 instructions downloaded
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.2/3.2.4
   Adaptec AHA-2940A Ultra SCSI host adapter
scsi : 1 host.
  Vendor: EXABYTE   Model: EXB-8505  Rev: 0051
  Type:   Sequential-Access  ANSI SCSI revision: 02
Detected scsi tape st0 at scsi0, channel 0, id 2, lun 0
(scsi0:0:2:0) Synchronous at 5.0 Mbyte/sec, offset 11.
scsi : 0 hosts.
st: Unloaded.
However, when I run Amcheck:
[bin@mail sbin]$ ./amcheck seascape
Amanda Tape Server Host Check
-
/var/amanda/spool: 6608043 KB disk space available, that's plenty.
insert tape into slot 11 and press return
It appears not to detect a tape in the drive (any tape i put in there). All
the tapes "are" labeled correctly (recently been used). I don't know if I
might have a hardware problem or an amanda configuration problem.
The backup system wasn't configured by me -- it was already setup when I
took over the position. Any suggestions appreciated.


Shane




Re: Can DLT7000 inter-operate with DLT4000?

2000-11-21 Thread John R. Jackson

I seem to remember there being a way to get tapes setup for 20/40 to be
written at 35/70, but I can't remember if that was using a specific
software package or just using the certain buttons on the drive.

I recently converted a bunch of tapes from DLT4000 (20/40) to DLT7000
(35/50).  The steps were:

  * Load the tape and wait for it to stop blinking.

  * Use the Select button on the front to enable density override and
change it to 35 or 35+compressed.

  * Run amlabel on the tape.  This was on Solaris.  I don't know if
that matters, i.e. whether it was just too dumb to send SCSI commands
that would have changed the density back or whether the button has
the final authority.  My guess is that the button wins.

I've also been able to fully process DLT4000 written tapes on the DLT7000.
I've never tried (and probably wouldn't trust) writing a DLT4000 format
on a DLT7000 and reading it on a DLT4000.

Bill Carlson

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



Re: dumper: FATAL must be run setuid root to communicate correctl y

2000-11-21 Thread John R. Jackson

At least planner, dumper and amcheck must be setuid-root.

Here's the complete list:

  -rwsr-x---   1 root backup244676 Nov  3 14:41 libexec/calcsize
  -rwsr-x---   1 root backup803996 Nov  3 15:17 libexec/dumper
  -rwsr-x---   1 root backup233356 Nov  3 14:41 libexec/killpgrp
  -rwsr-x---   1 root backup944400 Nov  3 15:17 libexec/planner
  -rwsr-x---   1 root backup231064 Nov  3 14:41 libexec/rundump
  -rwsr-x---   1 root backup231900 Nov  3 14:41 libexec/runtar
  -rwsr-x---   1 root backup953364 Nov  3 15:18 sbin/amcheck

Alexandre Oliva

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



Re: Problem with Amcheck

2000-11-21 Thread John R. Jackson

... notice above
it detects scsi tape st0 (not nst0) -- would this be an issue?

No.

What happens if you stick an Amanda tape in the drive and do this:

  $ mt -f /dev/nst0 rewind
  $ dd if=/dev/nst0 bs=32k

You should see the (ASCII) Amanda label.

Shane

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



Re: Problem with Amcheck

2000-11-21 Thread Christoph Scheeder

Hi,
no, that won't be an issu, it is completly normal for linux.
it always reports scsi-Tapes as st[0-x].
how long is the external cable connected?


"Shane T. Ferguson" schrieb:
[]
 I also have my symbolic link between /dev/tape and /dev/nst0 -- notice above
 it detects scsi tape st0 (not nst0) -- would this be an issue?
 
 Shane




RE: Problem with Amcheck

2000-11-21 Thread Shane T. Ferguson

Looks like a hardware problem. Is there anything else I can check before
coming to this conclusion?

[bin@mail sbin]$ mt -f /dev/nst0 rewind
/dev/nst0: Input/output error




-Original Message-
From: John R. Jackson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 21, 2000 1:13 PM
To: Shane T. Ferguson
Cc: Bort, Paul; Amanda-Users
Subject: Re: Problem with Amcheck 


... notice above
it detects scsi tape st0 (not nst0) -- would this be an issue?

No.

What happens if you stick an Amanda tape in the drive and do this:

  $ mt -f /dev/nst0 rewind
  $ dd if=/dev/nst0 bs=32k

You should see the (ASCII) Amanda label.

Shane

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




RE: Backing up Oracle database

2000-11-21 Thread Tuthill, Ed

I'm putting the finishing touches this week on a perl script
that handles Oracle database hot backups (to keep the database
up and running 24/7).  It's very much like the tcl script John
Jackson wrote, but uses the Expect perl module to interact with
the database.

The script essentially backs up all of the tablespaces, control
files, and config files to a spare partition set up specifically
for this purpose.  This partition is then set to be backed up
with Amanda, along with all the regular partitions on the
system  (e.g., /usr, /var, etc.).

So if you'd like to look at a perl version of this, let me know
and I can ship a copy your way.


 -Original Message-
 From: Fredrik Persson P (QRA) 
 [mailto:[EMAIL PROTECTED]]
 Sent: Monday, November 20, 2000 8:46 AM
 To: '[EMAIL PROTECTED]'
 Subject: RE: Backing up Oracle database
 
 
 
   [Fredrik Persson P (QRA)]  Please read the entire mail! 
 In the end, I'm coming to a conclusion that
   probably obsoletes a lot of the previous junk that I 
 wrote. I've been writing this email all day and 
   I've become wiser along the day too...
 
  I've been assigned the task to back up an Oracle database 
 w/ amanda. I'm
  also told (by the db administrator) that a have to read 
 the files under /u02
  (a directory in the root of the file hierarchy) in a 
 certain order. 
  
  Ummm, that's very odd.  I've talked with my Oracle admin 
 and we're not
  sure what it is you're trying to do here.  Could you elaborate?
  
   [Fredrik Persson P (QRA)]  Absolutely! Our main concern 
 seems to be that the
   database must operate 24/7. The scheme that we thought 
 up was to run the "begin
   backup" command on all tablespaces before amanda starts 
 her work. When she's
   finished, the "end backup" command is run on all 
 tablespaces. When all the tablespaces
   are brought "back into action", the command ALTER 
 SYSTEM SWITCH LOGFILE is issued,
   to create a new ARCHIVELOG file, even thought the old 
 one might not be "full". 
 
   To restore the contents of the db, we first bring the 
 tablespaces back, and then apply
   the archivelog file to them. Now, there seems to be a 
 file called the "control file". If this
   file is backed up before the tablespaces, and the 
 tablespaces are altered during backup,
   we cannot restore the system. The control file is out 
 of date and we get an error message
   similar to "control file older than tablespace". Can't 
 recall the exact words, but that's what 
   it means.
 
   So, what I want to do is to backup the tablespaces 
 first, and the control file after that. That's
   why I need to tell amanda to do things in a certain order.
 
  Also, the way we back up our Oracle system is to dump it to 
 a scratch disk
  area and then let Amanda back that up.  And yes, we've done 
 restores :-).
  And they even worked :-).
  
   [Fredrik Persson P (QRA)]  Are you running 24/7? If so, 
 how do you deal with the issue
   of changes in the db during file transfer? Do you use 
 raw partitions or does Oracle run on top
   of a file system?
 
  The scripts we use are at:
  
ftp://gandalf.cc.purdue.edu/dbbackup.*
  
   [Fredrik Persson P (QRA)]  That link didn't work. Did 
 you mean ftp://gandalf.cc.purdue.edu/pub/amanda/dbbackup.*
 
  Is there a way to tell Amanda this?
  
  If this really ends up being the way you need to do this, I 
 have some
  hacks that I think would work.  But let's make sure you're 
 headed down
  the right path first.
  
   [Fredrik Persson P (QRA)]  After spending the day 
 pondering this issue, I think we've come to the conclusion that 
   we'll copy the db files to a temp storage, and then 
 backup them from there as if they were regular files.
 
   This is your approach too. I'd say it's a good one. 
 Minimizes db backup time and gives us control 
   over the order when storing db files. 
 
   I've browsed your scripts. Are those GPL'ed or 
 something similar? Right now, we're using our own scripts
   that can be said to be stripped versions of yours. 
 However, I might be interested in your stuff later.
 
   Thanks for your help! Using a temp storage was pretty smart.
 
   /Fredrik Persson
 



RE: Problem with Amcheck

2000-11-21 Thread Bort, Paul
Title: RE: Problem with Amcheck





/dev/st0 is the first SCSI tape. /dev/nst0 is the same device, without the 'feature' of automatic rewind after each close(). AMANDA writes multiple images to one tape, so automatic rewinds would be problematic. Having two logical device names pointing to the same drive makes it easy for programs to use the drive as they need to.

-Original Message-
From: Christoph Scheeder [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 21, 2000 12:17 PM
To: Amanda-Users
Subject: Re: Problem with Amcheck



Hi,
no, that won't be an issu, it is completly normal for linux.
it always reports scsi-Tapes as st[0-x].
how long is the external cable connected?



Shane T. Ferguson schrieb:
[]
 I also have my symbolic link between /dev/tape and /dev/nst0 -- notice above
 it detects scsi tape st0 (not nst0) -- would this be an issue?
 
 Shane






Re: Can DLT7000 inter-operate with DLT4000?

2000-11-21 Thread David McCall

no button luxuries on the ADIC 40/80 unit
just an unload button.

"John R. Jackson" wrote:

 I seem to remember there being a way to get tapes setup for 20/40 to be
 written at 35/70, but I can't remember if that was using a specific
 software package or just using the certain buttons on the drive.

 I recently converted a bunch of tapes from DLT4000 (20/40) to DLT7000
 (35/50).  The steps were:

   * Load the tape and wait for it to stop blinking.

   * Use the Select button on the front to enable density override and
 change it to 35 or 35+compressed.

   * Run amlabel on the tape.  This was on Solaris.  I don't know if
 that matters, i.e. whether it was just too dumb to send SCSI commands
 that would have changed the density back or whether the button has
 the final authority.  My guess is that the button wins.

 I've also been able to fully process DLT4000 written tapes on the DLT7000.
 I've never tried (and probably wouldn't trust) writing a DLT4000 format
 on a DLT7000 and reading it on a DLT4000.

 Bill Carlson

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


begin:vcard 
n:McCall;David
tel;cell:707-592-6056
tel;home:707-792-0482
tel;work:707-664-3099
x-mozilla-html:FALSE
url:http://veronica.sonoma.edu/
org:Sonoma State University;Information Technology/Computer Operations
adr:;;1801 E. Cotati Avenue;Rohnert Park;California;94928-3609;California
version:2.1
email;internet:[EMAIL PROTECTED]
title:Operating Systems Analyst
x-mozilla-cpt:;1
fn:David McCall
end:vcard



Re: bzip2 support?

2000-11-21 Thread John R. Jackson

I can now rest in peace knowing that my backups will not be destroyed
by one errant bit :-)

As long as you're using GNU tar, which I realize you are.  But just to
make sure everyone else understands, system dump programs may or may
not be so amused with a missing chunk of data.  I've seen both amazing
ability to recover and core dumps at the slightest whiff of a problem.

...  Before
amanda, I used my tape drive's hardware compression, but that doesn't
seem to quite play nicely with amanda.

I use hardware compression.  Why do you think it's a problem?

... you can use wrappers around the compression program and
let them decide, for instance ...
How would such a wrapper work, since there's still no way to vary how
it's called per-filesystem?

I didn't think that all the way through.  I guess you'd probably do the
wrapper around GNU tar, tell Amanda to **not** compress and have the
wrapper decide what to do since it is given the file system.  That would
have issues during a restore, though, since Amanda doesn't realize it's
really compressed and would not decompress it.

Or I guess the GNU tar wrapper could leave a flag for the compression
wrapper saying what file system was being done, then Amanda would not
be lied to.

All of which is pretty icky and not worth pursuing.  Effort would be
better spent implementing (and finding :-) the FILTER-API.

John Goerzen

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



RE: Problem with Amcheck

2000-11-21 Thread Bort, Paul
Title: RE: Problem with Amcheck 





Check to make sure the devices are set up correctly. For example, here's what I get from ls -l /dev/*st0:


crw-rw 2 root disk 9, 128 May 5 1998 nst0
crw-rw 1 root disk 9, 0 May 5 1998 st0


If that looks right, It's time to suspect the hardware. Do you have another one you can swap for it? 


-Original Message-
From: Shane T. Ferguson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 21, 2000 12:20 PM
To: [EMAIL PROTECTED]
Cc: Amanda-Users
Subject: RE: Problem with Amcheck 



Looks like a hardware problem. Is there anything else I can check before
coming to this conclusion?


[bin@mail sbin]$ mt -f /dev/nst0 rewind
/dev/nst0: Input/output error





-Original Message-
From: John R. Jackson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 21, 2000 1:13 PM
To: Shane T. Ferguson
Cc: Bort, Paul; Amanda-Users
Subject: Re: Problem with Amcheck 



... notice above
it detects scsi tape st0 (not nst0) -- would this be an issue?


No.


What happens if you stick an Amanda tape in the drive and do this:


 $ mt -f /dev/nst0 rewind
 $ dd if=/dev/nst0 bs=32k


You should see the (ASCII) Amanda label.


Shane


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





RE: Problem with Amcheck

2000-11-21 Thread Shane T. Ferguson

Hi,
no, that won't be an issu, it is completly normal for linux.
it always reports scsi-Tapes as st[0-x].
how long is the external cable connected?

The cable is only a few feet in length. 




No Subject

2000-11-21 Thread Veasey

unsubscribe [EMAIL PROTECTED]

Veasey Manley
System Administrator
Search123.com
818.597.4799



Re: Problem with Amcheck

2000-11-21 Thread John R. Jackson

Looks like a hardware problem.  ...

That would be my conclusion as well, or else the kernel confused about
something.

Is there anything else I can check before
coming to this conclusion?

The usual suspects and techniques:

  * cables seated properly.

  * proper termination (not too much, not too little, just right ;-).

  * controller card seated properly.

  * replace the cable(s).

  * disconnect everything except the tape drive from the SCSI bus.

  * proper power grounding.

  * take the drive to another machine and try it there.

  * etc, ad infinitum.

Shane

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



RE: Problem with Amcheck

2000-11-21 Thread Shane T. Ferguson
Title: RE: Problem with Amcheck



Strange that a hardware problem would occur only after 
rebooting the server (or perhaps coincidence *shrugs*). This was actually a new 
tape drive that was sent to us from Exabyte after we shipped back a damaged one 
few months back.

Everything seems to look ok here:

[bin@mail sbin]$ ls -l 
/dev/*st0crw-rw 1 bin 
disk 9, 128 May 5 1998 
/dev/nst0crw-rw 1 bin 
disk 9, 0 May 5 1998 
/dev/st0

Thanks 
for the help!

Shane


  -Original Message-From: Bort, Paul 
  [mailto:[EMAIL PROTECTED]]Sent: Tuesday, November 21, 2000 1:26 
  PMTo: 'Shane T. Ferguson'; [EMAIL PROTECTED]Cc: 
  Amanda-UsersSubject: RE: Problem with Amcheck 
  Check to make sure the devices are set up correctly. For 
  example, here's what I get from ls -l /dev/*st0: 
  crw-rw 2 root 
  disk 9, 128 May 5 1998 
  nst0 crw-rw 1 
  root disk 
  9, 0 May 5 1998 st0 
  If that looks right, It's time to suspect the hardware. Do you 
  have another one you can swap for it? 
  -Original Message- From: Shane 
  T. Ferguson [mailto:[EMAIL PROTECTED]] 
  Sent: Tuesday, November 21, 2000 12:20 PM To: [EMAIL PROTECTED] Cc: Amanda-Users 
  Subject: RE: Problem with Amcheck 
  Looks like a hardware problem. Is there anything else I can 
  check before coming to this conclusion? 
  [bin@mail sbin]$ mt -f /dev/nst0 rewind /dev/nst0: Input/output error 
  -Original Message- From: John 
  R. Jackson [mailto:[EMAIL PROTECTED]] 
  Sent: Tuesday, November 21, 2000 1:13 PM To: Shane T. Ferguson Cc: Bort, Paul; 
  Amanda-Users Subject: Re: Problem with Amcheck 
  
  ... notice above it detects 
  scsi tape st0 (not nst0) -- would this be an issue? 
  No. 
  What happens if you stick an Amanda tape in the drive and do 
  this: 
   $ mt -f /dev/nst0 rewind  
  $ dd if=/dev/nst0 bs=32k 
  You should see the (ASCII) Amanda label. 
  Shane 
  John R. Jackson, Technical Software Specialist, 
  [EMAIL PROTECTED] 


Re: Problem with Amcheck

2000-11-21 Thread John R. Jackson

One other thing to check.  Make sure any (e.g. DIP) switches that
control drive options didn't accidentally get flipped or moved to
half-on/half-off.  They may have been wrong for a while and just now
took effect because of the reset.

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



Mandrake 7.2

2000-11-21 Thread Joshua E Warchol

Hows this for funny, the only person in the whole company who can't get his 
workstation to backup is the backup operator! :-)

Basically I installed Mandrake 7.2 a few weeks back, and got it nicely tweaked,
then went to setup the amanda clinet. We're using 2.4.2. Mandrake 7.2 uses
xinetd. I've configured /etc/xinetd.d/amanda as follows:

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

The amdump email states:

FAILURE AND STRANGE DUMP SUMMARY:
  hound.dsl. /boot lev 0 FAILED [disk /boot offline on hound.dsl.net?]
  hound.dsl. /usr lev 0 FAILED [disk /usr offline on hound.dsl.net?]
  hound.dsl. /home lev 0 FAILED [disk /home offline on hound.dsl.net?]
  hound.dsl. / lev 0 FAILED [disk / offline on hound.dsl.net?]


And /tmp/amanda/sendsize.debug says

sendsize: debug 1 pid 19480 ruid 501 euid 501 start time Tue Nov 21 00:59:13 2000
/usr/local/libexec/sendsize: version 2.4.2-19991216-beta1
calculating for amname '/', dirname '/'
sendsize: getting size via dump for / level 0
sendsize: running "/sbin/dump 0Ssf 1048576 - /dev/hda6"
running /usr/local/libexec/killpgrp
cannot execute /usr/local/libexec/killpgrp: Permission denied
/dev/hda6: Permission denied while opening filesystem
.

Any ideas?

-- 

Joshua Warchol



Re: Backing up Oracle database

2000-11-21 Thread John R. Jackson

   Are you running 24/7? If so, how do you deal  with the issue
   of changes in the db during file transfer?  ...

Yes, we're running 24/7.  And it's my understand the technique the script
we use employs deals with that.

 The scripts we use are at:
 
   ftp://gandalf.cc.purdue.edu/dbbackup.*
 
   [Fredrik Persson P (QRA)]  That link didn't work. Did you mean ftp://ga
ndalf.cc.purdue.edu/pub/amanda/dbbackup.*

Hey!  At least I got the host name right.  The rest is **supposed** to
be an adventure.  :-)

Yes, what you found was what I meant to point you at.

   I've browsed your scripts. Are those GPL'ed or something
similar?  ...

They say pretty clearly they are copyright Purdue University but freely
redistributable.

And don't anybody bother starting a war with me about free software,
copyrights, copylefts, GPL's or anything else.  I'm not interested.

   /Fredrik Persson

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



Re: Mandrake 7.2

2000-11-21 Thread John R. Jackson

Hows this for funny, the only person in the whole company who can't get his 
workstation to backup is the backup operator! :-)

Don't you just hate that? :-) :-)

...
  user= backup
  group   = disk
...
The amdump email states:

What does amcheck have to say?

And /tmp/amanda/sendsize.debug says
...
running /usr/local/libexec/killpgrp
cannot execute /usr/local/libexec/killpgrp: Permission denied

Not sure about this one.  What are the modes on killpgrp?  Can backup:disk
get at it?  Is it NFS mounted and if so is setuid allowed in the NFS
mount options?

/dev/hda6: Permission denied while opening filesystem

In any case, this is the real problem.  What are the modes and ownership
of /dev/*hda6?

Joshua Warchol

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



Re: Filesystem offline in cluster ENV

2000-11-21 Thread John R. Jackson

When I'm backing a filesytem that's part of SUN cluster ENV i 'm getting the
message:
filessytem offline and it's not getting backed up.

What does amcheck say?  And please post all of the output, not a summary.

What's in /tmp/amanda/sendsize*debug and sendbackup*debug on the client?

Ruksana

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



Re: linux filesize limit and amanda?

2000-11-21 Thread Yura Pismerov

David Wolfskill wrote:
 
 Date: Mon, 20 Nov 2000 17:52:54 -0500
 From: Michael Lea [EMAIL PROTECTED]
 
 Sorry if this is covered elsewhere, but I couldn't find anything about it.
 My understanding of the way that amanda works is that it streams the
 dump file to the holding disk on the tapehost, and then that gets written to
 the tape.  In my case, an x86 linux box is the tapehost, and it backs up
 some solaris boxes.  So my question is, what happens when it's backing
 up a filesystem that is larger than the 2gb filesize limit?  I have run
 into that problem trying to restore a large solaris filesystem dump, how
 does it backup large filesystems like that?
 
 That's what the "chunksize" specification (for a given holding disk) is
 for in the amanda.conf -- to break up the backup image into pieces that
 are manageable on the OS  file system in question.  (The chunks get
 concatenated when the image is written to tape, so there is -- for now,
 anyway -- no way to tell how many chunks the image was originally
 written in.  This is a Good Thing, because that way, the "chunking"
 cannot interfere with the recovery process.)


I think the oriiginal question was rather regarding restore of
a large FS on Linux box. Normally you dont have to worry about that
because
you don't have to restore the backup image - you just pipe the stream
from the
tape to tar program that extract files on the fly.
The only problem I can see here is large files (if any) inside of the
archive. Then it will be a problem and you only can do it on foreign
solaris filesystem
by piping the stream to there through, for example,  ssh.
Also you can try to find unofficial Linux kernel patch for large files
support.
Some server hardware vendors (Dell for example) ship RH Linux CD with
the patch applied.
Also RH Linux Enterprise has it in place too.

Hope this helps...


 
 Cheers,
 david
 --
 David Wolfskill  [EMAIL PROTECTED]   UNIX System Administrator
 Desk: 650/577-7158   TIE: 8/499-7158   Cell: 650/759-0823

-- 

Yuri Pismerov, TUCOWS.COM INC.  (416) 535-0123  ext. 352
 S/MIME Cryptographic Signature


RE: Dumping the second cycle?

2000-11-21 Thread Thomas Kleymann

 Indeed, the mail report suggests that the next dump should go
 onto the first
 tape. I had assumed that it would suffice to insert the first
 tape and the
 new dump would simply overwrite the dump from the first cycle. No? ...

 That's what should happen.

Thanks for clarifying this. I am still an Amanda novice.


 In fact,
 when I try to do this, my Sun DLT 4000 simply ejects the tape and amdump
 requests that I insert a tape in the next slot (1).  ...

 What happens when you run amcheck?  And please post all the actual
 messages, not a summary.


That is somewhat worrying:

**
bash-2.02$ amcheck Daily
Amanda Tape Server Host Check
-
/dumps/amanda: 3018523 KB disk space available, that's plenty.
amcheck-server: slot 0: not an amanda tape
insert tape into slot 1 and press return
**

The same happens when I insert the second tape from week 1. Worried that I
might not actually be able to restore any data, I checked the status usind
amadmin Daily info. This revealed that all the data is on tape 4 and 5. With
tape 4, using amcheck I obtain:

**
amcheck-server: slot 1: date 20001117 label DailySet104 (active tape)
**

So, I presume that I still have all the data. I just do not understand what
happened to tape 1 (and 2). I guess it would be safe to just relabel them,
but I am still confused. Any suggestions on what is going on?

--Thomas

BTW, on the topic of supplying all the output by email: does anyone know how
to copy and paste text from an Exceed X server to my Windows2000
applications?




Re: bzip2 support?

2000-11-21 Thread lamont

On 21 Nov 2000, John Goerzen wrote:
 [EMAIL PROTECTED] writes:
   Probably.  That's why there's the holding disk, right?  I'm backing up
   some machines over VPN Internet connection anyway, so this may
   actually speed that up.  The local server is an Alpha :-)
  
  okay then...  i'd suggest you grep the sources for "gz" if you're
  planning on doing this.  last time i checked there was some hardcoded
  stuff in there... 
 
 There was also COMPRESS_EXTENSION.  A bit of hacking to ./configure
 made it work with bzip2!  All I had to do was gunzip and then bzip2
 the *.gz files on the tape server.
 
 I can now rest in peace knowing that my backups will not be destroyed
 by one errant bit :-)

are you sure?  bzip2 would have to produce a file that was perfectly 
aligned other than the corrupted block of data.  if the corrupted block of
data can change size then the alignment will be off and tar will puke (at
least that's what happened to tar when i was testing it). 




Re: Can DLT7000 inter-operate with DLT4000?

2000-11-21 Thread Tim Janes


Hi,

Here is my understanding of the compatibility issues.

With the Quantum range of DLT's (2000, 2000XT, 4000, 7000  8000) there is
complete read  write backward compatibility. 

Any drive will read its native capacity and any lower capacity without
problem. 

On write if you are appending to a tape with existing data on it
the drive will write at the density already on the tape. 

If you are writing at BOM (irrespective of any pre-existing data on the
tape) the default is the native density of the tape but this can be
changed to be any lower density by a command from the host, or using the
front panel controls of the drive after loading the tape.

On Tru64 there is a mapping (defined in ddr.dbase??) between the
write density and the device name. ie /dev/ntape/tape0 will be the
default density of your drive but /dev/ntape/tape0l could be fixed at
DLT4000 density.

There is a new breed of lower cost DLT drives recently introduced that
have 40/80Gbyte capacity on type IV tapes (I think that they are called
Benchmark DLT1) that have limited backward capacity. They can read DLT4000
tapes but have no write compatibility and tapes previously written to in a
DLT4000 need bulk erasing before they be used for write in a DLT1. They
also only have a 1.5Mbyte/sec transfer rate compared with 6Mbytes/sec of a
Quantum DLT8000.
 
I think that David McCall must have one of these drives. 

I have seen a pointer to a company offering a bulk erase service. I can
probably find it again if anyone needs it.

Cheers

Tim Janes.









Re: Can DLT7000 inter-operate with DLT4000?

2000-11-21 Thread David McCall

here's my stats from last night full run:

 Total   Full  Daily
      
Estimate Time (hrs:min)0:04
Run Time (hrs:min)14:27
Dump Time (hrs:min)   72:11  72:11   0:00
Output Size (meg)   50257.950257.90.0
Original Size (meg) 50257.950257.90.0
Avg Compressed Size (%) -- -- --
Filesystems Dumped   69 69  0
Avg Dump Rate (k/s)   198.0  198.0--

Tape Time (hrs:min)4:51   4:51   0:00
Tape Size (meg) 50260.150260.10.0
Tape Used (%)  64.3   64.30.0
Filesystems Taped69 69  0
Avg Tp Write Rate (k/s)  2948.1 2948.1--




kinda says almost 3MByte/sec doesn't it?

Tim Janes wrote:

 Hi,

 Here is my understanding of the compatibility issues.

 With the Quantum range of DLT's (2000, 2000XT, 4000, 7000  8000) there is
 complete read  write backward compatibility.

 Any drive will read its native capacity and any lower capacity without
 problem.

 On write if you are appending to a tape with existing data on it
 the drive will write at the density already on the tape.

 If you are writing at BOM (irrespective of any pre-existing data on the
 tape) the default is the native density of the tape but this can be
 changed to be any lower density by a command from the host, or using the
 front panel controls of the drive after loading the tape.

 On Tru64 there is a mapping (defined in ddr.dbase??) between the
 write density and the device name. ie /dev/ntape/tape0 will be the
 default density of your drive but /dev/ntape/tape0l could be fixed at
 DLT4000 density.

 There is a new breed of lower cost DLT drives recently introduced that
 have 40/80Gbyte capacity on type IV tapes (I think that they are called
 Benchmark DLT1) that have limited backward capacity. They can read DLT4000
 tapes but have no write compatibility and tapes previously written to in a
 DLT4000 need bulk erasing before they be used for write in a DLT1. They
 also only have a 1.5Mbyte/sec transfer rate compared with 6Mbytes/sec of a
 Quantum DLT8000.

 I think that David McCall must have one of these drives.

 I have seen a pointer to a company offering a bulk erase service. I can
 probably find it again if anyone needs it.

 Cheers

 Tim Janes.


begin:vcard 
n:McCall;David
tel;cell:707-592-6056
tel;home:707-792-0482
tel;work:707-664-3099
x-mozilla-html:FALSE
url:http://veronica.sonoma.edu/
org:Sonoma State University;Information Technology/Computer Operations
adr:;;1801 E. Cotati Avenue;Rohnert Park;California;94928-3609;California
version:2.1
email;internet:[EMAIL PROTECTED]
title:Operating Systems Analyst
x-mozilla-cpt:;1
fn:David McCall
end:vcard



Re: Can DLT7000 inter-operate with DLT4000?

2000-11-21 Thread Tim Janes



On Tue, 21 Nov 2000, David McCall wrote:

 here's my stats from last night full run:
 
  Total   Full  Daily
       
 Estimate Time (hrs:min)0:04
 Run Time (hrs:min)14:27
 Dump Time (hrs:min)   72:11  72:11   0:00
 Output Size (meg)   50257.950257.90.0
 Original Size (meg) 50257.950257.90.0
 Avg Compressed Size (%) -- -- --
 Filesystems Dumped   69 69  0
 Avg Dump Rate (k/s)   198.0  198.0--
 
 Tape Time (hrs:min)4:51   4:51   0:00
 Tape Size (meg) 50260.150260.10.0
 Tape Used (%)  64.3   64.30.0
 Filesystems Taped69 69  0
 Avg Tp Write Rate (k/s)  2948.1 2948.1--
 
 
 
 
 kinda says almost 3MByte/sec doesn't it?
 

David,

Apologies, I was writing from memory, I have just looked up the data
sheet of the DLT1 and its transfer rate is 3Mbytes/sec uncompressed
6Mbytes/sec compressed.

The point I was trying to make is that there are two distinct 40/80Gbyte
tape drive. 

I have recently purchased purchased a Quantum DLT8000 in an Overland data
tape changer and have reused about 30 of our DLT4000 tapes at the higher
capacity without problems. Just doubled the capacity in amanda.conf and
put the tapes in as usual. All works as before but at the higher capacity,
no re-labelling or anything needed.

It is also in the DLT1's FAQ that media written in an incompatible format
must be degaussed before it can be written in a Benchmark DLT1.

This was the major reason I did not purchase a DLT1, replacing all our
media would have been far more expensive that purchasing a Quantum
DLT8000, and because of security reasons I am unable to send tapes off-site
for degaussing.

Regards

Tim.





dump failing but no errors during amcheck

2000-11-21 Thread Eric A. Sproul

Hi,
Got a new problem...

Backing up a FreeBSD 4.0 box, the client does not report any problems
during amcheck, but after the nightly run, the summary reports:

real.cho.c da0s1a lev 0 FAILED [could not connect to
real.cho.cstone.net]

It seems to connect fine during the check process?  Here's the only
oddity I could find among the debug files.

from sendbackup.debug:
/usr/local/libexec/amanda/sendbackup: got input request: DUMP da0s1a 0
1970:1:1:0:0:0 OPTIONS |;bsd-auth;index;
  parsed request as: program `DUMP' disk `da0s1a' lev 0 since
1970:1:1:0:0:0 opt `|;bsd-auth;index;'
  waiting for connect on 0, then 0, then 0
/usr/local/libexec/amanda/sendbackup: timeout on data port 0
/usr/local/libexec/amanda/sendbackup: timeout on mesg port 0
/usr/local/libexec/amanda/sendbackup: timeout on index port 0
sendbackup: pid 31332 finish time Tue Nov 21 02:34:04 2000

I'm not sure what those timeouts are.  Can someone help me understand?
Thanks,
Eric

-- 
Eric Sproul, Systems Administrator
Cornerstone Networks Inc. (http://www.cstone.net)
-
You're just jealous because the little voices only talk to me.



amrmtape mistake

2000-11-21 Thread David Lloyd


Someone I work with accidentally amrmtaped the wrong tape (number 10),
but immediately flushed what was in the holding disk to the correct tape
(number 15). Therefore I have the following situation:

* I have all of tape 10's data (but it may or may not have a header)
* I have the curinfo records that amrmtape saved

Now, how would I get this tape back into operation? Or is there no
way...

DL
-- 
Video killed the radio star!
 Video killed the radio star!
In my mind and in my car - we can't rewind
 We've gone too far



Re: Problem with Amcheck

2000-11-21 Thread Christoph Scheeder

Hi again,
I would do two things first:
1.) enable the termination on the adapter in the adapter-setup.
Sometimes automatic-termination mode does not do the expected.
2.) set the speed for all devices on this scsi-bus to 5MB/s,
and disable the ultra-mode-operation on this scsi-bus.
I remember reading somewhere that there are issus for the length
of scsi-cables and the operation in ultra-mode. 
Under some conditions you are limited to a total cable-lengt of
something around one meter or so, espacely if you have ultra-devices
(controler) and normal devices (tapedrive) mixed on one scsi-bus.
And try an external terminator. sometimes devices claim to do internal
termination, but in reality the don't do a good work on that.
Hope it helps.
Christoph

"Shane T. Ferguson" schrieb:
 
 Hi,
 no, that won't be an issu, it is completly normal for linux.
 it always reports scsi-Tapes as st[0-x].
 how long is the external cable connected?
 
 The cable is only a few feet in length.