RE: Planner FATAL protocol out of handles
> > What version of Amanda? > Pretty much the latest, 242p2, I think. > > The netusage would not affect planner. And I don't think inparallel is > involved, either. I'm pretty sure planner ships a sendsize request to > all the clients at the same time and doesn't pay any attention to either > of those limits. > > In theory, it has 1000 handles allocated (proto_init call in planner.c). > Do you have some incredibly large disklist? We have about 75 entries in the disklist. It seems to have gotten into some kind of loop and chewed up all the handles. Still not sure why. I changed a lot of parameters at the same time, increasing 'inparallel', 'netusage', and 'runtapes' significantly. Could any of those changes cause the problem? I also moved to an 'incronly' strategy, because we're backing up over a WAN and need to hold off on full backups until weekends. I'm not sure if it's related, but through many trials, I figured out that if I add a new disk with this incronly strategy, I need to force a full backup right away, or else I get "no results" back from the "getting estimates" phase, and the backup fails. It's running again now, but I had to blow away the curinfo database and rerun a full backup of everything to get it to work. Regards, Carey > > >Carey > > John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] >
Planner FATAL protocol out of handles
Hi, I've started getting "out of handle" errors from amdump, and can't seem to resolve them. It started when I tried bumping "inparallel" up to about 40 and increasing "netusage" to a high number to "open the throttle way up". amdump crashed, but now, after cranking "inparallel" back down to 10 and "netusage" down to 1 Mbps, I'm still getting these errors every time I run amdump. All the disklist entries come back with "RESULTS MISSING". I've tried rebooting the system, thinking that amanda was not letting go of some kernel resources, but the problem is still happening. Any ideas on how to resolve the problem? Thanks in advance, Carey ---- Carey Jung IT Freedom [EMAIL PROTECTED] 512.419.0070, fax 419.0080
RE: amidxtaped problem
> > >We can't seem to get amrecover to work. We have to manually load the > >correct tape and then run amrecover, because if the correct tape > is not in, > >it's not able to access the tape device. > > Amrecover (et al) do not use the Amanda tape changer software (yet). > So, yes, you have to do the mounts by hand. > I see. Thanks. > > What did you pass amrecover for the -d option? You should do something > like "-d /dev/tape0". If you didn't pass a -d option, amrecover is > getting the default tape device from what you set with ./configure, > which should have been --with-tape-device=/dev/tape0. I'll try that. By the way, since we're using an Exabyte 220 with 2 drives, if we specify /dev/tape1, should we be able to do restores whilst backups are running? Thanks, Carey
amidxtaped problem
We're running amanda 242p2 with a Linux server and Exabyte 220 tape library. We can't seem to get amrecover to work. We have to manually load the correct tape and then run amrecover, because if the correct tape is not in, it's not able to access the tape device. It appears that somewhere in the amrecover - amrestore - amidxtaped call chain, we're not getting the correct tape device to amrestore. As shown below, amrestore is getting passed a tape device of "0". This should actually be "/dev/tape0", which is specified as "config 0" in our chg-scsi.conf file. Have we misconfigured something, or is this a bug? thanks in advance, Carey bash$ cat amidxtaped.20010619100843.debug amidxtaped: debug 1 pid 30070 ruid 401 euid 401 start time Tue Jun 19 10:08:43 2001 amidxtaped: version 2.4.2p2 > SECURITY USER root > 6 amrestore_nargs=6 > -h > -p > 0 > justice > ^/home$ > 20010614 Ready to execv amrestore with: path = /usr/local/sbin/amrestore argv[0] = "amrestore" argv[1] = "-h" argv[2] = "-p" argv[3] = "0" argv[4] = "justice" argv[5] = "^/home$" argv[6] = "20010614" amrestore: could not open tape 0: No such file or directory amidxtaped: amrestore terminated normally with status: 2 amidxtaped: could not stat 0 could not stat 0 amidxtaped: pid 30070 finish time Tue Jun 19 10:08:44 2001 bash$
RE: amverify 'not at start of tape' errors
> > > we seem to get a lot of 'not at start of tape' errors > > It's not an error, just a warning that the tape section numbers that > follow do not reflect the actual tape section numbers on tape, because > you hadn't started amrestore at the beginning of the tape. It has > absolutely nothing to do with what is actually on the tape. It has to > do with whether amrestore found a tape label in the beginning of the > first section it read or not, and this tape label is only written by > Amanda in the beginning of a tape. > I'm still confused. These errors are showing up in the middle of amverify reports and consistently on the same partition, which is an smbclient partition in the middle of the tape. The label at the head of the tape is fine. (The first several filesystems check out fine. How can we correct this, even assuming it's just a warning? Here's fuller output: amverify DailySet1 Sun May 20 06:53:14 CDT 2001 Loading current slot... Using device /dev/tape0 Volume DailySet147, Date 20010519 Checked server._.20010519.1 ... ... ... Checked server.__LEAH5_C$.20010519.1 ** Error detected (server.__LEAH5_D$.20010519.1) amrestore: WARNING: not at start of tape, file numbers will be offset amrestore: 0: restoring server.__LEAH5_D$.20010519.1 gzip: stdin: decompression OK, trailing garbage ignored /bin/gtar: Skipping to next header /bin/gtar: Error exit delayed from previous errors 64+0 records in 64+0 records out Checked server.__ATHENA_G$.20010519.0 ... ... ... End-of-Tape detected.
amverify 'not at start of tape' errors
We've been running amanda 242p2 with an Exabyte 220 library for the most part with good success, but we seem to get a lot of 'not at start of tape' errors. Looking back at the amverify reports, they seem to be primarily on smbclient backups. We get frequent strange smbclient dumps due to sharing violations; could this smbclient error output data be cluttering up the backup stream? Tapes and drive are all new, and it occurs on several different tapes, so I'm confident it's not a hardware issue. Any ideas? Here's an example: DailySet152 (server.__LEAH5_D$.20010502.1): amrestore: WARNING: not at start of tape, file numbers will be offset amrestore: 0: restoring server.__LEAH5_D$.20010502.1 gzip: stdin: decompression OK, trailing garbage ignored /bin/gtar: Skipping to next header /bin/gtar: Error exit delayed from previous errors 64+0 records in 64+0 records out DailySet152 (server.__LEAH5_C$.20010502.1): amrestore: WARNING: not at start of tape, file numbers will be offset amrestore: 0: restoring server.__LEAH5_C$.20010502.1 gzip: stdin: decompression OK, trailing garbage ignored /bin/gtar: Skipping to next header /bin/gtar: Error exit delayed from previous errors 64+0 records in 64+0 records out thanks, Carey Jung IT Freedom [EMAIL PROTECTED] 512.419.0070, fax 419.0080
RE: How amanda thinks
> > >Am I > >correct, and if so how do I force amanda to do a full on the same day > >every week? > > Why would you want to do that? > Here's one example: You're backing up a number of customer servers over relatively slow WAN connections. A full backup takes 18 hours, and you don't want to choke the pipe during working hours. So you could run an incr-only strategy, then force full backups on weekends. Carey
RE: Linus Torvald's opinion on Dump.
> > >Or you could just use gtar > > As long as you don't mind altering the last access time of every file > that is backed up. > >From the gtar man page: OTHER OPTIONS --atime-preserve don't change access times on dumped files Carey
RE: amtape advance errors
> > 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. > Cool. Thanks. Will do. Carey
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
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: amtape advance errors
By the way, for what it's worth, here's our chg-scsi.conf file. Thanks. Carey bash$ cat chg-scsi.conf number_configs 2 eject 1 # Tapedrives need an eject command sleep 20 # Seconds to wait until the tape gets ready cleanmax10 # How many times could a cleaning tape get used changerdev /dev/sga havebarcode 1 labelfile /etc/amanda/DailySet1/tapelabels # Next comes the data for drive 0 config 0 drivenum0 dev /dev/tape0 startuse1 # The slots associated with the drive 0 enduse 20 # statfile/etc/amanda/DailySet1/tape0-slot cleancart 0 cleanfile /etc/amanda/DailySet1/tape0-clean usagecount /etc/amanda/DailySet1/tape0-totaltime # Next comes the data for drive 1 config 1 drivenum1 dev /dev/tape1 startuse1 # The slots associated with the drive 1 enduse 20 # statfile/etc/amanda/DailySet1/tape1-slot cleancart 0 cleanfile /etc/amanda/DailySet1/tape1-clean usagecount /etc/amanda/DailySet1/tape1-totaltime > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Carey Jung > Sent: Tuesday, April 24, 2001 11:25 PM > To: Amanda Users > Subject: amtape advance errors > > > Hi, > > We have an Exabyte 220 tape library, running chg-scsi tape changer, and > getting a tape 'advance' error at the end of amverify runs. It seems > inconsequential, but I'd like to know if there's anything we can do about > it: > > Here's the trailing snippet from amverify: > > Loading next slot... > Using device /dev/tape0 > Volume DailySet144, Date 20010419 > Checked localhost._.20010419.1 > Checked localhost._boot.20010419.1 > Checked localhost._var.20010419.1 > End-of-Tape detected. > Advancing past the last tape... > ** Error advancing after last slot > amtape: could not load slot : no slot `advance' > > Looking through the source, amverify is trying to run 'amtape > slot > advance'. Amtape is spitting out the last line above. > > Is this an amverify bug, a chg-scsi bug, both, neither, configuration > problem on our part, ...??? > > Thanks, > Carey > >
amtape advance errors
Hi, We have an Exabyte 220 tape library, running chg-scsi tape changer, and getting a tape 'advance' error at the end of amverify runs. It seems inconsequential, but I'd like to know if there's anything we can do about it: Here's the trailing snippet from amverify: Loading next slot... Using device /dev/tape0 Volume DailySet144, Date 20010419 Checked localhost._.20010419.1 Checked localhost._boot.20010419.1 Checked localhost._var.20010419.1 End-of-Tape detected. Advancing past the last tape... ** Error advancing after last slot amtape: could not load slot : no slot `advance' Looking through the source, amverify is trying to run 'amtape slot advance'. Amtape is spitting out the last line above. Is this an amverify bug, a chg-scsi bug, both, neither, configuration problem on our part, ...??? Thanks, Carey
RE: Exabyte Mammoth tape type?
Much appreciated, Ross. I didn't realize that the length should be the 'actual' length, when using s/w compression, but that makes sense, when I think about it. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Ross Johnson > Sent: Thursday, April 19, 2001 8:04 PM > To: Carey Jung > Cc: Amanda Users > Subject: Re: Exabyte Mammoth tape type? > > > Hi, > > The three parameters you need can be easily obtained or estimated. > > For no hardware compression:- > > length 2 mbytes # Raw length using 170m AME tape > # (use up to 4 mbytes with hw compression) > filemark 95 kbytes# From the Mammoth spec document > # (long filemarks to nearest kbyte) > speed 3000 kbytes # Max transfer rate from spec > # (up to 6000 kbytes with compression) > > These parameters don't appear to be critical if not exact. I think they > are used mostly by amanda for estimation, and to report the percent > tape used, etc. Speed and length using hw compression will be modified > based on your local experience. > > Hope this helps. > > Ross Johnson > > Carey Jung wrote: > > > > Hi, > > > > Anybody got a tapetype spec for an Exabyte Mammoth tape (not > Mammoth-2) that > > they would kindly share? How about some heuristics for a "good > guess" at > > parameters? Running the tapetype program seems to take hours, > even days. > > > > thanks, > > Carey > > > > > -- > -- > > > > > > Carey Jung > > IT Freedom > > [EMAIL PROTECTED] > > 512.419.0070, fax 419.0080 >
Exabyte Mammoth tape type?
Hi, Anybody got a tapetype spec for an Exabyte Mammoth tape (not Mammoth-2) that they would kindly share? How about some heuristics for a "good guess" at parameters? Running the tapetype program seems to take hours, even days. thanks, Carey ---- ---- Carey Jung IT Freedom [EMAIL PROTECTED] 512.419.0070, fax 419.0080
RE: Bandwidth throttling..
I don't think amanda actually throttles backups. That value is just used to determine how many backups to kick off at a time. If you want to try some cool traffic-shaping, look at http://www.securityfocus.com/frames/?focus=linux&content=/focus/linux/articl es/trafshap.html It shows you how to limit network traffic by source address, port, etc. I haven't played with it yet, but a really cool project would be to link it to amanda's bandwidth configuration information. We do backups of customer servers over slow WAN lines, so we'd like to use it so large backups that don't complete overnight won't choke the DSL connection for end-users during the day. Carey > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Steve Fulton > Sent: Friday, April 06, 2001 5:36 AM > To: [EMAIL PROTECTED] > Subject: Bandwidth throttling.. > > > I'm running Amanda 2.4.2 p1, and I'm having difficulting with the > "netusage" > command.. I want to throttle the bandwidth Amanda uses so it does not skew > our accounting for what machine uses how much bandwidth. But everytime > Amanda runs, it uses around 4 megabits, regardless of what > "netusage" is set > to.. > > Can anyone suggest anything or an alternative to limiting > Amanda's bandwidth > usage? > > Steve. > > >
RE: Amanda with two tape devices
> > Oh, if you have tape libraries, you'll be better off with chg-scsi. > IIRC, it can also use multiple tape drives in a single configuration > but, again, not simultaneously, unless you use separate > configurations. > Thanks. I think I'd just like to be able to run amrestore, using one drive, while the other is running amdump on the same configuration. Carey
RE: Amanda with two tape devices
> > > Can amanda use who tape devices to perform a single backup? > > You can't use them concurrently (yet), but you can set up chg-multi to > switch between tape drives automatically. That's what we do here. > Can you elaborate on this? We are just beginning to set up an Exabyte 220 tape library with 2 drives and would like to know what amanda can and can't do with them. thanks in advance, Carey
putting disklist entries on 'standby'
What's the recommended procedure for temporarily removing a disklist entry? Say, for example, a server is down for a few days, and you want to not back it up, but plan to resume backups later. 'amadmin delete' seems a bit cruel for that. My solution is to just comment out the disklist entry, but I'm not sure what effect that has on indexing, amrecover, etc. thanks in advance for any help, Carey -------- Carey Jung IT Freedom [EMAIL PROTECTED] 512.419.0070, fax 419.0080
RE:
Did somebody yell, "Fire!"? > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Daniel > Sent: Thursday, March 22, 2001 6:10 PM > To: [EMAIL PROTECTED] > Subject: > > > unsubscribe [EMAIL PROTECTED] > >
amanda dns semantics
We would like to turn off the reverse DNS resolution checking that amanda does, because frankly, it's a nuisance for us. We're doing appropriate firewalling, ipsec security, etc., via other means. In particular, even if it's just for amrecover/amindexd, is there an easy way to do this (i.e., recompile), or do we need to modify the source. If this is a braindead idea, I'd like to know that, too. Thanks in advance. Carey Jung IT Freedom [EMAIL PROTECTED] 512.419.0070, fax 419.0080
RE: amrecover/amindexd problems, 242p1
After all was said and done, it turned out that our amrecover problems had to do with reverse dns lookup errors. We had a named db misconfigured. Sorry for the waste of bandwidth. Carey
RE: amrecover/amindexd problems, 242p1
It was on the mailing list within the past couple weeks. I'll send it to you directly. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Shreedeep Bhachech > Sent: Tuesday, March 20, 2001 10:51 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: amrecover/amindexd problems, 242p1 > > > > I misspoke. We have it working now, running 2.4.2p1 plus the > > /dev/root > > patch. > What is this /dev/root patch? Where can I find it? Might be of help in > my case, maybe! > > > Carey > > > Shreedeep > > = > -+> > Shreedeep Bhachech > [EMAIL PROTECTED] > > __ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/ > >
RE: amrecover/amindexd problems, 242p1
> > We've gotten it working now, by going back to 2.4.2, applying the > /dev/root > fix, rebuilding, reinstalling, etc. I'll look at amrecover diffs between > 2.4.2 and 2.4.2p1 and see if I can track the problem down. > I misspoke. We have it working now, running 2.4.2p1 plus the /dev/root patch. It's a reverse resolution problem. Our temp fix is to create an /etc/hosts entry, and we're tracking down the reverse resolution problem now Carey
RE: amrecover/amindexd problems, 242p1
> > Amrecover is not the issue. The issue is why amindexd is quitting. I > assume both machines are connecting to the same amindexd server? Everything's happening on the same machine. The problem is not amindexd quitting, I believe, but rather amrecover not being able to connect to it. We ran another strace, this time on amrecover, that shows this. We've gotten it working now, by going back to 2.4.2, applying the /dev/root fix, rebuilding, reinstalling, etc. I'll look at amrecover diffs between 2.4.2 and 2.4.2p1 and see if I can track the problem down. Carey
RE: Failed backup of / partition
We just ran across the same problem. It's fixed in 2.4.2p1. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Shreedeep Bhachech > Sent: Monday, March 19, 2001 3:59 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: Failed backup of / partition > > > Well, I found out the source of my problem through > amcheck - dump was trying to stat /dev/root (instead > of /dev/hdaxx) which didn't work, since /dev/root > doesn't exist. > > Now that this problem is solved, though - anybody have > some idea about this /dev/root and why dump sees that > while df etc. see /dev/hdaxx? > > -Shreedeep. > > > --- "John R. Jackson" <[EMAIL PROTECTED]> > wrote: > > >could it be that linux treats / partition (and > > >therefor the disk that / belongs to) treats > > >differently, as a result it doesn't let amanda > > "read" > > >it? > > > > No. > > > > What did amcheck have to say? > > > > What's in /tmp/amanda/sendsize*debug on the client? > > > > >Shreedeep > > > > John R. Jackson, Technical Software Specialist, > [EMAIL PROTECTED] > > > = > -+> > Shreedeep [EMAIL PROTECTED] > > > > __ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/ > >
RE: amrecover/amindexd problems, 242p1
Are there perhaps index file incompatibilities between 242 and 242p1?
amrecover is working fine on the machine it was built on, but not on the
machine below, which has been running 242
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Carey Jung
> Sent: Monday, March 19, 2001 12:18 PM
> To: Amanda Users
> Subject: amrecover/amindexd problems, 242p1
>
>
> We just built 242p1 and are getting errors contacting the index
> server from
> amrecover. We get the following error:
>
> > % amrecover -C DailySet1 -s localhost -t localhost -d /dev/nst0
> > AMRECOVER Version 2.4.2p1. Contacting server on localhost ...
> > amrecover: Unexpected server end of file
>
> Here's what we see in the debug files (nothing abnormal, from what I can
> see):
>
> > % cat /tmp/amanda/amindexd.debug
> > amindexd: debug 1 pid 7914 ruid 401 euid 401 start time Mon Mar 19
> 11:27:12 2001
> > amindexd: version 2.4.2p1
> > gethostbyaddr: Success
> > amindexd: pid 7914 finish time Mon Mar 19 11:27:12 2001
>
> > % cat /tmp/amanda/amrecover.debug
> > amrecover: debug 1 pid 7912 ruid 0 euid 0 start time Mon Mar 19 11:27:12
> 2001
>
> We trussed up amindexd with strace and see the following. Any ideas,
> anybody? This is built on RH6.2 and running on another RH6.2 system.
>
> > amandadgram udp wait amanda /usr/local/libexec/amandadamandad
> > #amandaidx stream tcp nowait amanda /usr/local/libexec/amindexd
> > amandaidx stream tcp nowait root /usr/bin/strace amindexd -fo
> /tmp/amandaidx.strace > /usr/local/libexec/amindexd
> > amidxtape stream tcp nowait amanda /usr/local/libexec/amidxtaped
> amidxtaped
>
> >
> > 7914 execve("/usr/local/libexec/amindexd",
> > ["/usr/local/libexec/amindexd"], [/* 10 vars */]) = 0
> > 7914 brk(0)= 0x80622ac
> > 7914 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
> > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000
> > 7914 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such
> > file or directory)
> > 7914 open("/etc/ld.so.cache", O_RDONLY) = 4
> > 7914 fstat(4, {st_mode=S_IFREG|0644, st_size=10491, ...}) = 0
> > 7914 old_mmap(NULL, 10491, PROT_READ, MAP_PRIVATE, 4, 0) = 0x40015000
> > 7914 close(4) = 0
> > 7914 open("/lib/libm.so.6", O_RDONLY) = 4
> > 7914 fstat(4, {st_mode=S_IFREG|0755, st_size=527442, ...}) = 0
> > 7914 read(4,
> > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320F\0"...,
> 4096) = 4096
> > 7914 old_mmap(NULL, 117208, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4,
> > 0) = 0x40018000
> > 7914 mprotect(0x40034000, 2520, PROT_NONE) = 0
> > 7914 old_mmap(0x40034000, 4096, PROT_READ|PROT_WRITE,
> > MAP_PRIVATE|MAP_FIXED, 4, 0x1b000) = 0x40034000
> > 7914 close(4) = 0
> > 7914 open("/usr/lib/libreadline.so.3", O_RDONLY) = 4
> > 7914 fstat(4, {st_mode=S_IFREG|0644, st_size=171346, ...}) = 0
> > 7914 read(4,
> > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\231\0"...,
> 4096) = 4096
> > 7914 old_mmap(NULL, 146828, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4,
> > 0) = 0x40035000
> > 7914 mprotect(0x40054000, 19852, PROT_NONE) = 0
> > 7914 old_mmap(0x40054000, 20480, PROT_READ|PROT_WRITE,
> > MAP_PRIVATE|MAP_FIXED, 4, 0x1e000) = 0x40054000
> > 7914 close(4) = 0
> > 7914 open("/lib/libtermcap.so.2", O_RDONLY) = 4
> > 7914 fstat(4, {st_mode=S_IFREG|0755, st_size=12224, ...}) = 0
> > 7914 read(4,
> > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\\16\0"...,
> 4096) = 4096
> > 7914 old_mmap(NULL, 15304, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4,
> > 0) = 0x40059000
> > 7914 mprotect(0x4005c000, 3016, PROT_NONE) = 0
> > 7914 old_mmap(0x4005c000, 4096, PROT_READ|PROT_WRITE,
> > MAP_PRIVATE|MAP_FIXED, 4, 0x2000) = 0x4005c000
> > 7914 close(4) = 0
> > 7914 open("/lib/libnsl.so.1", O_RDONLY) = 4
> > 7914 fstat(4, {st_mode=S_IFREG|0755, st_size=370141, ...}) = 0
> > 7914 read(4,
> > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20?\0\000"...,
> > 4096) = 4096
> > 7914 old_mmap(NULL, 88104, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4,
> > 0) = 0x4005d000
> > 7914 mprotect(0x4006f000, 14376, PROT_NONE) = 0
> > 7914 old_mmap(0x4006f000, 8192, PROT_READ|PROT_WRITE,
> > MAP_PRIVATE|MAP_FIXED, 4, 0x11000) = 0x4006f000
> > 7914 old_mmap(0x40071000, 6184, PROT_READ|PROT_WRITE,
> > MAP_
amrecover/amindexd problems, 242p1
We just built 242p1 and are getting errors contacting the index server from
amrecover. We get the following error:
> % amrecover -C DailySet1 -s localhost -t localhost -d /dev/nst0
> AMRECOVER Version 2.4.2p1. Contacting server on localhost ...
> amrecover: Unexpected server end of file
Here's what we see in the debug files (nothing abnormal, from what I can
see):
> % cat /tmp/amanda/amindexd.debug
> amindexd: debug 1 pid 7914 ruid 401 euid 401 start time Mon Mar 19
11:27:12 2001
> amindexd: version 2.4.2p1
> gethostbyaddr: Success
> amindexd: pid 7914 finish time Mon Mar 19 11:27:12 2001
> % cat /tmp/amanda/amrecover.debug
> amrecover: debug 1 pid 7912 ruid 0 euid 0 start time Mon Mar 19 11:27:12
2001
We trussed up amindexd with strace and see the following. Any ideas,
anybody? This is built on RH6.2 and running on another RH6.2 system.
> amandadgram udp wait amanda /usr/local/libexec/amandadamandad
> #amandaidx stream tcp nowait amanda /usr/local/libexec/amindexd
> amandaidx stream tcp nowait root /usr/bin/strace amindexd -fo
/tmp/amandaidx.strace > /usr/local/libexec/amindexd
> amidxtape stream tcp nowait amanda /usr/local/libexec/amidxtaped
amidxtaped
>
> 7914 execve("/usr/local/libexec/amindexd",
> ["/usr/local/libexec/amindexd"], [/* 10 vars */]) = 0
> 7914 brk(0)= 0x80622ac
> 7914 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000
> 7914 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such
> file or directory)
> 7914 open("/etc/ld.so.cache", O_RDONLY) = 4
> 7914 fstat(4, {st_mode=S_IFREG|0644, st_size=10491, ...}) = 0
> 7914 old_mmap(NULL, 10491, PROT_READ, MAP_PRIVATE, 4, 0) = 0x40015000
> 7914 close(4) = 0
> 7914 open("/lib/libm.so.6", O_RDONLY) = 4
> 7914 fstat(4, {st_mode=S_IFREG|0755, st_size=527442, ...}) = 0
> 7914 read(4,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320F\0"..., 4096) = 4096
> 7914 old_mmap(NULL, 117208, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4,
> 0) = 0x40018000
> 7914 mprotect(0x40034000, 2520, PROT_NONE) = 0
> 7914 old_mmap(0x40034000, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED, 4, 0x1b000) = 0x40034000
> 7914 close(4) = 0
> 7914 open("/usr/lib/libreadline.so.3", O_RDONLY) = 4
> 7914 fstat(4, {st_mode=S_IFREG|0644, st_size=171346, ...}) = 0
> 7914 read(4,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\231\0"..., 4096) = 4096
> 7914 old_mmap(NULL, 146828, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4,
> 0) = 0x40035000
> 7914 mprotect(0x40054000, 19852, PROT_NONE) = 0
> 7914 old_mmap(0x40054000, 20480, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED, 4, 0x1e000) = 0x40054000
> 7914 close(4) = 0
> 7914 open("/lib/libtermcap.so.2", O_RDONLY) = 4
> 7914 fstat(4, {st_mode=S_IFREG|0755, st_size=12224, ...}) = 0
> 7914 read(4,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\\16\0"..., 4096) = 4096
> 7914 old_mmap(NULL, 15304, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4,
> 0) = 0x40059000
> 7914 mprotect(0x4005c000, 3016, PROT_NONE) = 0
> 7914 old_mmap(0x4005c000, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED, 4, 0x2000) = 0x4005c000
> 7914 close(4) = 0
> 7914 open("/lib/libnsl.so.1", O_RDONLY) = 4
> 7914 fstat(4, {st_mode=S_IFREG|0755, st_size=370141, ...}) = 0
> 7914 read(4,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20?\0\000"...,
> 4096) = 4096
> 7914 old_mmap(NULL, 88104, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4,
> 0) = 0x4005d000
> 7914 mprotect(0x4006f000, 14376, PROT_NONE) = 0
> 7914 old_mmap(0x4006f000, 8192, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED, 4, 0x11000) = 0x4006f000
> 7914 old_mmap(0x40071000, 6184, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40071000
> 7914 close(4) = 0
> 7914 open("/lib/libc.so.6", O_RDONLY) = 4
> 7914 fstat(4, {st_mode=S_IFREG|0755, st_size=4101324, ...}) = 0
> 7914 read(4,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\210\212"..., 4096) = 4096
> 7914 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40073000
> 7914 old_mmap(NULL, 1001564, PROT_READ|PROT_EXEC, MAP_PRIVATE,
> 4, 0) = 0x40074000
> 7914 mprotect(0x40161000, 30812, PROT_NONE) = 0
> 7914 old_mmap(0x40161000, 16384, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED, 4, 0xec000) = 0x40161000
> 7914 old_mmap(0x40165000, 14428, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40165000
> 7914 close(4) = 0
> 7914 mprotect(0x40074000, 970752, PROT_READ|PROT_WRITE) = 0
> 7914 mprotect(0x40074000, 970752, PROT_READ|PROT_EXEC) = 0
> 7914 munmap(0x40015000, 10491) = 0
> 7914 personality(PER_LINUX)= 0
> 7914 getpid() = 7914
> 7914 close(3) = 0
> 7914 close(4) = -1 EBADF (Bad file descriptor)
> 7914 close(5)
RE: FATAL: data write: File too large
> > > > Nope. Use 2000mb. That's a little bit less than 2Gb, so it won't > > bump into the limit. > > Confusing, but understood. I will try that, thanks. I think the amanda man page discusses this a bit, or else it's in the default amanda.conf. To allow for header information on the dump file, etc., you can't set chunksize to exactly 2GB (= 2048MB); it has to be a bit less. 2000MB is a nice, round, easy-to-remember number. Carey
RE: smbclient backups
> > >... What would the amanda developers recommend using, 2.4.2, > >2.4.2p1, or latest stable patches? ... > > Is that a rhetorical question? :-) Developers **always** recommend > you use the absolutely latest stuff so you'll test it for them :-). > > That being said, I'd recommend the latest 2.4.2 CVS sources. Which subdir, amanda, amanda-2, amanda-krb-2? They first two look the same, except in name. Carey
RE: tape slot anomaly
Also, I just ran another amcheck, after the amtape 'show' and get this: amcheck-server: slot 7: date 20010314 label DailySet104 (active tape) amcheck-server: slot 8: date 20010314 label DailySet101 (active tape) amcheck-server: slot 9: date 20010314 label DailySet102 (active tape) amcheck-server: slot 10: date 20010314 label DailySet103 (active tape) amcheck-server: slot 1: date 20010314 label DailySet104 (active tape) amcheck-server: slot 2: date 20010313 label DailySet105 (exact label match) NOTE: skipping tape-writable test Tape DailySet105 label ok Server check took 508.346 seconds Slot 1 was just reported as having DailySet108. What's up? Carey > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Carey Jung > Sent: Wednesday, March 14, 2001 10:54 AM > To: Amanda Users > Subject: tape slot anomaly > > > Can somebody explain this oddity? I run amcheck and get this: > > > [amanda@intranet DailySet1]$ amcheck DailySet1 > > Amanda Tape Server Host Check > > - > > Holding disk /home/amanda/dumps: 2514280 KB disk space available, > > using 2411880 > > KB > > amcheck-server: slot 3: date 20010314 label DailySet104 (active tape) > > amcheck-server: slot 4: date 20010314 label DailySet101 (active tape) > > amcheck-server: slot 5: date 20010314 label DailySet102 (active tape) > > amcheck-server: slot 6: date 20010314 label DailySet103 (active tape) > > amcheck-server: slot 7: date 20010314 label DailySet104 (active tape) > > amcheck-server: slot 8: date 20010313 label DailySet105 (exact > > label match) > > NOTE: skipping tape-writable test > > Tape DailySet105 label ok > > Server check took 508.647 seconds > > > > Amanda Backup Client Hosts Check > > > > Client check: 1 host checked in 0.074 seconds, 0 problems found > > > > (brought to you by Amanda 2.4.2) > > Note two DailySet104 tapes reported. So I immediately run amtape > 'show' and > get this: > [amanda@intranet DailySet1]$ amtape DailySet1 show > amtape: scanning all 10 slots in tape-changer rack: > slot 8: date 20010313 label DailySet105 > slot 9: date 20010314 label DailySet106 > slot 10: date 20010314 label DailySet107 > slot 1: date 20010314 label DailySet108 > slot 2: date 20010314 label DailySet109 > slot 3: date 20010314 label DailySet110 > slot 4: date 20010314 label DailySet101 > slot 5: date 20010314 label DailySet102 > slot 6: date 20010314 label DailySet103 > slot 7: date 20010314 label DailySet104 > > So, everything looks fine, according to amtape. > > Why is amcheck reporting incorrect slot contents, or is it? > > Carey > > >
tape slot anomaly
Can somebody explain this oddity? I run amcheck and get this: > [amanda@intranet DailySet1]$ amcheck DailySet1 > Amanda Tape Server Host Check > - > Holding disk /home/amanda/dumps: 2514280 KB disk space available, > using 2411880 > KB > amcheck-server: slot 3: date 20010314 label DailySet104 (active tape) > amcheck-server: slot 4: date 20010314 label DailySet101 (active tape) > amcheck-server: slot 5: date 20010314 label DailySet102 (active tape) > amcheck-server: slot 6: date 20010314 label DailySet103 (active tape) > amcheck-server: slot 7: date 20010314 label DailySet104 (active tape) > amcheck-server: slot 8: date 20010313 label DailySet105 (exact > label match) > NOTE: skipping tape-writable test > Tape DailySet105 label ok > Server check took 508.647 seconds > > Amanda Backup Client Hosts Check > > Client check: 1 host checked in 0.074 seconds, 0 problems found > > (brought to you by Amanda 2.4.2) Note two DailySet104 tapes reported. So I immediately run amtape 'show' and get this: [amanda@intranet DailySet1]$ amtape DailySet1 show amtape: scanning all 10 slots in tape-changer rack: slot 8: date 20010313 label DailySet105 slot 9: date 20010314 label DailySet106 slot 10: date 20010314 label DailySet107 slot 1: date 20010314 label DailySet108 slot 2: date 20010314 label DailySet109 slot 3: date 20010314 label DailySet110 slot 4: date 20010314 label DailySet101 slot 5: date 20010314 label DailySet102 slot 6: date 20010314 label DailySet103 slot 7: date 20010314 label DailySet104 So, everything looks fine, according to amtape. Why is amcheck reporting incorrect slot contents, or is it? Carey
smbclient backups
We're about to dive into smbclient backups of NT servers with amanda. We're running 2.4.2. What would the amanda developers recommend using, 2.4.2, 2.4.2p1, or latest stable patches? I recall seeing notes to the effect that some of this code has changed/been fixed recently, so I want to get any significant, smbclient-related code changes. Thanks in advance. Regards, Carey
RE: Best config for a single large root partition
> > 2.4.2 makes it possible to define dump types directly in the > disklist. And since dump types can define the filename for an exclude > file you can have seperate exclude files for each disk entry (of > course you could also define the dump types in amanda.conf and use > different dump types for each disk entry). This only works when using tar, correct? My recollection is that exclude files are not supported for 'dump' and 'smbclient' dumps. Am I right? Regards, Carey
RE: data write: File too large
> > By sheer (and extremely annoying :-) coincidence, one of my systems did > the same thing last night, but behaved "properly", i.e. all the images > smaller than 2 GBytes were flushed and removed from the holding disk. > So my best guess is this a problem that's fixed with a more recent > version of Amanda (you didn't say what you're running). > We're running 2.4.2 with no patches.
data write: File too large
We just ran across this error, because we hit the 2GB filesize limit on ext2 filesystems. After reading the man pages, we've cranked down the holdingdisk chunksize to 2000MB, which should alleviate the problem in the future. However, the behavior after this error seems a bit odd. Amanda flushed the other disk files on the holding disk to tape ok, but then also left them on the holdingdisk. amverify confirms they're all on tape, but ls shows they're all still on the holdingdisk, too. Is this normal? I would have expected amanda to flush all the files to tape, remove them from the holding disk, and then retry the level 0 backup that failed on the next run. I've forced a level 0 of the failed disk for the next run (probably unnecessary, but what the hey), but I guess I need to run amflush again on the holding disk. Regards, Carey
newbie question re barcodes
I've caught some conversation about tape libraries w/barcode readers. How are they used, and what does amanda do with them? Regards, Carey Carey Jung IT Freedom [EMAIL PROTECTED] 512.419.0070, fax 419.0080
RE: Do I get this right ?
> > > when I do amcheck and no error are reported, can I trust it 100 % > > that the backup will work? > > Well, there's always Murphy's law :-) > amcheck doesn't, by default, try to write to the tape. It just reads the label. If, for example, the write-protect tab is set on today's tape, amcheck will succeed, but the backup will fail. (Actually, if you've got sufficient holding disk space, only the flush will fail.) Carey
holding disk/taper semantics?
Could someone please clarify the holding disk/taper semantics? It appears that amanda deletes files from the holding disk as they are taped off, rather than after they are ALL successfully taped off. We noticed this when we had a tape problem. When we put a good tape in and tried to re-flush the files, they had disappeared from the holding disk. Watching the behavior since then seems to confirm this. Regards, Carey
