Re: Problem with device sg*
On Apr 26, 2001, Juergen Knott <[EMAIL PROTECTED]> wrote:
> Hm.with "mtx -f /dev/sg7 slot first" i haven't problems. The tape is
> changed. Also "mtx -f /dev/sg7 info" have no problems.
But /dev/sg7 is not the tape device, it's the changer device.
It is /dev/nst0, the tape device, that is not working. Are you sure
/dev/nst0 is what you're supposed to use to access the tape device
associated with that changer?
--
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
could someone explain me this error?
hi, is someone could help me, here is an extract from an amanda report, as you can see i am trying to backup disks: i don't understand why amanda return "data timeout" because the other disk have been successfully backup ?? FAILURE AND STRANGE DUMP SUMMARY: minos ida/c0d0p8 lev 1 FAILED [data timeout] minosida/c0d0p7 13070384 12.5 0:06 69.3 0:02 185.5 minosida/c0d0p8 1 FAILED --- minosida/c0d2p4 2 506300 222528 44.0 6:45 550.1 0:504450.4 -- pierre-yves Verdon (FRANCE)
Problems with tar
Hello, I'm using gnutar to save some devices and I get something like this on tape: 07270112417/./OPCTEST/OPC/TIM/skripte/Opc_esi/data/input/Ota/sz1/ 07270112417/./OPCTEST/OPC/TIM/skripte/Opc_esi/data/input/Ota/sz10/ 07270112417/./OPCTEST/OPC/TIM/skripte/Opc_esi/data/input/Ota/sz11/ 07270112417/./OPCTEST/OPC/TIM/skripte/Opc_esi/data/input/Ota/sz12/ 07270112417/./OPCTEST/OPC/TIM/skripte/Opc_esi/data/input/Ota/sz13/ 07270112417/./OPCTEST/OPC/TIM/skripte/Opc_esi/data/input/Ota/sz14/ 07270112417/./OPCTEST/OPC/TIM/skripte/Opc_esi/data/input/Ota/sz15/ 07270112417/./OPCTEST/OPC/TIM/skripte/Opc_esi/data/input/Ota/sz16/ 07270112417/./OPCTEST/OPC/TIM/skripte/Opc_esi/data/input/Ota/sz17/ 07270112417/./OPCTEST/OPC/TIM/skripte/Opc_esi/data/input/Ota/sz18/ 07270112417/./OPCTEST/OPC/TIM/skripte/Opc_esi/data/input/Ota/sz19/ 07270112417/./OPCTEST/OPC/TIM/skripte/Opc_esi/data/input/Ota/sz2/ 07270112417/./OPCTEST/OPC/TIM/skripte/Opc_esi/data/input/Ota/sz20/ 07270112420/./OPCTEST/OPC/TIM/skripte/Opc_esi/data/input/Ota/sz21/ 07270112420/./OPCTEST/OPC/TIM/skripte/Opc_esi/data/input/Ota/sz22/ 07270112420/./OPCTEST/OPC/TIM/skripte/Opc_esi/data/input/Ota/sz23/ 07270112420/./OPCTEST/OPC/TIM/skripte/Opc_esi/data/input/Ota/sz24/ 07270112420/./OPCTEST/OPC/TIM/skripte/Opc_esi/data/input/Ota/sz25/ Due to the prefix numbers it takes a lot of time and work to restore entire directories from tape. So my question is: what are those numbers and how do I get amanda to not write them on the tape? Any help is appreciated. Regards Silke - Silke Mueller | Am Hoppenhof 33 ORGA Kartensysteme| 33104 Paderborn email: [EMAIL PROTECTED] | phone: +49 +5251 889-1305
Re: Problems with tar
>So my question is: what are those numbers and how do I get amanda to not >write them on the tape? Those numbers mean you're using a broken version of GNU tar 1.13. You should get at least version 1.13.19. > Silke John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Problem with device sg*
> On Apr 26, 2001, Juergen Knott <[EMAIL PROTECTED]> wrote: > > Hm.with "mtx -f /dev/sg7 slot first" i haven't problems. The tape is > > changed. Also "mtx -f /dev/sg7 info" have no problems. > > But /dev/sg7 is not the tape device, it's the changer device. correct, the tape device is /dev/sg6 > It is /dev/nst0, the tape device, that is not working. Are you sure > /dev/nst0 is what you're supposed to use to access the tape device > associated with that changer? Before i installed a new hard drive in the system (only scsi devices), the changer device was /dev/sg6 and the tape device was /dev/sg5. The device /dev/nst0 (no-rewinding device?) is set from the beginning and was working fine. But after installing the new hard-drive, i have changed the /dev/sg5 to /dev/sg6 and /dev/sg6 to /dev/sg7. The /dev/nst0 device is not changed in the config. I don't understand that "mtx -f /dev/sg6 info" works fine. And when i have loaded a tape manually and start "amcheck Daily", the loaded tape was unloaded and than comes the error messages in /tmp/amanda/*.debug It is an input-/output error. Do you need Log- or debugfiles from Amanda? Which commands shall i'm typing for the correct debugfiles? Bye Juergen -- Dies ist eine Microsoft freie Mail!
Re: could someone explain me this error?
On Apr 26, 2001, [EMAIL PROTECTED] wrote:
> i don't understand why amanda return "data timeout" because the other
> disk have been successfully backup ??
Unless you have modified dtimeout, this means the Amanda waited for
this filesystem to send data for 30 minutes and got nothing, so it
assumed the system was dead and aborted the backup. You may increase
dtimeout, if you have reasons to believe the backup is indeed making
progress. If you're using GNU tar, this is quite normal: it has a
very long start-up time: while it collects the directory tables it
outputs very little information.
--
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 device sg*
On Apr 26, 2001, Juergen Knott <[EMAIL PROTECTED]> wrote:
>> On Apr 26, 2001, Juergen Knott <[EMAIL PROTECTED]> wrote:
>> > Hm.with "mtx -f /dev/sg7 slot first" i haven't problems. The tape is
>> > changed. Also "mtx -f /dev/sg7 info" have no problems.
>>
>> But /dev/sg7 is not the tape device, it's the changer device.
> correct, the tape device is /dev/sg6
Huh? This looks very much like the name of a changer device too. Why
do you think it's a tape device?
> I don't understand that "mtx -f /dev/sg6 info" works fine.
This probably talks to the tape changer, not to the tape drive.
> And when i have loaded a tape manually and start "amcheck Daily", the loaded
> tape was unloaded and than comes the error messages in /tmp/amanda/*.debug
> It is an input-/output error.
Looks like your tape changer configuration file is not properly set
up. Which changer program are you using? How does its configuration
file look like?
--
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 device sg*
> >> > Hm.with "mtx -f /dev/sg7 slot first" i haven't problems. The tape > >> > is changed. Also "mtx -f /dev/sg7 info" have no problems. > >> But /dev/sg7 is not the tape device, it's the changer device. > > correct, the tape device is /dev/sg6 > Huh? This looks very much like the name of a changer device too. Why > do you think it's a tape device? I think, the first scsi device is sg0, the second is sg1 etc. i have from id0 - id4 scsi drives, id5 is a cd-rom drive, id 7 is the adaptec, id8 is the tape and id9 is the changer. So i think id0 -> sg0 id1 -> sg1 id2 -> sg2 id3 -> sg3 id4 -> sg4 id5 -> sg5 id8 -> sg6 id9 -> sg7 is this correct? Here the sg-devices from the system: root@fileserver:/ > ls -l /dev/sg* crw--- 1 root disk 21, 0 Nov 8 1999 /dev/sg0 crw--- 1 root disk 21, 1 Nov 8 1999 /dev/sg1 crw--- 1 root disk 21, 10 Nov 8 1999 /dev/sg10 crw--- 1 root disk 21, 11 Nov 8 1999 /dev/sg11 crw--- 1 root disk 21, 12 Nov 8 1999 /dev/sg12 crw--- 1 root disk 21, 13 Nov 8 1999 /dev/sg13 crw--- 1 root disk 21, 14 Nov 8 1999 /dev/sg14 crw--- 1 root disk 21, 15 Nov 8 1999 /dev/sg15 crw--- 1 amanda disk 21, 2 Nov 8 1999 /dev/sg2 crw--- 1 amanda disk 21, 3 Nov 8 1999 /dev/sg3 crw--- 1 amanda disk 21, 4 Nov 8 1999 /dev/sg4 crw-r--r-- 1 amanda disk 21, 5 Apr 25 11:20 /dev/sg5 crw-r--r-- 1 amanda disk 21, 6 Apr 25 11:21 /dev/sg6 crw-r--r-- 1 amanda disk 21, 7 Apr 25 11:21 /dev/sg7 crwxrwxrwx 1 amanda disk 21, 8 Nov 8 1999 /dev/sg8 crwxrwxrwx 1 amanda disk 21, 9 Nov 8 1999 /dev/sg9 lrwxrwxrwx 1 root root3 Aug 4 2000 /dev/sga -> sg0 lrwxrwxrwx 1 root root3 Aug 4 2000 /dev/sgb -> sg1 lrwxrwxrwx 1 root root3 Aug 4 2000 /dev/sgc -> sg2 lrwxrwxrwx 1 root root3 Aug 4 2000 /dev/sgd -> sg3 root@fileserver:/ > here the result from mtx with sg6 and sg7 root@fileserver: > mtx -f /dev/sg6 status mtx: Request Sense: 70 00 02 00 00 00 00 16 00 00 00 00 04 00 00 00 00 00 00 00 mtx: READ ELEMENT STATUS Command Failed root@fileserver: > mtx -f /dev/sg7 status Data Transfer Element: Full (Storage Element 7 Loaded) Storage Element 1: Full Storage Element 2: Full Storage Element 3: Full Storage Element 4: Full Storage Element 5: Full Storage Element 6: Full Storage Element 7: Empty Storage Element 8: Full Storage Element 9: Full Storage Element 10: Full root@fileserver: > > > I don't understand that "mtx -f /dev/sg6 info" works fine. > This probably talks to the tape changer, not to the tape drive. Sorry, a bug from me, device /dev/sg7 works fine. You can see the resutl from "mtx -f /dev/sg7 status" and "mtx -f /dev/sg6 status" I'm wondering for this: root@fileserver:/ > mtx -f /dev/sg6 status mtx: Request Sense: 70 00 02 00 00 00 00 16 00 00 00 00 04 00 00 00 00 00 00 00 mtx: READ ELEMENT STATUS Command Failed root@fileserver:/ > mtx -f /dev/nst0 status mtx: Request Sense: 70 00 02 00 00 00 00 16 00 00 00 00 04 00 00 00 00 00 00 00 mtx: READ ELEMENT STATUS Command Failed root@fileserver:/ > Is /dev/sg6 and /dev/nst0 the same, eg. the tape? > > And when i have loaded a tape manually and start "amcheck Daily", the > > loaded tape was unloaded and than comes the error messages in > > /tmp/amanda/*.debug It is an input-/output error. > Looks like your tape changer configuration file is not properly set > up. Which changer program are you using? How does its configuration > file look like? I'm using chg-scsi from /usr/local/libexec/chg-scsi Here is the Config from chg-scsi named chg-scsi.conf *** Begin Config *** number_configs 1 eject 0 # Tapedrives need an eject command sleep120 # Seconds to wait until the tape gets ready cleanmax 50# How many times could a cleaning tape get used changerdev /dev/sg7 # # Next comes the data for drive 0 # config0 drivenum0 dev /dev/st0 scsitapedev /dev/sg6 startuse 0 # The slots associated with the drive 0 enduse 9 # statfile /usr/local/etc/amanda/Daily/tape0-slot # The file where the actual slot is stored cleancart 10 # the slot where the cleaningcartridge for drive 0 is located cleanfile /usr/local/etc/amanda/Daily/tape0-clean # The file where the cleanings are recorded usagecount /usr/local/etc/amanda/Daily/totaltime tapestatus /usr/local/etc/amanda/Daily/tapestatus # here will some status infos be stored #labelfile /usr/local/etc/amanda/Daily/labelfile # Use this if you have an barcode reader *** End of Config *** Bye Juergen -- Dies is
Re: Problem with device sg*
Hi! > > After 10 Minutes i send a break with ctrl-c because there is no > > operating. > It's waiting for the tape to get ready. Perhaps Amanda should print a > message after a while, and eventually time out. After 10 minutes i don't have a message from Amanda, so i send a break. > > as user amanda and as user root after typing "mt-f /dev/nst0 rewind" this > > error message is displayed: > > mt: /dev/nst0: Input-/output error > Looks like you've got a problem accessing the tape device. Before you > fix this problem, Amanda won't be able to use it. Hm.with "mtx -f /dev/sg7 slot first" i haven't problems. The tape is changed. Also "mtx -f /dev/sg7 info" have no problems. I think the device /dev/nst0 is demaged. root@fileserver:/home/jknott > ls -l /dev/nst0 crw-rw 1 amanda root disk 9, 128 Apr 26 07:16 /dev/nst0 Bye Juergen -- Dies ist eine Microsoft freie Mail!
Re: Problem with device sg*
On Wed, Apr 25, 2001 at 04:56:38PM +0200, Juergen Knott wrote: > Am Mittwoch, 25. April 2001 16:47 schrieben Sie: > > > > Have you tried different devices ? > > What "mtx -f /dev/sgX status" says on them ? > > Also make sure the device is readable by amanda user. > > Problem is fixed, the major and minor numbers are not set correct. > mtx is working fine, gives me the Information which slot ist loaded etc. > But i have another Problem. I can't open the no-rewinding device /dev/nst0. Based on this and the other messages that have shown up in my mailbox, it sounds to me like your linux kernel doesn't have scsi tape support compiled in, or you don't have scsi tape support available as a module. If you're using redhat, I believe that you may be able to just "modprobe st" as root. (I believe that redhat tries to make everything available as a module if it's not compiled directly into the kernel, but I may be wrong.) -ron > > Bye Juergen > -- > Dies ist eine Microsoft freie Mail!
Re: "STRANGE DUMP SUMMARY"
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> (Thu, Apr 26, 2001 at 04:36:29AM -0700) > HI, > I got the following, and was wondering what the "Strange" meant, and what I could do >about the "File too large" failures : File too large: _> your dumping a >2G file to your linux holding disk, Either upgrade your linux kernel to 2.4 (e.g. suse 7.1) or set the chunksize for your holding disk to something less than 2G. As for the error messages on pipe10's /dev/hda1 either you were dumping a disk that had activity (lot of deleting of files from the looks of it (e.g. an overnight make job) or your disk is dying. Kind regards, -- Gerhard den Hollander Phone +31-10.280.1515 Technical Support Jason Geosystems BV Fax +31-10.280.1511 (When calling please note: we are in GMT+1) [EMAIL PROTECTED] POBox 1573 visit us at http://www.jasongeo.com 3000 BN Rotterdam JASON...#1 in Reservoir CharacterizationThe Netherlands This e-mail and any attachment is/are intended solely for the named addressee(s) and may contain information that is confidential and privileged. If you are not the intended recipient, we request that you do not disseminate, forward, distribute or copy this e-mail message. If you have received this e-mail message in error, please notify us immediately by telephone and destroy the original message.
amverify and runtapes > 1
When running amverify with a tape changer and runtapes set to n greater than 1, we've noticed that amverify will verify the current tape and the next runtapes-1 tapes, even if they weren't all used during the previous amdump. Is this a bug or a feature? It creates unnecessary usage on the unused tapes. thanks, Carey
Re: tapelist
>... I don't know what happened but some tape are not in >proper order (sequence). ... But I would like to know >if it is possible to put in correct order all my tapes ... I wrote a lengthy description of this about a month and a half ago (early March and again mid-March). Look in the E-mail archives for Subject "Add more tapes on the backup cycle" or "Changing the order in which tapes are used". >Sandra John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Configuring and testing Amanda Software...
Hi... I'm configuring Amanda on a server with SDT-9000 tape drive, when I run: $amcheck /etc/amanda/amanda.conf I got the following: Amanda Tape Server Host Check - Server check took 9.328 seconds. protocol packet receive: Conexão recusada (Connection Refused) protocol packet receive: Conexão recusada (Connection Refused) protocol packet receive: Conexão recusada (Connection Refused) Amanda Backup Client Hosts Check WARNING: localhost: selfcheck request timed out. Host down? Client check: 1 host checked in 30.040 seconds, 1 problem found. PS: "Conexão recusada" in english means "Connection Refused" What is happen? I don't know how to procedure now! In my server also runs a firewall. What I need to do to fix this problem? Leandro Melo de Sales. CEFET/AL - Centro Federal de Educação Tecnológica de Alagoas Estagiário GTI - Gerência de Tecnologia da Informação Maceió-AL-Brasil Mensagem enviada pelo servidor de Webmail www.etfal.g12.br
Re: Problem with device sg*
Let me preface this with I'm not a Linux person. But I've been around OS's long enough to make some educated guesses. >I think, the first scsi device is sg0, the second is sg1 etc. That's certainly possible. >here the result from mtx with sg6 and sg7 > >root@fileserver: > mtx -f /dev/sg6 status >mtx: Request Sense: 70 00 02 00 00 00 00 16 00 00 00 00 04 00 00 00 00 00 00 >00 >mtx: READ ELEMENT STATUS Command Failed > >root@fileserver: > mtx -f /dev/sg7 status >Data Transfer Element: Full (Storage Element 7 Loaded) >... What you're seeing here is that sg7 is truly the changer, which accepts raw SCSI commands like "READ ELEMENT STATUS", and that sg6 might be the tape device, but it doesn't do changer type commands (which is no surprise), hence the error. >root@fileserver:/ > mtx -f /dev/sg6 status >mtx: Request Sense: 70 00 02 00 00 00 00 16 00 00 00 00 04 00 00 00 00 00 00 >00 >mtx: READ ELEMENT STATUS Command Failed > >root@fileserver:/ > mtx -f /dev/nst0 status >mtx: Request Sense: 70 00 02 00 00 00 00 16 00 00 00 00 04 00 00 00 00 00 00 >00 >mtx: READ ELEMENT STATUS Command Failed See above. Mtx "status" sends changer SCSI commands to a device (although "info" is a generic command all devices support). So you can't use mtx to talk to the tape drive except with some specific commands -- "status" isn't one of them, "info" probably is. >Is /dev/sg6 and /dev/nst0 the same, eg. the tape? They might end up talking to the same physical device, but you cannot use mtx (in general) to talk to /dev/nst0 and you cannot use mt to talk to /dev/sg6. Mt sends the tape driver ioctl's to do generic types of things (e.g. "rewind"). The driver translates those to the appropriate tape (SCSI, in this case) commands. Amanda (other than chg-scsi) needs a real tape device it can issue mt-like ioctl's to. So you've got to get /dev/nst0 fixed. Chg-scsi can issue raw SCSI commands to a device and bypass the st driver, which is why you give it the sg* names. So with Amanda and chg-scsi, you need both to work properly. Put another way, the /dev/nst0 driver is at one level between an application and the tape device, the /dev/sg* driver is at the next level "down" (closer to the device): Application (e.g. mt or Amanda, other than chg-scsi) st driver sg driver physical device You said: >as user amanda and as user root after typing "mt-f /dev/nst0 rewind" this >error message is displayed: >mt: /dev/nst0: Input-/output error >... >I think the device /dev/nst0 is demaged. I agree that your /dev/nst0 entry might be wrong. It's probably still telling the tape driver to talk to SCSI ID 5, which is why it hung -- disk drives don't like to be told to rewind :-). I don't know how you tell Linux to regenerate /dev entries. Maybe if you just remove (or rename would be safer) it, it will come back on the next reboot? >Bye Juergen John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Configuring and testing Amanda Software...
>WARNING: localhost: selfcheck request timed out. Host down? First, you probably do not want to use localhost. Use the real host name instead. It will save you grief later if things move around. The "selfcheck request timed out" error comes up here a lot (it's a very common first problem), and is covered in the FAQ at www.amanda.org. I'd suggest starting there and if you have trouble with that, then post back here what you tried and what the results were. Also, please post what version of Amanda you're using and what OS and version it's running on (client and server, if different). > Leandro Melo de Sales. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
RE: amtape advance errors
> > >We have an Exabyte 220 tape library, running chg-scsi tape changer ... > > What version of Amanda? What version of chg-scsi? > 2.4.2 p2. I'm not sure which version of chg-scsi; whatever's with amanda 2.4.2p2. Carey
Re: access to raid
nope not using xinetd "John R. Jackson" wrote: > >groups = yes is nowhere as far as I know, doing a grep search through > >man amanda, amdump, amanda.conf shows no such line > > It's an xinetd parameter. You need to look in that config file, if > you're using xinetd. > > >I assume therefore the default is group = no.? > > That's my understanding. > > >Steven > > John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Tar, general, and amindexd questions
Hello,
Thank you for responding to my message. this platform (redhat 7.0) uses
Xinetd. here's the configuration:
[streak : xinetd.d]$ cat amandaidx
# default: on
# this is for the amindexd program.
service amandaidx
{
socket_type = stream
protocol= tcp
wait= no
user= bv-amanda
groups = yes
server = /usr/local/libexec/amindexd
server_args = amindexd
}
> Note that "amindexd" in the path. That says your inetd.conf or xinetd
> config file is wrong. It's passing the program name ("amindexd") as an
> arg to the program, who is taking it as the config name to use.
Ok, I see (I think) how having my configuration as part of the
server_args line could have an effect, but what if I wish to
run amindexd for a different configuration such as Test, Periodic_full,
or Daily? Since I specify "amrecover -C Daily" on the command line, I
would expect the data stream from client to server to tell amindexd
what configuration to look for.
Thanks for your time...
--jason
--
~~~
Jason Brooks ~ (503) 641-3440 x1861
Direct ~ (503) 924-1861
System / Network Administrator
Wind River Systems
8905 SW Nimbus ~ Suite 255
Beaverton, Or 97008
amanda applications questions
Hello, can I run the planner program independantly to see how amanda is scheduling dumps? I realize planner puts out estimations based on my tape type info, netusage limits, etc. --jason -- ~~~ Jason Brooks ~ (503) 641-3440 x1861 Direct ~ (503) 924-1861 System / Network Administrator Wind River Systems 8905 SW Nimbus ~ Suite 255 Beaverton, Or 97008
tape strategy question
Hello, I am trying to decide if I should have two sets of tapes of fifteen each, or to put them all in one run of thirty tapes? What are the pros and cons of each? this is assuming of course that fifteen tapes can handle a level zero of each filesystem, plus their changes... thanks for your time... -- ~~~ Jason Brooks ~ (503) 641-3440 x1861 Direct ~ (503) 924-1861 System / Network Administrator Wind River Systems 8905 SW Nimbus ~ Suite 255 Beaverton, Or 97008
Disklist formatting questions:
Hello, I just tried doing a test dump and ran into two problems: 1) When I changed the partitions in my disklist file to the mount points, it worked except for "/". I did this so the logs and indexes made sense without having to cross-reference each fstab. example: jetstream hda8 nocomp-root jetstream hda1 nocomp-root become jetstream / nocomp-root jetstream /boot nocomp-root the error messages complain about not being able to open "/dev/root". Is there a mnemonic to indicate to amanda "backup the root filesyste" aside from just the device file? 2) Redhat 7.0 changes its fstab usage to use the labeling feature of the ext2 filesystem. example: LABEL=/ /ext2defaults 1 1 LABEL=/boot /bootext2defaults 1 2 Amanda would chock on these lables until I redid the fstab files to read: /dev/hda6/ext2defaults 1 1 /dev/hda1/bootext2defaults 1 2 Does amanda have the ability to interpret the "LABEL=" portion of fstab then dig the information out of ext2fs? If not, is it planned? I am ok with changing the fstab file, but it kind of falls into my philosophy of "if it ain't broke, don't fix it". --jason -- ~~~ Jason Brooks ~ (503) 641-3440 x1861 Direct ~ (503) 924-1861 System / Network Administrator Wind River Systems 8905 SW Nimbus ~ Suite 255 Beaverton, Or 97008
Re: Tar, general, and amindexd questions
Hello,
I forgot to include I am running version 2.4.2p1 on all systems.
I am running amrecover on the amanda server to remove any networking
hardware issues.
On Thu, Apr 26, 2001 at 02:30:23PM -0700, Jason Brooks wrote:
> Hello,
>
> Thank you for responding to my message. this platform (redhat 7.0) uses
> Xinetd. here's the configuration:
>
> [streak : xinetd.d]$ cat amandaidx
> # default: on
> # this is for the amindexd program.
> service amandaidx
> {
> socket_type = stream
> protocol= tcp
> wait= no
> user= bv-amanda
> groups = yes
> server = /usr/local/libexec/amindexd
> server_args = amindexd
> }
>
> > Note that "amindexd" in the path. That says your inetd.conf or xinetd
> > config file is wrong. It's passing the program name ("amindexd") as an
> > arg to the program, who is taking it as the config name to use.
>
> Ok, I see (I think) how having my configuration as part of the
> server_args line could have an effect, but what if I wish to
> run amindexd for a different configuration such as Test, Periodic_full,
> or Daily? Since I specify "amrecover -C Daily" on the command line, I
> would expect the data stream from client to server to tell amindexd
> what configuration to look for.
>
>
> Thanks for your time...
>
> --jason
>
>
>
> --
>
> ~~~
> Jason Brooks ~ (503) 641-3440 x1861
> Direct ~ (503) 924-1861
> System / Network Administrator
> Wind River Systems
> 8905 SW Nimbus ~ Suite 255
> Beaverton, Or 97008
>
--
~~~
Jason Brooks ~ (503) 641-3440 x1861
Direct ~ (503) 924-1861
System / Network Administrator
Wind River Systems
8905 SW Nimbus ~ Suite 255
Beaverton, Or 97008
Re: Tar, general, and amindexd questions
>server_args = amindexd Ditch that line. None of the Amanda xinetd config files should have a server_args key/value. >... what if I wish to >run amindexd for a different configuration such as Test, Periodic_full, >or Daily? Since I specify "amrecover -C Daily" on the command line, I >would expect the data stream from client to server to tell amindexd >what configuration to look for. Right. It does. You did when you put "-C Daily" on the command line. If you want to run for "Test", do "-C Test". But amindexd looks at the command line first, and that's what triggers the error. If you don't give it the command line arg, then it comes from the data stream. I don't know why amindexd was written to look at it's command line (when not in a debugging mode). That might just be a goof. BTW, the "-C" on amrecover is optional and probably should not be there. >--jason John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amanda applications questions
>can I run the planner program independantly to see how amanda is >scheduling dumps? ... Yes. All you have to do is remove the "log" file that it leaves behind in your "logdir" (set in amanda.conf) afterward. If you forget to do that, the next amdump run will think another run is already in progress and refuse to work. You must run planner as the Amanda user. It must be setuid-root (in case you were going to run it from the build area). Stderr will have the stuff you see in the amdump.NN files. Stdout will have the schedule that would normally be piped to driver. Note that estimates are based on what the client thinks has been backed up, so running planner twice in a row without changing anything else probably won't show any differences. >--jason John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
amrecover
i'm having trouble with AM recover... it doesn't have indexs of any of the disk on my system... its bad to try and recover data and know its on a tape, but not know how to get it back
Re: amrecover
>i'm having trouble with AM recover... it doesn't have indexs of any of the >disk on my system... its bad to try and recover data and know its on a tape, >but not know how to get it back So what, exactly, is your question? Did you turn on indexing in amanda.conf? John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amtape advance errors
>2.4.2 p2. I'm not sure which version of chg-scsi; whatever's with amanda >2.4.2p2. OK. It doesn't look like any version of chg-scsi supports "advance". Oops. Please give the following patch a try and let me know if it solves the problem so I can update the sources. Note that except for making sure it compiles, it is untested as I don't have the hardware needed to easily do much else. >Carey John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] chg-scsi.diff
Re: access to raid
>nope not using xinetd Then you need to look at either sendsize*debug or sendbackup*debug in /tmp/amanda on kaitlin. If you're running 2.4.2p2, it should not be a problem finding the right file. Otherwise, they get overwritten with each invocation unless you used --with-pid-debug-files on ./configure. BTW, I noticed in some old E-mail that you're using "localhost" as one of your systems to back up. It's probably a better idea to use explicit host names in case the configuration has to change at some point (e.g. the tape server moves to a different machine). John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: tape strategy question
>I am trying to decide if I should have two sets of tapes of fifteen >each, or to put them all in one run of thirty tapes? ... What do you mean by "two sets"? >Jason Brooks John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Disklist formatting questions:
> the error messages complain about not being able to open "/dev/root". This and your other item are two symptoms of the same problem. > Does amanda have the ability to interpret the "LABEL=" portion > of fstab then dig the information out of ext2fs? ... Yes. You need to upgrade to 2.4.2p2 and also check out the Amanda patches page for one more item beyond that. >--jason John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Tar, general, and amindexd questions
Hello, On Thu, Apr 26, 2001 at 05:53:13PM -0500, John R. Jackson wrote: > >server_args = amindexd > > Ditch that line. None of the Amanda xinetd config files should have a > server_args key/value. That did it. it is working now. > BTW, the "-C" on amrecover is optional and probably should not be there. Do you mean to say that the "-C" option shouldn't be optional? --jason -- ~~~ Jason Brooks ~ (503) 641-3440 x1861 Direct ~ (503) 924-1861 System / Network Administrator Wind River Systems 8905 SW Nimbus ~ Suite 255 Beaverton, Or 97008
Re: Tar, general, and amindexd questions
>Do you mean to say that the "-C" option shouldn't be optional? I mean that every other Amanda command that takes a configuration as an option accepts it as the first argument and none of them use something like -C. So I changed amrecover so it acts like all the other commands, i.e. you can do this: amrecover Daily -s wherever.com -d /some/device ... The only reason I didn't take -C out altogether was backward compatibility (i.e. I didn't want to deal with all the "what does 'C: unknown option' mean" E-mail :-). Maybe I'll finally get rid of it in 2.5. >--jason John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Problem with device sg*
Am Donnerstag, 26. April 2001 16:57 schrieben Sie: Hi Ron! > Based on this and the other messages that have shown up in my mailbox, it > sounds to me like your linux kernel doesn't have scsi tape support compiled > in, or you don't have scsi tape support available as a module. Sorry, i think you don't understand my english. On this system amanda works a long time ago, but i installed a new hard drive in this system (it's a scsi system). After installing the new Hard drive the devices must be changed, eg. the tape device is changed from /dev/sg5 to /dev/sg6 and the changer device is changed fron /dev/sg6 to /dev/sg7. The no-rewinding device is unchanged. I didn't know that i must change the sg-devices after installing a new hard drive. I'm wondering after installation the drive that amanda can't read/write the tape. Another user told me that i must change the sg-devices, what i have done. But the /dev/nst0 device don't work, and i don't know why. I can put in a tape from hand in the tapedrive and can start ./amcheck Daily, and it's all ok. The second start of ./amcheck Daily is runningand running...and running. No messages on the screen, sot hat i send a break after 10 minutes with CTRL-C to the System and look into the *debug files from amanda and the chg-scsi script can't read from de/nst0 btw. /dev/nst0 have a io-error and can't be open. > If you're using redhat, I believe that you may be able to just > "modprobe st" as root. (I believe that redhat tries to make everything > available as a module if it's not compiled directly into the kernel, but > I may be wrong.) I'm using S.u.S.E 7.0 Prof. The Kernel is an scsi only Kernel wit compiled with gerneric SCSI, SCSI-Disk and SCSI-Tape support. The system was running wonderful bevor i installed a new hard drive. Bye Juegen --
Re: Problem with device sg*
Hi John! > See above. Mtx "status" sends changer SCSI commands to a device (although > "info" is a generic command all devices support). So you can't use mtx > to talk to the tape drive except with some specific commands -- "status" > isn't one of them, "info" probably is. OK, i understand. > >Is /dev/sg6 and /dev/nst0 the same, eg. the tape? > They might end up talking to the same physical device, but you cannot > use mtx (in general) to talk to /dev/nst0 and you cannot use mt to talk > to /dev/sg6. Mt sends the tape driver ioctl's to do generic types of > things (e.g. "rewind"). The driver translates those to the appropriate > tape (SCSI, in this case) commands. Amanda (other than chg-scsi) needs > a real tape device it can issue mt-like ioctl's to. So you've got to > get /dev/nst0 fixed. > > Chg-scsi can issue raw SCSI commands to a device and bypass the st driver, > which is why you give it the sg* names. So with Amanda and chg-scsi, > you need both to work properly. OK, i think it's present, because amanda works fine bevor i installed a new hard disk. > Put another way, the /dev/nst0 driver is at one level between an > application and the tape device, the /dev/sg* driver is at the next > level "down" (closer to the device): > > Application (e.g. mt or Amanda, other than chg-scsi) > st driver > sg driver > physical device When i understand you, than is the application coressponding with the st driver, the st driver is coressponding with the sg driver and the sg driver is coressponding with the physical device. > You said: > >as user amanda and as user root after typing "mt-f /dev/nst0 rewind" this > >error message is displayed: > >mt: /dev/nst0: Input-/output error > >... > >I think the device /dev/nst0 is demaged. > I agree that your /dev/nst0 entry might be wrong. It's probably still > telling the tape driver to talk to SCSI ID 5, which is why it hung -- Hm...the tape haven't and hasn't SCSI ID 5, that's the CD-ROM. First, ID 0, ID1, ID 2, ID 4 are hard drives, ID 5 is the CD-ROM, ID 8 is the tape device and ID 9 is the Changer device. ID 7 is the adaptec. Now, i installed a new hard drive with ID 3 in the system, and from this moment amanda can't change the tapes. > disk drives don't like to be told to rewind :-). I don't know how :-) > you tell Linux to regenerate /dev entries. Maybe if you just remove > (or rename would be safer) it, it will come back on the next reboot? No, i have removed the device /dev/nst0 and rebooted the system, but this device isn't come back, so that i must create it from hand. I made this with "mknod /dev/nst0 c 9 128 but it don't work :-( Bye Juergen --- It's friday!
Re: Problem with device sg*
>When i understand you, than is the application coressponding with the st >driver, the st driver is coressponding with the sg driver and the sg driver >is coressponding with the physical device. Close enough. I doubt st actually talks to sg (it probably has a more direct path to the hardware), but the basic idea is the same. >Hm...the tape haven't and hasn't SCSI ID 5 ... But earlier you said: Before i installed a new hard drive in the system (only scsi devices), the changer device was /dev/sg6 and the tape device was /dev/sg5. I took that to mean the tape drive used to be ID 5. Not that it really matters. The problem is that it doesn't work now. >No, i have removed the device /dev/nst0 and rebooted the system, but this >device isn't come back, so that i must create it from hand. > >I made this with "mknod /dev/nst0 c 9 128 but it don't work :-( I found a Linux system and read up on the major and minor device numbers for the st device so I see where 9 and 128 came from. I don't know enough about Linux to know where you find this out for sure (e.g. some boot time log messages or the like), but I suspect what might be happening is that the driver found something else it thought of as the first (zero'th) "sequential access device" and so 128 is the wrong minor number to have picked. You might try creating a few others (/dev/nst1, etc) per the man page and see if any of them will answer to a simple "mt -f /dev/whatever rewind". One other possibility is that when you added the disk the tape drive went "dead" (unable to be accessed by the st driver) for some reason. For instance, it's in the wrong place on the SCSI chain (narrow after wide, for instance), or termination is now wrong. That's less likely since, if I understood correctly, you can do some simple (info) mtx things to it. Other than that, I think you need some real Linux help here. Until you can get /dev/nstN to work with normal mt commands, this is not really an Amanda issue. Not that there aren't good Linux folks listening in. >Juergen John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] P.S. Before anyone starts quoting chapter and verse about how the st driver works, including that it will pass SCSI commands through, I was deliberatly simplifying the description in this discussion to try and clear up some confusion rather than add to it :-).
Re: Problem with device sg*
Hi John! > >Hm...the tape haven't and hasn't SCSI ID 5 ... > But earlier you said: > Before i installed a new hard drive in the system (only scsi devices), > the changer device was /dev/sg6 and the tape device was /dev/sg5. Yes, because i read that the first scsi device becomes the device /dev/sg0, the second device becomes sg1 etc. The SCSI-ID must not the same as the sg-device. Shit, i don't find the documentation for this. I mean, when only one scsi device is in the system with id 3, than it becomes the device /dev/sg0. Is the one SCSI-Device ID 1, it becomes /dev/sg0 Have you two scsi devices with SCSI-ID 2 and SCSI-ID 4 becomes the device with SCSI-ID 2 /dev/sg0 and the SCSI-Devie with SCSI-ID 4 /dev/sg1 In my System there was 4 HD's, one CD-ROM and the tape with the changer. The HD's have /dev/sg0 - /dev/sg3, the CD-ROM /dev/sg4 and the Tape /Dev/sg5 and the changer /dev/sg6. > I took that to mean the tape drive used to be ID 5. > Not that it really matters. The problem is that it doesn't work now. Right. > I don't know enough about Linux to know where you find this out for > sure (e.g. some boot time log messages or the like), but I suspect what > might be happening is that the driver found something else it thought > of as the first (zero'th) "sequential access device" and so 128 is the > wrong minor number to have picked. You might try creating a few others > (/dev/nst1, etc) per the man page and see if any of them will answer to > a simple "mt -f /dev/whatever rewind". Hm...at another Server i looked in the devices and there is 9 and 128 the Major and Minor numbers of /dev/nst0. The same is in the Doc from the devices. I will search for this dokument. So, i found it. The document is in the Kernel sources under /usr/src/linux/Documentation/devices.txt > One other possibility is that when you added the disk the tape drive > went "dead" (unable to be accessed by the st driver) for some reason. > For instance, it's in the wrong place on the SCSI chain (narrow after > wide, for instance), or termination is now wrong. That's less likely Hm..The System is a 19" Rack with only Mainboard, Grafik etc, and cd-Rom. in the second 19" Rack there are the HD's and the changer is an external device. All HD's are the same Model. > since, if I understood correctly, you can do some simple (info) mtx > things to it. Yes. > Other than that, I think you need some real Linux help here. Until you > can get /dev/nstN to work with normal mt commands, this is not really > an Amanda issue. OK, i think you are right. John, i thank you very much for your Infos and your help. I will search for the error and i want write to you when the changer is running and when i know what the error is. Bye Juergen -- It's Friday!
"STRANGE DUMP SUMMARY"
HI, I got the following, and was wondering what the "Strange" meant, and what I could do about the "File too large" failures : ... FAILURE AND STRANGE DUMP SUMMARY: pipe10 /dev/hda1 lev 1 STRANGE workshop /dev/hdc lev 0 FAILED ["data write: File too large"] workshop /dev/hda1 lev 0 FAILED ["data write: File too large"] ... FAILED AND STRANGE DUMP DETAILS: /-- pipe10.pcp /dev/hda1 lev 1 STRANGE sendbackup: start [pipe10:/dev/hda1 level 1] sendbackup: info BACKUP=/sbin/dump sendbackup: info RECOVER_CMD=/sbin/restore -f... - sendbackup: info end | DUMP: Date of this level 1 dump: Tue Apr 24 07:59:26 2001 | DUMP: Date of last level 0 dump: Thu Apr 19 15:48:15 2001 | DUMP: Dumping /dev/hda1 (/) to standard output | DUMP: mapping (Pass I) [regular files] | DUMP: mapping (Pass II) [directories] | DUMP: estimated 469381 tape blocks. | DUMP: Volume 1 started at: Tue Apr 24 08:00:05 2001 | DUMP: dumping (Pass III) [directories] | DUMP: dumping (Pass IV) [regular files] ? DUMP: bread: lseek fails ? DUMP: bread: lseek fails ? DUMP: short read error from /dev/hda1: [block -892547938]: count=1024, got=0? DUMP: bread: lseek2 fails! ? DUMP: short read error from /dev/hda1: [sector -892547938]: count=512, got=0? DUMP: bread: lseek2 fails! ? DUMP: short read error from /dev/hda1: [sector -892547937]: count=512, got=0? DUMP: bread: lseek fails ? DUMP: short read error from /dev/hda1: [block -1032166684]: count=1024, got=0 ? DUMP: bread: lseek2 fails! ? DUMP: short read error from /dev/hda1: [sector -1032166684]: count=512, got=0 ? DUMP: bread: lseek2 fails! ? DUMP: short read error from /dev/hda1: [sector -1032166683]: count=512, got=0 ? DUMP: bread: lseek fails ? DUMP: short read error from /dev/hda1: [block -556603194]: count=1024, got=0? DUMP: bread: lseek2 fails! ? DUMP: short read error from /dev/hda1: [sector -556603194]: count=512, got=0? DUMP: bread: lseek2 fails! ? DUMP: short read error from /dev/hda1: [sector -556603193]: count=512, got=0? DUMP: bread: lseek fails | DUMP: 32.21% done, finished in 0:10 | DUMP: 46.60% done, finished in 0:11 | DUMP: 69.02% done, finished in 0:06 | DUMP: DUMP: 476474 tape blocks | DUMP: finished in 1143 seconds, throughput 416 KBytes/sec | DUMP: Volume 1 completed at: Tue Apr 24 08:19:09 2001 | DUMP: Volume 1 took 0:19:04 | DUMP: Volume 1 transfer rate: 416 KB/s | DUMP: level 1 dump on Tue Apr 24 07:59:26 2001 | DUMP: DUMP: Date of this level 1 dump: Tue Apr 24 07:59:26 2001 | DUMP: DUMP: Date this dump completed: Tue Apr 24 08:19:09 2001 | DUMP: DUMP: Average transfer rate: 416 KB/s | DUMP: DUMP IS DONE sendbackup: size 476474 sendbackup: end \ /-- workshop.p /dev/hdc lev 0 FAILED ["data write: File too large"] sendbackup: start [workshop:/dev/hdc level 0] sendbackup: info BACKUP=/sbin/dump sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/sbin/restore -f... - sendbackup: info COMPRESS_SUFFIX=.gz sendbackup: info end | DUMP: Date of this level 0 dump: Tue Apr 24 04:20:30 2001 | DUMP: Date of last level 0 dump: the epoch | DUMP: Dumping /dev/hdc (/ddisk) to standard output | DUMP: mapping (Pass I) [regular files] | DUMP: mapping (Pass II) [directories] | DUMP: estimated 22438288 tape blocks. | DUMP: dumping (Pass III) [directories] | DUMP: dumping (Pass IV) [regular files] | DUMP: 0.80% done, finished in 35:54 | DUMP: 3.84% done, finished in 9:19 | DUMP: 6.88% done, finished in 6:09 | DUMP: 10.03% done, finished in 4:49 | DUMP: 12.65% done, finished in 4:17 | DUMP: 15.35% done, finished in 3:53 | DUMP: 18.41% done, finished in 3:29 | DUMP: 20.39% done, finished in 3:24 | DUMP: 22.80% done, finished in 3:13 | DUMP: 25.57% done, finished in 3:01 | DUMP: 27.39% done, finished in 2:58 | DUMP: 29.50% done, finished in 2:52 | DUMP: 31.21% done, finished in 2:50 | DUMP: 32.65% done, finished in 2:49 | DUMP: 35.02% done, finished in 2:41 | DUMP: 38.16% done, finished in 2:29 | DUMP: 40.78% done, finished in 2:21 | DUMP: 43.64% done, finished in 2:12 | DUMP: 46.15% done, finished in 2:05 | DUMP: 48.80% done, finished in 1:57 \ /-- workshop.p /dev/hda1 lev 0 FAILED ["data write: File too large"] sendbackup: start [workshop:/dev/hda1 level 0] sendbackup: info BACKUP=/sbin/dump sendbackup: info RECOVER_CMD=/sbin/restore -f... - sendbackup: info end | DUMP: Date of this level 0 dump: Tue Apr 24 06:21:14 2001 | DUMP: Date of last level 0 dump: the epoch | DUMP: Dumping /dev/hda1 (/) to standard output | DUMP: mapping (Pass I) [regular files] | DUMP: mapping (Pass II) [directories] | DUMP: estimated 4673779 tape blocks. | DUMP: dumping (Pass III) [directories] | DUMP: dumping (Pass IV) [regular files] | DUMP: 4.42% done, finished in 1:48 | DUMP: 13.60% done, finished in 1:03 | DUMP: 23.01% done, finished in 0:50 | DUMP: 32.63% done, finished in 0:41 | DUMP: 43.46% done, finished in 0:32 | DUMP: 54
Off topic: hardware reliability issues with Exabyte X80 Mammoth 2?
My group is considering putting in an order for a 40 or 80 slot Mammoth 2 tape library 2 drives (Part No# 1002699) and 1 power supply. We are going to act soon, but one question plagues us: will it work, and if it does, for how long? Unfortunately, I could not sell our group on AMANDA, so we will be using Veritas NetBackup... are there problems to watch out for there? What about adding 40 new slots to a 40 slot cabinet or new drives. How about Exabyte/IBM global services support? I am looking for real stories of failures and successes. You may e-mail me off list as my posting is clearly off topic. Thank you very much, Soren Soren C. Sorensen -- [EMAIL PROTECTED] http://www.socsci.umn.edu http://www.pop.umn.edu College of Liberal Arts University of Minnesota, Minneapolis, West Bank
tapelist
Hi everybody: one month ago, I changed my tape server for Hp Surestore 24X6 so I use amlabel force and t relabel my new tapes, in this way I be able to use my old configuration (25 tapes, runtapes, etc) but I have problems with my tapelist because I don't know what happened but some tape are not in proper order (sequence). I know that's matter for amanda. But I would like to know if it is possible to put in correct order all my tapes because something is confusing when i going to put my six tapes at the same time and I use the human sequence. This my tapelist now 20010321 miro_daily-10 reuse 20010320 miro_daily-9 reuse 20010319 miro_daily-3 reuse -- out the order 20010319 miro_daily-8 reuse 20010317 miro_daily-7 reuse 20010316 miro_daily-6 reuse 20010315 miro_daily-5 reuse 20010314 miro_daily-4 reuse 20010314 miro_daily-2 reuse 20010312 miro_daily-1 reuse 20010312 miro_daily-25 reuse 20010310 miro_daily-24 reuse 20010309 miro_daily-18 reuse - out the order 20010308 miro_daily-21 reuseout the order 20010307 miro_daily-23 reuse 20010306 miro_daily-22 reuse 20010305 miro_daily-20 reuse 20010305 miro_daily-19 reuse 20010302 miro_daily-17 reuse 20010301 miro_daily-16 reuse 20010228 miro_daily-15 reuse 20010227 miro_daily-14 reuse 20010227 miro_daily-13 reuse Any suggestion? thanks to everybody for your help. Sandra
RE: tapelist
It will take a while, but you can straighten your tape order out. When amcheck says it's about to use a tape that is out of sequence, use 'amadmin CONFIG no-reuse TAPENAME' to take it out of the rotation. Make a note of which tapes you take out of rotation. When the tape cycle comes around to where you want that tape, use 'amadmin CONFIG reuse TAPENAME' to bring it back. amcheck should then show it as the next tape to be used. -Original Message- From: Sandra Panesso [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 26, 2001 1:38 PM To: [EMAIL PROTECTED] Subject: tapelist Hi everybody: one month ago, I changed my tape server for Hp Surestore 24X6 so I use amlabel force and t relabel my new tapes, in this way I be able to use my old configuration (25 tapes, runtapes, etc) but I have problems with my tapelist because I don't know what happened but some tape are not in proper order (sequence). I know that's matter for amanda. But I would like to know if it is possible to put in correct order all my tapes because something is confusing when i going to put my six tapes at the same time and I use the human sequence. This my tapelist now 20010321 miro_daily-10 reuse 20010320 miro_daily-9 reuse 20010319 miro_daily-3 reuse -- out the order 20010319 miro_daily-8 reuse 20010317 miro_daily-7 reuse 20010316 miro_daily-6 reuse 20010315 miro_daily-5 reuse 20010314 miro_daily-4 reuse 20010314 miro_daily-2 reuse 20010312 miro_daily-1 reuse 20010312 miro_daily-25 reuse 20010310 miro_daily-24 reuse 20010309 miro_daily-18 reuse - out the order 20010308 miro_daily-21 reuseout the order 20010307 miro_daily-23 reuse 20010306 miro_daily-22 reuse 20010305 miro_daily-20 reuse 20010305 miro_daily-19 reuse 20010302 miro_daily-17 reuse 20010301 miro_daily-16 reuse 20010228 miro_daily-15 reuse 20010227 miro_daily-14 reuse 20010227 miro_daily-13 reuse Any suggestion? thanks to everybody for your help. Sandra
