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

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

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

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

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

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

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

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

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

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

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

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,

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