Re: AMANDA reports no slots, but there ARE slots!

[Stefan G. Weichinger]

FL schrieb:
> 
> 
> On 3/6/07, *Stefan G. Weichinger* <[EMAIL PROTECTED]
> > wrote:
> 
> FL schrieb:
> > Thanks for getting back to me so quickly!
> 
> Why should I sleep at midnight? ;-)
> 
> 
> You too?

:)

> This is what I settled on as a first guess
> # my customized rule
> ID=="2:0:0:0", BUS=="scsi", SYSFS{vendor}=="EXABYTE ",   NAME="changer",
> OWNER="root", GROUP="tape", MODE="0660"
> 
> and it worked: I have a /dev/changer (I removed the symbolic link
> instruction in my setup file). I'm using the name changer since
>mtx uses it if it exists

right, ok.

>I wanted to try udev with new names, to see that the major and minor
> number assignments were correct (they were) and to avoid any potential
> conflicts
> 
> With /dev/sg1 renamed to /dev/changer in amanda.conf, I ran an amcheck
> against my configuration (one should always do this after changing the
> config):
> 
> [EMAIL PROTECTED]:/etc/init.d$ amcheck Daily
> Amanda Tape Server Host Check
> -
> Holding disk /home/amanda: 61798904 KB disk space available, using
> 60774904 KB
> slot 6: read label `Daily-13', date `20070221'
> NOTE: skipping tape-writable test
> Tape Daily-13 label ok
> Server check took 208.007 seconds
> 
> Amanda Backup Client Hosts Check
> 
> Client check: 1 host checked in 0.150 seconds, 0 problems found
> 
> (brought to you by Amanda 2.5.1p1 )
> [EMAIL PROTECTED]:/etc/init.d$
> 
> 
> So that worked. I'm not even sure that I needed to assert
> 
> modprobe sg
> 
> When I do this, I have:
> sh-3.1# ls -latrs sg*
> 0 crw-rw 1 root tape 21, 0 Mar  6 13:30 sg0
> 0 crw-rw 1 root tape 21, 1 Mar  6 13:30 sg1
> 0 crw-rw 1 root tape 21, 3 Mar  6 13:30 sg3
> sh-3.1#
> 
> so I see that my rule caused the reassignment of /dev/sg2 to /dev/changer
> 
> sh-3.1# ls -latrs changer
> 0 crw-rw 1 root tape 21, 2 Mar  6 13:30 changer
>  
> Now previously it was /dev/sg1
> 
> So if I wanted to fix sg1, I might have to write KERNEL="sg1" and for kicks
> I suppose I could add SYMLINK+="changer"
> 
> Anyway, I will spare the list my real-time fumbling, and thanks for
> being so helpful!
> AMANDA is a great program.

Glad that thinks worked out. Might be a nice thing to write as small
udev-related subsection for the HOWTOs ...

Greets, Stefan.

Re: AMANDA reports no slots, but there ARE slots!

[Lonny Selinger]

> Unfortunately, my system doesn't have sg_scan (perhaps I could install
> this).

There is another script you can use for rescanning devices on a SCSI interface
that works quite well. The output looks quite similar to that the sg_scan
script does. You can find it here:

http://www.garloff.de/kurt/linux/rescan-scsi-bus.sh

Not sure if it would help at but it's worked for me adding new devices
including having the dev nodes created even for devices that seemed to have
magically disappeared.

--
Lonny Selinger LPIC-1
-- 
"To mess up a Linux box, you need to work at it; to mess up your Windows box,
you just need to work ON it."

Re: AMANDA reports no slots, but there ARE slots!

[FL]

On 3/6/07, Stefan G. Weichinger <[EMAIL PROTECTED]> wrote:


FL schrieb:
> Thanks for getting back to me so quickly!

Why should I sleep at midnight? ;-)



You too?


And in my startup script, I have:
>
> modprobe sg
> chown root.tape /dev/sg0
> chown root.tape /dev/sg1  # moved from sg2 to sg1!!!
> chown root.tape /dev/sg2
> chown root.tape /dev/sg3
> if [ ! -h /dev/changer ]; then
> ln -s /dev/sg1 /dev/changer
> fi
>
> But this is not optimal. According to /proc/scsi/scsi
> I have this entry
>
> Host: scsi2 Channel: 00 Id: 00 Lun: 00
>   Vendor: EXABYTE  Model: LTO 1x7 2U   Rev: B005
>   Type:   Medium Changer   ANSI SCSI revision: 04

[...]

> So, after the most cursory reading of the documentation, I guess that I
want
>
> ID=="2:0:0:0" BUS=="scsi" SYSFS{vendor}=="EXABYTE "   NAME="changer"
>
> to identify the device and set the symbolic link (I also need to set the
> ownership and mode).

Looks OK, just try it with udevtest.

Why do you want that symbolic link?
Why not use "/dev/sg2" in your config?

But you may use it, sure.

Even better stuff: udev is also able to set the group:

I have (example):

# cat 10-udev.rules
# "chgrp tape" for the changer-robots
BUS=="scsi", KERNEL=="sg?", ATTR{model}=="SA100", GROUP="tape"

Stefan




This is what I settled on as a first guess

# my customized rule
ID=="2:0:0:0", BUS=="scsi", SYSFS{vendor}=="EXABYTE ",   NAME="changer",
OWNER="root", GROUP="tape", MODE="0660"

and it worked: I have a /dev/changer (I removed the symbolic link
instruction in my setup file). I'm using the name changer since
  mtx uses it if it exists
  I wanted to try udev with new names, to see that the major and minor
number assignments were correct (they were) and to avoid any potential
conflicts

With /dev/sg1 renamed to /dev/changer in amanda.conf, I ran an amcheck
against my configuration (one should always do this after changing the
config):

[EMAIL PROTECTED]:/etc/init.d$ amcheck Daily
Amanda Tape Server Host Check
-
Holding disk /home/amanda: 61798904 KB disk space available, using 60774904
KB
slot 6: read label `Daily-13', date `20070221'
NOTE: skipping tape-writable test
Tape Daily-13 label ok
Server check took 208.007 seconds

Amanda Backup Client Hosts Check

Client check: 1 host checked in 0.150 seconds, 0 problems found

(brought to you by Amanda 2.5.1p1)
[EMAIL PROTECTED]:/etc/init.d$


So that worked. I'm not even sure that I needed to assert

modprobe sg

When I do this, I have:
sh-3.1# ls -latrs sg*
0 crw-rw 1 root tape 21, 0 Mar  6 13:30 sg0
0 crw-rw 1 root tape 21, 1 Mar  6 13:30 sg1
0 crw-rw 1 root tape 21, 3 Mar  6 13:30 sg3
sh-3.1#

so I see that my rule caused the reassignment of /dev/sg2 to /dev/changer

sh-3.1# ls -latrs changer
0 crw-rw 1 root tape 21, 2 Mar  6 13:30 changer

Now previously it was /dev/sg1

So if I wanted to fix sg1, I might have to write KERNEL="sg1" and for kicks
I suppose I could add SYMLINK+="changer"

Anyway, I will spare the list my real-time fumbling, and thanks for being so
helpful!
AMANDA is a great program.

FL

Re: AMANDA reports no slots, but there ARE slots!

[FL]

Unfortunately, my system doesn't have sg_scan (perhaps I could install
this).
If my first reckless attempt to create a fixed device node for the changer
isn't
wrong, I'm trying this, based on the output from udevinfo:

ID=="2:0:0:0", BUS=="scsi", SYSFS{vendor}=="EXABYTE ",   NAME="changer",
OWNER="root", GROUP="tape", MODE="0660"

the hope is that I could refer to /dev/changer in amanda.conf and not have
to set
a symbolic link

The matching critera have to come from precisely one device section of the
udevinfo output (no doubt I've missed some crucial point)...

On 3/6/07, Jon LaBadie <[EMAIL PROTECTED]> wrote:


On Tue, Mar 06, 2007 at 04:09:42PM -0500, FL wrote:
> On 2/22/07, Stefan G. Weichinger <[EMAIL PROTECTED]> wrote:
> >
> After watching the trouble recur, I see that the device associated with
the
> changer SCSI device ID moved: it was /dev/sg2, today it is /dev/sg1. No
> changes were made to the Exabyte LTO-2 tape library  or to the SCSI card
(or
> anything else). So there is something I'm failing to understand about
udev,
> SCSI or the Exabyte.
>
> Perhaps during bootup I should attempt
>
> mtx -f /dev/sg0 status
> mtx -f /dev/sg1 status
>
> until I have a valid status, and link
> /dev/changer to that, then refer to /dev/changer in amanda.conf. That's
a
> workaround: somehow the device assigned to the changer moves on
occasion,
> after a reboot. Perhaps I should be referring to the changer device in
some
> other way (bus number, SCSI ID, lun...).

Does your system have sg_scan?  My FC4 does.  It would be a way of
enumerating your devices and possibly setting up udev rules to
create persistent names for the devices.

Here is a sample output on my system with a DDS3 drive + changer
id 5, lun 0+1, an LTO drive, and two usb disks.

[EMAIL PROTECTED] /]# sg_scan -i
/dev/sg0: scsi0 channel=0 id=5 lun=0
HPC1557AU610 [rmb=1 cmdq=0 pqual=0 pdev=0x1]
/dev/sg1: scsi0 channel=0 id=5 lun=1
HPC1557AU610 [rmb=1 cmdq=0 pqual=0 pdev=0x8]
/dev/sg2: scsi1 channel=0 id=4 lun=0
HPUltrium 1-SCSIE21V [rmb=1 cmdq=0 pqual=0 pdev=0x1]
/dev/sg3: scsi3 channel=0 id=0 lun=0 [em]
ST330083  1A3.03 [rmb=0 cmdq=0 pqual=0 pdev=0x0]
/dev/sg4: scsi4 channel=0 id=0 lun=0 [em]
ST330063  1A3.04 [rmb=0 cmdq=0 pqual=0 pdev=0x0]

--
Jon H. LaBadie  [EMAIL PROTECTED]
JG Computing
4455 Province Line Road(609) 252-0159
Princeton, NJ  08540-4322  (609) 683-7220 (fax)

Re: AMANDA reports no slots, but there ARE slots!

[Stefan G. Weichinger]

FL schrieb:
> Thanks for getting back to me so quickly!

Why should I sleep at midnight? ;-)

> And in my startup script, I have:
> 
> modprobe sg
> chown root.tape /dev/sg0
> chown root.tape /dev/sg1  # moved from sg2 to sg1!!!
> chown root.tape /dev/sg2
> chown root.tape /dev/sg3 
> if [ ! -h /dev/changer ]; then
> ln -s /dev/sg1 /dev/changer
> fi
> 
> But this is not optimal. According to /proc/scsi/scsi
> I have this entry
> 
> Host: scsi2 Channel: 00 Id: 00 Lun: 00
>   Vendor: EXABYTE  Model: LTO 1x7 2U   Rev: B005
>   Type:   Medium Changer   ANSI SCSI revision: 04

[...]

> So, after the most cursory reading of the documentation, I guess that I want
> 
> ID=="2:0:0:0" BUS=="scsi" SYSFS{vendor}=="EXABYTE "   NAME="changer"
> 
> to identify the device and set the symbolic link (I also need to set the
> ownership and mode).

Looks OK, just try it with udevtest.

Why do you want that symbolic link?
Why not use "/dev/sg2" in your config?

But you may use it, sure.

Even better stuff: udev is also able to set the group:

I have (example):

# cat 10-udev.rules
# "chgrp tape" for the changer-robots
BUS=="scsi", KERNEL=="sg?", ATTR{model}=="SA100", GROUP="tape"

Stefan

Re: AMANDA reports no slots, but there ARE slots!

[FL]

Thanks for getting back to me so quickly!

Here's the relevant data:
OS is debian linux
[EMAIL PROTECTED]:~$ uname -a
Linux Wilf 2.6.17 #4 SMP PREEMPT Wed May 10 13:53:45 CEST 2006 i686
GNU/Linux

Amanda version:
amadmin Daily version
build: VERSION="Amanda-2.5.1p1"
  BUILT_DATE="Wed Nov 29 02:15:07 CET 2006"
  BUILT_MACH="Linux intrepid 2.6.18-1-686 #1 SMP Fri Sep 29 16:25:40
UTC 2006 i686 GNU/Linux"
  CC="gcc"
  CONFIGURE_COMMAND="'./configure' '--prefix=/usr' '--bindir=/usr/sbin'
'--mandir=/usr/share/man' '--libexecdir=/usr/lib/amanda' '--enable-shared'
'--sysconfdir=/etc' '--localstatedir=/var/lib'
'--with-gnutar-listdir=/var/lib/amanda/gnutar-lists'
'--with-index-server=localhost' '--with-user=backup' '--with-group=backup'
'--with-bsd-security' '--with-amandahosts'
'--with-smbclient=/usr/bin/smbclient' '--with-debugging=/var/log/amanda'
'--with-dumperdir=/usr/lib/amanda/dumper.d'
'--with-tcpportrange=5,50100' '--with-udpportrange=840,860'
'--with-maxtapeblocksize=256' '--with-ssh-security'"
paths: bindir="/usr/sbin" sbindir="/usr/sbin"
  libexecdir="/usr/lib/amanda" mandir="/usr/share/man"
  AMANDA_TMPDIR="/tmp/amanda"
  AMANDA_DBGDIR="/var/log/amanda" CONFIG_DIR="/etc/amanda"
  DEV_PREFIX="/dev/" RDEV_PREFIX="/dev/" DUMP="/sbin/dump"
  RESTORE="/sbin/restore" VDUMP=UNDEF VRESTORE=UNDEF
  XFSDUMP="/sbin/xfsdump" XFSRESTORE="/sbin/xfsrestore"
  VXDUMP=UNDEF VXRESTORE=UNDEF
  SAMBA_CLIENT="/usr/bin/smbclient" GNUTAR="/bin/tar"
  COMPRESS_PATH="/bin/gzip" UNCOMPRESS_PATH="/bin/gzip"
  LPRCMD="/usr/bin/lpr" MAILER="/usr/bin/mail"
  listed_incr_dir="/var/lib/amanda/gnutar-lists"
defs:  DEFAULT_SERVER="localhost" DEFAULT_CONFIG="DailySet1"
  DEFAULT_TAPE_SERVER="localhost" HAVE_MMAP HAVE_SYSVSHM
  LOCKING=POSIX_FCNTL SETPGRP_VOID DEBUG_CODE
  AMANDA_DEBUG_DAYS=4 BSD_SECURITY RSH_SECURITY USE_AMANDAHOSTS
  CLIENT_LOGIN="backup" FORCE_USERID HAVE_GZIP
  COMPRESS_SUFFIX=".gz" COMPRESS_FAST_OPT="--fast"
  COMPRESS_BEST_OPT="--best" UNCOMPRESS_OPT="-dc"
sh-3.1#

And in my startup script, I have:

modprobe sg
chown root.tape /dev/sg0
chown root.tape /dev/sg1  # moved from sg2 to sg1!!!
chown root.tape /dev/sg2
chown root.tape /dev/sg3
if [ ! -h /dev/changer ]; then
   ln -s /dev/sg1 /dev/changer
fi

But this is not optimal. According to /proc/scsi/scsi
I have this entry

Host: scsi2 Channel: 00 Id: 00 Lun: 00
 Vendor: EXABYTE  Model: LTO 1x7 2U   Rev: B005
 Type:   Medium Changer   ANSI SCSI revision: 04

which means (now that I barely know enough to be dangerous)
that I need to create a rule to bind the scsi generic device I want
to sg1; so I have to derive something from the output of udevinfo
command:

sh-3.1# udevinfo -a -p /sys/class/scsi_generic/sg1/

udevinfo starts with the device the node belongs to and then walks up the
device chain, to print for every device found, all possibly useful
attributes
in the udev key format.
Only attributes within one device section may be used together in one rule,
to match the device for which the node will be created.

 looking at device '/class/scsi_generic/sg1':
   KERNEL=="sg1"
   SUBSYSTEM=="scsi_generic"
   SYSFS{dev}=="21:1"

 looking at device '/devices/pci:00/:00:1e.0/:06:00.0
/host2/target2:0:0/2:0:0:0':
   ID=="2:0:0:0"
   BUS=="scsi"
   DRIVER==""
   SYSFS{ioerr_cnt}=="0x2"
   SYSFS{iodone_cnt}=="0x8c"
   SYSFS{iorequest_cnt}=="0x8c"
   SYSFS{iocounterbits}=="32"
   SYSFS{timeout}=="0"
   SYSFS{state}=="running"
   SYSFS{rev}=="B005"
   SYSFS{model}=="LTO 1x7 2U  "
   SYSFS{vendor}=="EXABYTE "
   SYSFS{scsi_level}=="5"
   SYSFS{type}=="8"
   SYSFS{queue_type}=="none"
   SYSFS{queue_depth}=="2"
   SYSFS{device_blocked}=="0"

 looking at device '/devices/pci:00/:00:1e.0/:06:00.0
/host2/target2:0:0':
   ID=="target2:0:0"
   BUS==""
   DRIVER==""

 looking at device '/devices/pci:00/:00:1e.0/:06:00.0/host2':
   ID=="host2"
   BUS==""
   DRIVER==""

 looking at device '/devices/pci:00/:00:1e.0/:06:00.0':
   ID==":06:00.0"
   BUS=="pci"
   DRIVER=="aic7xxx"
   SYSFS{modalias}=="pci:v9005d0080sv9005sdE2A0bc01sc00i00"
   SYSFS{local_cpus}==""
   SYSFS{irq}=="21"
   SYSFS{class}=="0x01"
   SYSFS{subsystem_device}=="0xe2a0"
   SYSFS{subsystem_vendor}=="0x9005"
   SYSFS{device}=="0x0080"
   SYSFS{vendor}=="0x9005"

 looking at device '/devices/pci:00/:00:1e.0':
   ID==":00:1e.0"
   BUS=="pci"
   DRIVER==""
   SYSFS{modalias}=="pci:v8086d244Esvsdbc06sc04i01"
   SYSFS{local_cpus}==""
   SYSFS{irq}=="0"
   SYSFS{class}=="0x060401"
   SYSFS{subsystem_device}=="0x"
   SYSFS{subsystem_vendor}=="0x"
   SYSFS{device}=="0x244e"
   SYSFS{vendor}=="0x8086"

 looking at device '/devices/pci:00':
   ID=="pci:00"
   BUS==""
   DRIVER==""


So, after the most cursory reading of the documentation, I guess that I want

ID=="2:0:0:0" BUS=="s

Re: AMANDA reports no slots, but there ARE slots!

[Jon LaBadie]

On Tue, Mar 06, 2007 at 04:09:42PM -0500, FL wrote:
> On 2/22/07, Stefan G. Weichinger <[EMAIL PROTECTED]> wrote:
> >
> After watching the trouble recur, I see that the device associated with the
> changer SCSI device ID moved: it was /dev/sg2, today it is /dev/sg1. No
> changes were made to the Exabyte LTO-2 tape library  or to the SCSI card (or
> anything else). So there is something I'm failing to understand about udev,
> SCSI or the Exabyte.
> 
> Perhaps during bootup I should attempt
> 
> mtx -f /dev/sg0 status
> mtx -f /dev/sg1 status
> 
> until I have a valid status, and link
> /dev/changer to that, then refer to /dev/changer in amanda.conf. That's a
> workaround: somehow the device assigned to the changer moves on occasion,
> after a reboot. Perhaps I should be referring to the changer device in some
> other way (bus number, SCSI ID, lun...).

Does your system have sg_scan?  My FC4 does.  It would be a way of
enumerating your devices and possibly setting up udev rules to
create persistent names for the devices.

Here is a sample output on my system with a DDS3 drive + changer
id 5, lun 0+1, an LTO drive, and two usb disks.

[EMAIL PROTECTED] /]# sg_scan -i
/dev/sg0: scsi0 channel=0 id=5 lun=0
HPC1557AU610 [rmb=1 cmdq=0 pqual=0 pdev=0x1]
/dev/sg1: scsi0 channel=0 id=5 lun=1
HPC1557AU610 [rmb=1 cmdq=0 pqual=0 pdev=0x8]
/dev/sg2: scsi1 channel=0 id=4 lun=0
HPUltrium 1-SCSIE21V [rmb=1 cmdq=0 pqual=0 pdev=0x1]
/dev/sg3: scsi3 channel=0 id=0 lun=0 [em]
ST330083  1A3.03 [rmb=0 cmdq=0 pqual=0 pdev=0x0]
/dev/sg4: scsi4 channel=0 id=0 lun=0 [em]
ST330063  1A3.04 [rmb=0 cmdq=0 pqual=0 pdev=0x0]

-- 
Jon H. LaBadie  [EMAIL PROTECTED]
 JG Computing
 4455 Province Line Road(609) 252-0159
 Princeton, NJ  08540-4322  (609) 683-7220 (fax)

vtapes, virtual libraries, and tape?

[Lonny Selinger]

All,

I'm just digging around a little more but I figured I'd put this out anyway.
I'm just curious if anyone has tried anything like this ... I'd like to
maintain longer retention period backups to tape and still have the advantage
of using the file-driver and a virtual library of tapes.

Based on the virsatility of Amanda I'm sure it's possible but the only thing I
can think of so far is to create another config that would write to tape and
would only write full backups. What it looks like would happen though is that
I would have a full to tape and a full on disk that my incriemtals would be
based off of.

Is it possible to have a full backed up to tape and have just the incrementals
written to disk? I'm not sure how I would link the two or if there's a way to
configure this. I'm prety new to Amanda so I'll keep searching but I figured
I'd ask.

Thanks,
Lonny
-- 
"To mess up a Linux box, you need to work at it; to mess up your Windows box,
you just need to work ON it."

Re: AMANDA reports no slots, but there ARE slots!

[Stefan G. Weichinger]

FL schrieb:

> After watching the trouble recur, I see that the device associated with
> the changer SCSI device ID moved: it was /dev/sg2, today it is /dev/sg1.
> No changes were made to the Exabyte LTO-2 tape library  or to the SCSI
> card (or anything else). So there is something I'm failing to understand
> about udev, SCSI or the Exabyte.
>  
> Perhaps during bootup I should attempt
>  
> mtx -f /dev/sg0 status
> mtx -f /dev/sg1 status
>  
> until I have a valid status, and link
> /dev/changer to that, then refer to /dev/changer in amanda.conf. That's
> a workaround: somehow the device assigned to the changer moves on
> occasion, after a reboot. Perhaps I should be referring to the changer
> device in some other way (bus number, SCSI ID, lun...).

Don't remember the used OS now:

Do you have something like udev on that box? You could then set up a
rule to get a fixed relation between devicename and device.

What else gets in the way? /dev/sg? are scsi-devices, on my boxes the
order is always the same, increasing with the SCSI-IDs.

Another idea would be:

chgrp tape /dev/sg?

in a start-script ...

Just quick thoughts.

Stefan

Re: AMANDA reports no slots, but there ARE slots!

[FL]

On 2/22/07, Stefan G. Weichinger <[EMAIL PROTECTED]> wrote:


FL schrieb:
> Now that this problem is overcome,

What did now solve it?
chgrp'ing again?




After watching the trouble recur, I see that the device associated with the
changer SCSI device ID moved: it was /dev/sg2, today it is /dev/sg1. No
changes were made to the Exabyte LTO-2 tape library  or to the SCSI card (or
anything else). So there is something I'm failing to understand about udev,
SCSI or the Exabyte.

Perhaps during bootup I should attempt

mtx -f /dev/sg0 status
mtx -f /dev/sg1 status

until I have a valid status, and link
/dev/changer to that, then refer to /dev/changer in amanda.conf. That's a
workaround: somehow the device assigned to the changer moves on occasion,
after a reboot. Perhaps I should be referring to the changer device in some
other way (bus number, SCSI ID, lun...).

Thanks again.

FL

Re: Amanda Solaris + Kerberos5 anyone?

[Klas Heggemann]

Are we really the only ones wanting to use amanda with kerberos 5 on  
Solaris?

Feels a bit lonely...


Hi!

Anyone out there using amanda on Solaris with Kerberos 5?

We've been trying to get Amanda working with Kerberos 5 on Solaris  
(10)

with limited success.

We've tried builds with Heimdal and with MIT-kerberos, but have not  
managed

to get a working setup.

Looking at the debug output (amcheck -c), it seems the the initial  
connecetion works OK,

but then someting bails out.

The client seems to accept the initial connection (checking and  
matching the

principal in its .k5amandahosts file)  It then sends an answer that
the server receives but fails to recognize so it gets discarded.  
The client
repeats the ACK with no success and the servers gives up on the  
connection.


Is there anyone that managed to get this working on Solaris and can  
give

any hints?

/klas

Re: Should we move to amanda 2.5.1 ?

[Cyrille Bollu]

> 2007/2/27, Guy Dallaire <[EMAIL PROTECTED]>:
> We're happily running amanda 2.4.5 right now. I'm wondering if we 
> should move toward 2.5.1. I don't see the advantages for us. Are 
> major bug fixes still issued for 2.4.5 ?
> 
> If we move to 2.5.1, will we be able to recover the backups we made 
> with 2.4.5. Do we have to upgrade all the clients and server at the 
> same time ?
> 
> Thanks
> 
> 
> Was I too vague ?

Maybe...

I'm in the same situation as your.

Sometime ago, I was considering upgrade to 2.5.1 for some reasons but I 
can't remember why. Maybe this was something to do with the fact that 
amanda 2.5.1 could run scripts on the client before doing a backup... Oh 
wait, I just remembered now: It was just that I wanted to re-compile 
amanda to use a larger block size than the one pre-defined in RedHat (but 
maybe there was also this idea of client-side script execution)

Then I read quite a few bug reports on the list concerning the first 
releases of 2.5.1 and now I'm not so excited by this upgrade anymore...

Cyrille

Re: SDLT-4 compareded to LTO-3

[Cyrille Bollu]

> 
> > LTO-3 also has atleast one advantage for (capable) libraries, each
> > cartridge has a contactless (read... RFID like) memory that can
> > report the tapes last known condition, as well as user data.  in
> > theory atleast an LTO drive or library has only to read this tag to
> > decide whether-or-not it can read the tape, and if it even should.
> 
> Anyone ever used LTO CM (cartridge memory)? With amanda?
> 

I think that Amanda doesn't use the tape memory. 

I think it writes the tape label on the first few blocks of the tape 
instead.

Cyrille

Re: Should we move to amanda 2.5.1 ?

[Guy Dallaire]

2007/2/27, Guy Dallaire <[EMAIL PROTECTED]>:


We're happily running amanda 2.4.5 right now. I'm wondering if we should
move toward 2.5.1. I don't see the advantages for us. Are major bug fixes
still issued for 2.4.5 ?

If we move to 2.5.1, will we be able to recover the backups we made with
2.4.5. Do we have to upgrade all the clients and server at the same time ?

Thanks




Was I too vague ?

Re: SDLT-4 compareded to LTO-3

[Sven Rudolph]

Michael Loftis <[EMAIL PROTECTED]> writes:

> --On March 2, 2007 10:31:33 AM + Anthony   Worrall
> <[EMAIL PROTECTED]> wrote:

>> This is not strictly an amanda question but I thought I would see if any
>> one has any views on SDLT-4 compared to LTO-3.
>>
>> We are currently looking at replacing our tape devices an are looking at
>> SDLT-4 which seems to be about the same price as LTO-3 but offer twice
>> the capacity. Has anyone got any experience of these drives. I am told
>> by our supplier that they are selling many more LTO-3 than SDLT-4. Is it
>> just that SDLT-4 is newer is there some reason?
>
> SDLT-4 (DLT-S4) may cost less $/gb but it still costs more per tape.
> So unless you're actually using that much tape it may noe be as
> attractive as it seems.

In my configuration I can easily utilize 800GB tapes; so this is no
problem. I tested a DLT-S4 library and it works fine.

In Germany the tapes cost fourty percent more than LTO-3 tapes; so
DLT-S4 is less expensive than LTO-3.

> Several other issues with DLT-S4 are the relatively slow rated
> speed of 60MB/sec (LTO3 is rated at 80, and I routinely see 60 in
> production, I'd see more if I had faster hosts).

This means that DLT-S4 perfectly matches your current speed
requirements ;-)

> Also I don't know, but last I checked DLT still had to be streamed at
> the rate they were at.

Sorry, I never cared about this. Two SATA disks as RAID0 provide
enough bandwidtht.

> Though the biggest reasons LTO is outselling DLT/SDLT is SDLT is
> viewed as being end of line first,

That's IMHO the major point. There are qualified rumours that DLT-S4
will be the last in the DLT family.

> LTO-3 also has atleast one advantage for (capable) libraries, each
> cartridge has a contactless (read... RFID like) memory that can
> report the tapes last known condition, as well as user data.  in
> theory atleast an LTO drive or library has only to read this tag to
> decide whether-or-not it can read the tape, and if it even should.

Anyone ever used LTO CM (cartridge memory)? With amanda?

> DLT and SDLT have the problem that if you load an older generation
> cartridge than your drive supports you may destroy the heads.

I didn't try all combinations, but my SDLT-I drive reliably rejected
SDLT-II tapes. Nothing has been destroyed.

Sven