Overland AIT and chg-zd-mtx
I seem to be having some problems with my Overland AIT library and chnaging tapes. It appears I am missing some things in changer.conf or amanda.conf. What it comes down to is whenever I try to run something like: amlabel -f DailySet1 tape123212 slot 7 I get the response of: labeling tape in slot /usr/local/libexec/chg-zd-mtx: ([: 7: unary operator expected): rewinding amlabel: no tape online But if I run the same command again it works because the tape is in the drive. Here is my changer.conf: firstslot=1 lastslot=18 AUTOCLEAN=0 offlinestatus=1 havereader=1 OFFLINE_BEFORE_UNLOAD=0 MT=/bin/mt MTF=-f MTX=/usr/local/sbin/mtx Here is the output of the above command in changer.debug: Fri Jun 1 09:38:54 EDT 2001 Invoked with args '-slot 7' STATUS - currently loaded slot = -1 LOADSLOT - load tape from slot 7 - loading tape from slot 7 to /dev/nst0 - status 0, result '' - readyStatus = SCSI 2 tape drive: File number=0, block number=0, partition=0. Tape block size 512 bytes. Density code 0x31 (unknown to this mt). Soft error count since last status=0 General status bits on (4101): BOT ONLINE IM_REP_EN - rewind 7 I think it must be something really minor in chg-zd-mtx, but I am lost on where to tweak it to work correctly. Any help you could provide would be great. Thanks, Grant Schofield ITA Software
subscribe
auth 83ac0875 subscribe amanda-users [EMAIL PROTECTED]
amrestor -ing 3 files but can't find em
As root from the / directory on the tape host I run amrecover -C daily -s sunny1 -t sunny1 -d /dev/rmt/0cbn amrecover sethost to sunny#2 200 Dump host set sunny#2 amrecover setdisk to sda10 200 Disk set to sda10. amrecover cd web /web amrecover cd bin /web/bin ###When I do an ls I see the files I want amrecover add file1.sh Added /web/bin/file1.sh amrecover extract Extracting files using tape drive /dev/rmt/0cbn on host sunny1 The following tapes are needed: daily119 Restoring files into directory / Continue? [Y/n]: y Load tape daily119 now Continue? [Y/n]: y amrecover Did amrecover restore the file? I looked on sunny1 in the root dir and on sunny2 in /web/bin but I am unable to locate the file I am trying to restore. thanks,
unsubscribe
un _ Get your FREE download of MSN Explorer at http://explorer.msn.com
Re: Iomega Zip tapetype definition
I'd just downloaded the source tree of amanda from cvs, is it what you said or it's at another place. By from cvs do you mean from SourceForge? And did you check out the amanda-242-tapeio branch? Here's an FAQ item about the location: http://amanda.sourceforge.net/fom-serve/cache/136.html Must I run ./configure with any special argument or it's enough 'make; make install'. You need to run autogen first, then configure, then make. Here's an FAQ item about it: http://amanda.sourceforge.net/fom-serve/cache/156.html Javier Viñuales Gutiérrez John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: map bits from windows to samba/amanda
So, is there a way to save these bits with amanda and samba? ... Sure. Get the Samba folks to put them in the tar file. Amanda has nothing to do with them. And for me more important is there a way to restore the files with the bits they had before the were backed up? Again, ask the Samba folks. Amanda just saves the image and gives it back to you. It pays absolutely no attention to what's inside. Wolfgang John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Iomega Zip tapetype definition
On vie, jun 01, 2001 at 02:10:35 -0500, John R. Jackson wrote: By from cvs do you mean from SourceForge? And did you check out the amanda-242-tapeio branch? Here's an FAQ item about the location: Yes I mean. What do you want to say with amanda-242-tapeio branch, the only modulenames I can to see are: amanda, amanda-2, amanda-krb-2, amcore, old and www. I'd downloaded amanda-2 module, is it ok?. You need to run autogen first, then configure, then make. Here's an FAQ item about it: http://amanda.sourceforge.net/fom-serve/cache/156.html Oops!, I must had seen this first sorry :-? Thank you very much. -- Javier Viñuales Gutiérrez [EMAIL PROTECTED] [EMAIL PROTECTED] GnuPG public information: pub 1024D/4EB82468 1C2A 0241 D350 B43D E027 4FCD F8E8 3454 4EB8 2468
Re: Faster dump on tape
I measured (cstream(8)) that it needs about 6 Mbs to keep the tape streaming. Does it tell you how it did that? For instance, what block size did it use? Does it use the normal write() system call? Is the data random or a fixed pattern? Do you have hardware compression turned on? Tape write rate given in Amanda reports is (stable values) Avg Tp Write Rate (k/s) 4643.2 4687.7 3698.6 You need to split these into dumps that were written to tape from the holding disk vs. those written directly to tape from the network. To do that, look at the amdump.nn file(s). Those with FILE-WRITE are holding disk - tape. Those with PORT-WRITE are network/dumper - tape. The DONE line from taper tells you the KBytes/s rate. The next question is, can the holding disk feed taper fast enough? I would test it this way (very carefully): * Create a second configuration just like your main one but with a separate curinfo, etc. * Reload a good sized (10's to 100's of MBytes) image from some tape into the holding disk. Actually, I'd store it in a temp area within the holding disk, then create the holding disk datestamp directory and finally hard link the temp file name(s) to the datestamp directory. That way, when you run amflush below, the file names will be removed from the datestamp directory but you can quickly re-create it to adjust some values and try the test again. For instance: cd /holding/disk mkdir xxx cd xxx amrestore $TAPE some-host some-disk dd if=some-host.some-disk.nn bs=32k count=1 # to get the datestamp cd .. mkdir MMDD ln xxx/* MMDD/. To repeat a test, all you have to do is rerun the last two steps (mkdir and ln). * dd the image from the holding disk to /dev/null with bs=32k and see what kind of rate you get. * Set tapedev in the alternate configuration to /dev/null. * Run amflush with the alternate configuration and see what kind of rate you get. Then I'd try the above test cases with a real tape and see what you get. Keep in mind that the holding disk may now be contending with the tape if they are on the same bus. If you have enough disk space on some other device, you could try putting the holding disk there for testing. About the only tunable taper has is the number of buffers (tapebufs). I'd try doubling that and see what happens, but only after I was sure nothing else was the bottleneck. Olivier John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
core:
ELF 32-bit MSB core file SPARC Version 1, from 'ufsrestore gdb ufsrestore GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as sparc-sun-solaris2.8...(no debugging symbols found)... (gdb)
Re: core:
ELF 32-bit MSB core file SPARC Version 1, from 'ufsrestore So this isn't an Amanda problem, but a Solaris one. Here are some thoughts: * Go to Sun and look for any patches to ufsdump/ufsrestore, i.e. make sure you're running the latest version. * Reload the image to disk by hand and run ufsrestore against it directly instead of in a pipeline: cd /some/place mt -f /dev/rmt/0cbn amrestore /dev/rmt/0cbn admin1.corp.walid.com sda10 cd /where/ever ufsrestore if /some/place/admin1.corp.walid.com.sda10.20010519.0 * If that doesn't work, see if any of your other systems are running a different version of ufsrestore (either older or newer) and either try the image there or copy the ufsrestore program over to your tape server (use some temporary name) and try it there. * If that doesn't work, try dd'ing the image to a **scratch** tape and handing that to ufsrestore: cd /some/place mt -f /dev/rmt/0cbn dd if=admin1.corp.walid.com.sda10.20010519.0 of=/dev/rmt/0cbn bs=32k mt -f /dev/rmt/0cbn cd /where/ever ufsrestore ibf 64 /dev/rmt/0cbn * If that still doesn't work, ask me offline of the list and I'll dig into my dirty little bag of tricks for some other slight of hand. One question first, what version of Solaris are you using? BTW, at some point you'll want to change to using /dev/rmt/0cn instead of /dev/rmt/0cbn. The 'b' gives you BSD semantics, which can sometimes cause problems with Amanda. Nothing related to what your seeing at the moment, but there are other issues. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: core:
On Jun 1, 2001, Denise Ives [EMAIL PROTECTED] wrote:
gdb ufsrestore
This GDB was configured as sparc-sun-solaris2.8...(no debugging symbols
found)...
(gdb)
If it was ufsrestore that crashed, you should file a bug report to
Sun.
But first, make sure this particular filesystem was dumped with
ufsdump on the same version of Solaris. dump formats change from one
OS to another, and from one OS version to another.
--
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
tape host is solaris and one client running linux
I can restore all images/files backed-up via the solaris box but Tape Host SunOS sundev1 5.8 Generic sun4u sparc SUNW,Ultra-60 Client Linux 6.2 I can restore all files on my Sun box. However, Amanda generates a core file every time I try to restore back-ups of the client.
Re: tape host is solaris and one client running linux
Tape Host SunOS sundev1 5.8 Generic sun4u sparc SUNW,Ultra-60 Client Linux 6.2 I can restore all files on my Sun box. However, Amanda generates a core file every time I try to restore back-ups of the client. Oh. Well that explains everything. You can't do that. Dump format is system-dependent. You can't read a Linux dump image on a Solaris system (or vice versa). You'll have to do the restore on the Linux system. If you don't want to restore the file in place, just cd to a different directory before running amrecover (or use lcd when inside amrecover). John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
FreeBSD 4.3/inetd failing
I have a new FBSD 4.3 box and I installed the amanda 2.4.2p2 client with the same parameters as my other FBSD 4.2 clients: ./configure --with-gtar=/usr/local/bin/gtar --without-server --with-portrange=900,950 --with-udpportrange=900,950 --with-user=root --with-group=wheel --with-amandahosts inetd.conf entry: amanda dgram udp waitroot/usr/local/libexec/amandad amandad Using tcpdump, I see the packets get to the machine, but at that point, inetd craps out: inetd[152]: amanda/udp server failing (looping), service terminated netstat -a confirms that the machine at this point is no longer listening to the udp/amanda port, and HUPing inetd fixes that issue. I even tried copying the libexec stuff from a 4.2 box with the same result. Any suggestions? I'm not sure if this is a FBSD or amanda problem, though considering my other FBSD 4.2 machines are setup exactly the same, it appears to be a FBSD one. Thanks! ~ Doug Silver Quantified Systems, Inc ~
Re: FreeBSD 4.3/inetd failing
Done. The script still doesn't execute, inetd just terminates the service. Here's what tcpdump shows: # tcpdump udp tcpdump: listening on fxp0 17:10:40.132018 amanda-server.930 client.amanda: udp 214 17:10:49.591485 amanda-server.930 client.amanda: udp 214 Nothing in /tmp. Very strange, don't you think?! I heard of inetd doing this when it's bombarded, but I think this happens right when the first packet gets to that port! -doug On Fri, 1 Jun 2001, John R. Jackson wrote: print: not found Change print to echo in the script. -doug John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] -- ~ Doug Silver Quantified Systems, Inc ~
Re: FreeBSD 4.3/inetd failing
Done. The script still doesn't execute ... Doesn't execute at all??? Is anything logged to /var/adm/messages (or wherever inetd puts stuff)? What happens if you run the script as your Amanda user (root?). It should sit for 30 seconds and then terminate, and you should get the script output file. -doug John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
