Re: Can't Find Clients
Wilkerson, Scott wrote: greener pastures a few months ago. Since then, each time our remaining system manager has upgraded a sun system to Solaris 8 it has begun failing out of the backup set. I have made sure that I can rsh from our backup amcheck gives this error: WARNING: gsbmkt.uchicago.edu: selfcheck request timed out. Host down? I expect that the amanda entries are no longer in /etc/inetd.conf after the update. You will need to add them back and may need to add appropriate entries to /etc/services too. -- [EMAIL PROTECTED] - HMC UNIX Systems Manager
Re: BSDI changers
On Wed, 31 Jan 2001, Rick Meidinger wrote: Is there anyone out there that is using BSDI 4.2 with amanda and a tapechanger? I have a Spectra Logic Treefrog changer with a Sony AIT2 drive. Amanda works great with the drive, but I can get it to recognize the changer. I've searched the archives, and haven't found anything specific on this subject. I've read the TAPE.CHANGERS file, and that hasn't helped too much either. I'm running amanda-2.4.2. Thanks, I'm not using BSDI but I imagine it's probably similar to FreeBSD. Let's start with a few questions: - What changer script(s) have you tried? - Have you determined the device name for the changer? - Does BSDI have chio? If yes, are you able to control the changer with it? - If no chio, have you tried mtx? -Mitch
Re: BSDI changers
On Wed, 31 Jan 2001, Rick Meidinger wrote: - What changer script(s) have you tried? chg-multi chg-multi is probably not what you want to use. I haven't tried it myself but it sounds like it can be made to work if you configure your Treefrog to operate in gravity mode. The Treefrog documentation might call this by a different name such as sequential. Would have loved to try chg-scsi, but it doesn't compile on my system. Have you posted the pertinent information? The author is usually listening and might be interested in getting it to build on BSDI. He got it working with FreeBSD so it shouldn't(?) take much more effort to get it going on BSDI. - Have you determined the device name for the changer? sg0 - Does BSDI have chio? If yes, are you able to control the changer with it? Nope. - If no chio, have you tried mtx? Yes, but I gotten anywhere with it. Doesn't BSDI come with _any_ SCSI media changer control software? If not I think I would complain to the company about that. If they really don't have a recommended solution I would try to get mtx, chio, or chg-scsi to build and run. In the mean time chg-multi should at least allow you to run in gravity/sequential mode. The thing to realize here is amanda does not have built in changer support. Amanda allows for changer support, through the use of a changer script that calls out to whatever software is needed to control the changer you have. This is a flexible design that allows for new devices to be supported by the addition of an appropriate script, but it means you first have to have the low-level software to control the changer itself. (Unless you can get chg-scsi to work.) Some sort of SCSI media changer software typically comes with the OS these days, and then there are applications like mtx that have been around for a while in various versions. The changer scripts that come with amanda are samples that you can use with common existing changer software but they are just a starting place. If you need something different or more exotic it's easy to swap in something else or modify an existing script to do what you need. A few years ago I needed to set up a changer with an OS that came with its own media changer software that amanda didn't have an existing changer script for, and chg-scsi didn't exist yet. By looking at the docs and the existing scripts I was able to write my own in a few days with normal interruptions. Uninterrupted it would have taken a day at most, probably less. -Mitch
amanda-2.4.1-p1 and VxFS 3.3.3
Since upgrading VxFS (Veritas Filesystem) to v 3.3.3 on our Solaris 2.6 servers, amanda (2.4.1-p1) is complaining about strange dump results. An excerpt from a mail follows. Kris, /-- appel /dev/dsk/c3t5d0s4 lev 0 STRANGE sendbackup: start [appel:/dev/dsk/c3t5d0s4 level 0] sendbackup: info BACKUP=/usr/sbin/vxdump sendbackup: info RECOVER_CMD=/usr/local/bin/gzip -dc |/usr/sbin/vxrestore -f... +- sendbackup: info COMPRESS_SUFFIX=.gz sendbackup: info end ? vxfs vxdump: Date of this level 0 dump: Wed Jan 31 21:47:52 2001 ? vxfs vxdump: Date of last level 0 dump: the epoch ? vxfs vxdump: Dumping /dev/rdsk/c3t5d0s4 (/gcg/bin) to stdout ? vxfs vxdump: mapping (Pass I) [regular files] ? vxfs vxdump: mapping (Pass II) [directories] ? vxfs vxdump: estimated 858690 blocks (419.28MB) on 0.01 tape(s). ? vxfs vxdump: dumping (Pass III) [directories] ? vxfs vxdump: dumping (Pass IV) [regular files] | vxfs vxdump: vxdump: 429673 tape blocks ? vxfs vxdump: level 0 dump on Wed Jan 31 21:47:52 2001 ? vxfs vxdump: vxdump is done sendbackup: size 429673 sendbackup: end \
Re: amrestore problems
On Jan 31, 2001, Sandra Panesso [EMAIL PROTECTED] wrote:
/amanda_holding/20001215/duchamp.tomandandy._Local_Users.0.1 | tar xvf
duchamp.tomandandy._Local_Users.0.1 but I got two errors :
amrestore: 0: skipping cont dumpfile: date 20001215 host
duchamp.tomandandy.com disk /Local/Users lev 0 comp .gztar:
This is ok
tar: duchamp.tomandandy.com._Local_Users.0.1: Not found in archive
This means this is not the name of the file you want to restore.
I.e., it's not part of the archive, it's the name of the archive
itself.
But this is just one of the chunks of a multi-chunk backup. You have
to start from the first one.
--
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: please help me - amrestore
Sorry. That should have been: amrestore -p \ /amanda_holding/20001215/duchamp.tomandandy.com._Local_Users.0 \ | tar xvf - JJ
Fastsor DLT4000 and linux, how?
Hello, i am using amanda2.4.2 on a Linux Suse7.0 system. (amanda is compiled by hand, no rpm) I am now trying to get my Faststor DL4000 7-tapes-changer to work. I am using chg-zd-mtx. But i am still having problems like... tux06:/tmp/amanda # tail -f changer.debug Args - -info - info 1 Args - -slot current - loaded 1 Args - -slot next - loaded 1 Args - -slot clean - loaded 1 - load 7 - status 1 - resmtx: Storage Element 7 is Empty - load 2 - status 0 - resLoading Storage Element 2 into Data Transfer Element...done - rew 2 /bin/dd: /dev/nst0: Input/output error 0+0 records in 0+0 records out Args - -slot next - loaded 2 - unload 2 - status 1 - resUnloading Data Transfer Element into Storage Element 2...mtx: Request Sense: 70 00 05 00 00 00 00 0E 00 00 00 00 3B 90 00 00 00 56 00 00 I changed chg-zd-mtx with $MT $MTF $tape offline calls in front of any $MTX call, as the Changer was blocking the mtx-commands otherwise tux06:/tmp/amanda # mtx -f /dev/sg1 inquiry Vendor ID: 'ADIC', Product ID: 'FastStor DLT', Revision: '0119' Any comments? -- Martin Koch Systemadministration MOSAIC SOFTWARE AGFeldstrasse 8 D-53340 Meckenheim Tel. 02225/882-0 Fax. 02225/882-201
stctl question
Title: stctl question Is there anyone that is using the 'stctl' driver for their changer that has ever seen this problem before: I have already installed the driver stctl and when I issue the 'stc status' command I get a report of my changer not having any tapes in it. This is not true, I have it loaded full with tapes. I'm just curious as to if anyone has ever seen this before and might know what to do in this case. Thanks all! Christopher A. Los Angeles, Ca.
Re: Client constrained ?
* Alexandre Oliva [EMAIL PROTECTED] (Wed, Jan 31, 2001 at 08:23:27PM -0200) On Jan 31, 2001, Gerhard den Hollander [EMAIL PROTECTED] wrote: (client constrained she tells me). Can anyone tell me how I can tell amanda to use more dumpers at once ? Increase maxdumps in some dumptype of that host. Thats' what I like about this list, rapid turn artound time, and to the ppoint answers that correctly solve the problem ;) Try finding that level of support for a commercial product ;) Gerhard, @jasongeo.com == The Acoustic Motorbiker == -- __O Standing above the crowd, he had a voice so strong and loud =`\, we'll miss him (=)/(=) Ranting and pointing his finger, At everything but his heart we'll miss him
Re: Need some help with a new changer
Are you using the latest MTX version? Is the problem mtx itself? (Can you run "mtx load x", "mtx unload x" etc? Or is the problem with the changer script? Are you using the latest version? You can get it at http://www.noc.isite.net/?Projects On Wed, Jan 31, 2001 at 07:32:44PM -, [EMAIL PROTECTED] wrote: I'm new to amanda and really can use some help installing a new changer. The new unit is a Overland Minilibrary (15-slot) with 1 DLT-7000 drive. Our old unit is working fine but our filesystems have grown a lot. The new unit is a model 7115. The problem appears to be my mtx configuration. Any help is greatly appreciated!!! Sam Lauro -- Joe Rhett Chief Technology Officer [EMAIL PROTECTED] ISite Services, Inc. PGP keys and contact information: http://www.noc.isite.net/Staff/
Re: Speeding up the dumpprocess ?
* Mitch Collinsworth [EMAIL PROTECTED] (Thu, Feb 01, 2001 at 09:31:52AM -0500) The avg dump rate is listed as 2M/s The avg tape rate is listed as 10M/s ... is there any way to speed up the dump process ? If you take a closer look at the numbers you'll see these are actually averages over the individual file systems' dump rates, without taking into account amount of data dumped for each data point in the average. Put more plainly, these numbers are really bogus. To really know how fast your dumps are going, look down the KB/s column. Your numbers look pretty good to me. You've got better than 1 MB/s on all your big dumps. True. The point is though that 2.3M/s (which Im getting at the 0 dump of the biggest one) translates to about 10G/hr, which means it takes 11 hours to dump the largest slice. Dumping the results from that from holding disk to tape takes less than 3 hours. In other words, it's fast, but I'd like it even faster ;). I guess splitting that slice into a bunch of smaller slices would help Gerhard, @jasongeo.com == The Acoustic Motorbiker == -- __O I'm preparing to fly, under my own steam =`\, I'm preparing to fly, into the dream (=)/(=) I'm back in the saddle, I'm out in the clear I've got no regrets, I've got no fear
Re: modification
i did a modification in the amstatus script, it looked for amdump file by default, but amanda creates amdump.1, as the newer file, so if i typed amstatus Diario, (Diario is where i have the amanda.conf), it said that the $logdir/amdum doesn't exist, so you had to type the commad with the file option. The amstatus command is normally used while amdump is running to find out how far along it is, so going after "amdump" is probably the right default. I doubt if many people (although I'm one of them) use it to post-process a completed run. It seems to me that adding "--file amdump.1" to the command line is reasonable requirement to do this. You do realize you only have to enter "amdump.1", not the full path to the file, right? Of course, one of the beauties of open source is that if you disagree, you're free to make it do whatever you want :-). John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Speeding up the dumpprocess ?
Thanskl for all who delivered suggestions for this: To really know how fast your dumps are going, look down the KB/s column. Your numbers look pretty good to me. You've got better than 1 MB/s on all your big dumps. True. The point is though that 2.3M/s (which Im getting at the 0 dump of the biggest one) translates to about 10G/hr, which means it takes 11 hours to dump the largest slice. Wow, that's one big partition. You _could_ cut it up into smaller partitions or use the GNU tar top level directory trick but you probably have your reasons why those solutions won't work for you. OK, maybe a description of th setup might help. We've got 1 (one) big server (sun UE450) it's got 2 scsi ontrollers, and we stuck in an additional 2 dual scsi cards giving us 6 scsi channels. They're all ultra LVD (that's 160 Mbaud unles Im deeply mistaken ) Controller 0 - 4 internal 4 G disk 1 disk split up into different slices other 3 disks striped to a 12 Gb disk Controller 1 - CDrom drive - Mammoth tape drive - Mammoth tapedrive Controller 2 - empty Controller 3 - 2 18G disks - 1 36G disk partitioned into 2 18G disks Controller 4 - LTO tapedrive Controller 5 - Zero downtime RAID array (420 G) [this puppy rules, see below for rant ;) ] For the 420G raid array I use gnutar (and a patched sendsize to use calcsize to calculate the estimates, see my previous posts on this) to backup the toplevel subdirs. The RAID array is raid 5 (w/ hotspare). The holding disk is on that same raid array (and on the same partition) I've checked, and it's not the scsi controller bandwidth that's the limiting factor. [that is, if amdump is dumping to holding disk, I can start moving data to and from that disk, whitout the amdump performance dropping noticably] * Johannes Niess [EMAIL PROTECTED] (Thu, Feb 01, 2001 at 08:01:39PM +0100) Let's do the math: We need 10 M/s sustained transfer rate from holding disk to the tape and 10 M/s from data disk to holding disk. A 80 M/s SCSI bus should be able to do that. 20 M/s with a lot of seeks are quite a load for a single holding disk. Depending on you holding disk hardware I'd guestimate 3 M/s a reasonable throughput under these circumstances. Im getting 7 M/s to tape, while the simultaneous write to the holding disk is around 3 M/s Even if there are 2 dumpers dumping (giving 6 M/s - holding disk) I easily get 7 M/s to tape. I upped maxdumpers to 4 and rearranged the toplevel dir layout on the big disk (i split the 110G dir into 2 dirs of ~ 55G each). Let's see how weel that performs .. If upping maxdumpers to 4 is indeed bottlenecking the disk (which i can easily see if the dumper speed average is dropping instead of staying more or less the same) I can lower the number again. Nobody asked about seek problems on your data disks. It definitely kills performance to dump two partitions of the same disk at the same time. Amanda's default value of the spindle parameter is not at an intuitive value: Been there, tried that, sent the postcard ;) dumping a single disk at once gives me roughly the sme performance as dumping 2 disks simultaneously, even to the same holding disk. Johannes Niess P.S: Feel free to make a faq-o-matic section on performace out of this. What about a weekly post of the FAQ to this list? I am actually keeping notes on this, and I plan to put it all together into some larger document. Im proobaly gonna stick it on my webpage (along with all the other useful hints and tips I've found about amanda sofar). Ill happily make it into a faq-o-matic or write it up a bit more detailed for inclusion with the amdna docs. Whatever is most appropriate. (but currently i's not yet finished , and im still experimenting. Gerhard, @jasongeo.com == The Acoustic Motorbiker == -- __O Standing above the crowd, he had a voice so strong and loud =`\, we'll miss him (=)/(=) Ranting and pointing his finger, At everything but his heart we'll miss him
A Perl-based changer (perhaps FreeBSD-centric)
I've been meaning to submit this for about two years.. it's probably not as useful anymore, but who knows. When we set up Amanda here, ISTR we couldn't get the chg-scsi thing to work happily with our FreeBSD systems and an Exabyte EHB-10h. So I threw together a Perl module and changer script to do the job. It's been taking care of our daily backups since April '99. Maybe someone else having trouble with the changer stuff will be able to use it, or at least bend it to their needs. I find straightforward Perl easier to modify than a complicated C program slinging pointers around and core dumping. It can be found at: http://www.masto.com/dist/nm-changer/ Enjoy, and thanks to the Amanda team for a really impressive piece of software. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/
RE: driver: dumper0 died while dumping
just a thought, that may not be the answer... try setting your chunksize to something like 1Gb (or 200M, if that works for you). This means that if it's backing up 2.5G, no individual file in the holding disk area will be bigger than that chunksize. We needed it because our backup was trying to write chunks 3 or 4G big, and failing. e2fs can't currently hold bigger than a 2G file, can't provide any advice on other filesystems, however. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Robinson David F Dr DLVA Sent: Thursday, 1 February 2001 08:07 To: '[EMAIL PROTECTED]' Subject: RE: driver: dumper0 died while dumping This problem goes away if I specify a much lower value for the 'use' parameter on the holdingdisk. The original value specified was 30Gb. This would be more than enough space for the backup (approximately 2.5Gb). If I switch this value to 200Mb the backup works. If I use amstatus to watch the dump as it proceeds, it appears that the entire dump is being written to the holding disk. The dump is apparently dying when trying to move the file to the tape. Any suggestions as to why this behaves this way? David
unsubscribe
unsubscribe
Re: Speeding up the dumpprocess ?
Gerhard den Hollander [EMAIL PROTECTED] writes: * Johannes Niess [EMAIL PROTECTED] (Thu, Feb 01, 2001 at 04:01:03PM +0100) My first thought was to disable compression, but that's already done. What's your network technology? 2 MBytes/sec is not the optimum They're all local disks (Wide scsi 2, so that's 80 Mbaud IIRC) On the other hand disk speed might be the bottle neck. I'd run bonnie on the clients and the server holding disk. I assume you've checked SCSI settings/errors/DMA for IDE controllers etc. of the holding disk. Let's do the math: We need 10 M/s sustained transfer rate from holding disk to the tape and 10 M/s from data disk to holding disk. A 80 M/s SCSI bus should be able to do that. 20 M/s with a lot of seeks are quite a load for a single holding disk. Depending on you holding disk hardware I'd guestimate 3 M/s a reasonable throughput under these circumstances. Two simultaneous runs of bonnie (read/write) on the same disk could give reasonably good values. How does amanda determine the block size of writes/reads? I hope that there are large buffers on all sides between client, server and tape writing parts. RAID in stripping (or concatenation) mode might help on the holding disks. Different physical holding disks might do the same trick. What exactly is meant by "round robing" of holding disks? It looks like you need two holding disks for maximum performance: 1 for writing to , one for simultaneous reads. In your case I'd set maxdumps=1, too. The extended formula is N = D + 1, where N is the optimum number of independend holding disks and D is the number of simultaneous dumpers, 1 is for the taper reading data. Nobody asked about seek problems on your data disks. It definitely kills performance to dump two partitions of the same disk at the same time. Amanda's default value of the spindle parameter is not at an intuitive value: (man amanda, disk list parameters) spindle Default: -1. A number used to balance backup load on a host. Amanda will not run multiple backups at the same time on the same spindle, unless the spin dle number is -1, which means there is no spindle restriction. This assumption might date from the times when disks where too small to be split into pieces. IMHO 1 is a more reasonable default as it does only one dump at a time on a host. HTH, Johannes Niess P.S: Feel free to make a faq-o-matic section on performace out of this. What about a weekly post of the FAQ to this list?
Problems with amdump
Hello folks-- Problems with amdump from HP-UX 11.0 server to BSD/OS 4.2 client (named ritchie). The 'amcheck' commands succeeds. The 'amdump' connects and looks like the index is started, but that is about it. After 10 minutes, the 'amdump' quits. On the client, the sendbackup.debug file says after the runtar command: sendbackup [pid]: index tee cannot write [Broken pipe] sendbackup [pid]: error [/usr/local/bin/tar got signal 13] I read in the archives that this error is usually caused by bad tapes, or write protect etc. I know that the tape is in good condition, because I tar'd to it before labeling. The /var/adm/amanda/RitchieWeekly/index/ritchie/_ directory does not actually contain an index. The amdump.1 file has the following errors: driver: result time 548.663 from dumper0: FAILED 00-1 [data read: Connection reset by peer] dumper: kill index command This is my first backup over the network, so I am a little clueless. cjw
Re: Barcode support outside of chg-scsi
That's essentially the same things I had to do, the timeout and the changing of
the wording returned from mtx. The only other thing I had to change was the
case test at line that read:
[$firstslot-$lastslot])
load=$1
;;
Because of the wording of the [test]), the highest slot number you can have
would be 9. Since I have 30, I had to change it to the below:
$[${whichslot}])
if [ $whichslot -gt $lastslot ] || [ $whichslot -lt $firstslot ]; then
echo "0 Slot $whichslot is out of range ($firstslot - $lastslot)"
exit 1
else
loadslot=$whichslot
fi
;;
This was because if your $lastslot 9, the test doesn't work right. For me,
$lastslot is 30, so the test was saying " [1-30]) which is "1-3 _or_ 0" in
shell pattern matching. It took me forever to notice this, and I pulled some
hair out wondering why I couldn't load a tape higher than slot 3.
Thanks...
On Thu, 01 Feb 2001, Doug Munsinger wrote:
Jason -
having just been through "changer hell" I'm copying some mail I just sent
to Joe Rhett re: chg-zd-mtx and barcodes -
MAYBE it will help resolve what you are going through now.
I fought with chg-scsi and chg-zd-mtx for about a week before dropping back
and getting chg-manual to fully work first.
Here's what I just finished:
Hope this helps.
--doug
___
Joe -
I downloaded the improved mtx script from the link you gave in this post -
MUCH THANKS as the site also gave specific instructions for placing
at amanda-src/client-src/chg-zd-mtx.sh.in
and then run configure. This came very close to working as is.
The timing worked well as I was already re-installing 2.4.2p1 upgrades
anyway...
I found two flaws in the code for my specific tape drive and changer.
I have an Ecrix VXA autopak library with a single Ecrix VXA tape unit
installed - with a barcode reader.
I managed to get chg-manual running consistently and getting good backups
first, which let me know that the tape drive and amanda were doing well,
before attempting for a second time to get the changer to cooperate.
I also installed mtx 1.2.10 and tested and verified this would work... So
at least I could get an e-mail that the tape needed changing and then log
in and accomplish that from home...
What I changed to make the chg-zd-mtx script work was to add a TIMEOUT
variable to use in a sleep command in loadslot as follows:
# Now rewind and check
echo " - rewind $loadslot" $DBGFILE
echo " - sleeping TIMEOUT: $TIMEOUT
seconds..." $DBGFILE
sleep $TIMEOUT
echo " - rewind..." $DBGFILE
$MT $MTF $tape rewind
echo "$loadslot" $slotfile
echo "$loadslot $tape"
exit 0
Otherwise I would consistently get
"/dev/nst0: Input/output error"
on any rewind or tape change by the script
This MOSTLY allowed the script to work, except -
I have a barcode reader.
The result of an mtx status command with a barcode reader is different than
without - at least when the tapes have barcodes -
here's what the mtx -f /dev/sg1 status result looks like (with barcode)
Data Transfer Element 0:Full (Storage Element 11 Loaded):VolumeTag = 09
Storage Element 1:Full :VolumeTag=00
Storage Element 2:Full :VolumeTag=01
Storage Element 3:Full :VolumeTag=02
Storage Element 4:Full :VolumeTag=03
Storage Element 5:Full
Storage Element 6:Full
Storage Element 7:Full
Storage Element 8:Full
Storage Element 9:Full
Storage Element 10:Full
Storage Element 11:Empty
Storage Element 12:Full
Storage Element 13:Full
Storage Element 14:Full
Storage Element 15:Full
which caused the sed command to give back:
[amanda@ford amanda]$ mtx -f /dev/sg1 status | sed -n 's/Data Transfer
Element 0:Empty/-1/p;s/Data Transfer Element 0:Full (Storage Element \(.\)
Loaded)/\1/p'
1:VolumeTag = 00
which won't work...
here's the change:
readstatus() {
EMP_FULL=`$MTX status | grep "Data Transfer Element" | awk '{
print $4 }' | awk -F: '{print $2 }'`
if [ $EMP_FULL = "Empty" ]; then
usedslot="-1"
fi
if [ $EMP_FULL = "Full" ]; then
usedslot=`$MTX status | grep "Data Transfer Element" | awk
'{ print $7 }'`
fi
I'll include the full script below this.
I thought this might come in handy and might also be something you would
want to include in the upkeep of chg-zd-mtx.
--doug
Doug Munsinger
egenera, Inc.
[EMAIL PROTECTED]
563 Main Street, Bolton, MA 01740
Tel: 508-786-9444 ext. 2612
OR 508-481-5493
fax: 978 779-9730
At 03:54 PM
