Indexes not being made
Fellas-
My indexes aren't being created. Specifically, the files are being
created, but not populated with index data (from client host "albatross"
sendbackup debug):
sendbackup: started index creator: "/usr/sbin/ufsrestore -tvf - 2>&1 |
sed -e '
s/^leaf[ ]*[0-9]*[ ]*\.//
t
/^dir[ ]/ {
s/^dir[ ]*[0-9]*[ ]*\.//
s%$%/%
t
}
d
'"
sendbackup: spawning /usr/sbin/ufsdump in pipeline
sendbackup: argument list: dump 0usf 1048576 - /dev/rdsk/c0t0d0s7
sendbackup: index pipe returned 36096
In /var/adm/amanda/wink/index:
$ ls -lR /var/adm/amanda/wink/index
/var/adm/amanda/wink/index:
total 4
drwxr-sr-x 5 amanda amanda 512 Jul 23 14:50 albatross
drwxr-sr-x 5 amanda amanda 512 Jul 20 15:58 wind
/var/adm/amanda/wink/index/albatross:
total 6
drwxr-sr-x 2 amanda amanda 512 Jul 26 14:09 _
drwxr-sr-x 2 amanda amanda 512 Jul 26 00:46 _export_home
drwxr-sr-x 2 amanda amanda 512 Jul 26 15:21 _usr
/var/adm/amanda/wink/index/albatross/_:
total 0
-rw--- 1 amanda amanda 0 Jul 23 13:28 20010723_0.gz
-rw--- 1 amanda amanda 0 Jul 24 00:46 20010724_1.gz
-rw--- 1 amanda amanda 0 Jul 25 09:59 20010725_0.gz
-rw--- 1 amanda amanda 0 Jul 25 16:15 20010725_1.gz
-rw--- 1 amanda amanda 0 Jul 26 00:46 20010726_1.gz
/var/adm/amanda/wink/index/albatross/_export_home:
total 0
-rw--- 1 amanda amanda 0 Jul 23 13:32 20010723_0.gz
-rw--- 1 amanda amanda 0 Jul 24 00:46 20010724_1.gz
-rw--- 1 amanda amanda 0 Jul 25 10:01 20010725_1.gz
-rw--- 1 amanda amanda 0 Jul 25 16:15 20010725_2.gz
-rw--- 1 amanda amanda 0 Jul 26 00:45 20010726_2.gz
... and so on.
I have configured all disks (via global) to produce indexes.
$ amadmin wink disklist|grep index
index YES
index YES
index YES
index YES
index YES
index YES
As above, the amanda user does have write access to the disk, and there is
enough space:
$ df -k /var
Filesystemkbytesused avail capacity Mounted on
/dev/dsk/c0t0d0s0 246167 129265 9228659%/
So ... what's up with that?
--
Austin David -- Sr. Systems Architect
Wink Communications
[EMAIL PROTECTED]
(510) 337-6334
Disk Not Found Error
When ever I run amcheck I get the following error: ERROR: wildcat: [can not access hdb1 (hdb1): No such file or directory] In my disklist file if I put a "/" instead of the device name amcheck runs fine, but when I run amdump and try and back up the device I get the following error message: wildcat / lev 0 FAILED [disk / offline on wildcat?] Any ideas? Travis Rail
Re: problem with changer
>Hi, I'm an amanda newbie running it on ... What version of Amanda? >amcheck-server: slot : could not read result from >"/usr/local/libexec/chg-zd-mtx" What happens if you do this (as the Amanda user): cd /usr/local/libexec/chg-zd-mtx -reset /usr/local/libexec/chg-zd-mtx -slot 4 Depending on what version of Amanda you're using, there should be a debug file named /tmp/amanda/changer.debug.drive$drivenum changer.debug (in either /tmp or /tmp/amanda). What's in it (you may want to zero it out before doing the above -- it just keeps getting appended to)? >Ignacio Tripodi John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Amdump question
Hello Amanda Users, I'm trying to dump the entire contents of the host onto the holding disk, but I got this error: ./amdump set1 insert tape into slot 0 and press return When I ran amcheck before running amdump this is the result: ./amcheck set1 Amanda Tape Server Host Check - WARNING: tapedev is /dev/null, dumps will be thrown away Holding disk /geo1/backup/spindltop: 23053588 KB disk space available, that's plenty NOTE: skipping tape checks WARNING: info file /usr/adm/amanda/set1/curinfo/spindletop/_usr/info: does not exist WARNING: info file /usr/adm/amanda/set1/curinfo/spindletop/_/info: does not exist WARNING: info file /usr/adm/amanda/set1/curinfo/spindletop/_geo1_backup_spindltop/info: does not exist Server check took 0.040 seconds Amanda Backup Client Hosts Check Client check: 1 host checked in 0.085 seconds, 0 problems found (brought to you by Amanda 2.4.2) =>Any ideas?? Thanks a lot, Nupur
Re: badly formatted requests
>btw, does amanda normally write sendbackup.debug >by opening and closing on each write? ... It depends. Prior to 2.4.2p2 it would do this unless you built it with --with-pid-debug-files, in which case it would create files with unique names. At 2.4.2p2, the debug file names always contain a timestamp and are unique (Amanda also cleans up after itself). >/usr/lib/amanda/sendsize: version 2.4.1p1 >REQ packet is bogus: bad level Ahh. The REQ (request) packet is listed in the corresponding amandad*debug file, but if you've run amcheck it will be clobbered from the run this morning (look for the "SERVICE sendsize" line). Hopefully the run tonight will leave it alone and you can grab it. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: advfs.diff patch
>When I tried installing the above patch, I got this error while running >make and make install. ... Are you sure you are working with the 2.4.2p2 sources? >Would amanda still work? Not likely. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: advfs.diff patch
When I tried installing the above patch, I got this error while running make and make install. Would amanda still work? Making install in client-src /sbin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I../config -I../common-src-g -c -o getfsent.lo getfsent.c cc -DHAVE_CONFIG_H -I. -I. -I../config -I../common-src -g -c getfsent.c -o getfsent.o cc-1162 cc: ERROR File = getfsent.c, Line = 489 Too few arguments in function call. if(search_fstab(str, &fsent)) ^ cc-1162 cc: ERROR File = getfsent.c, Line = 501 Too few arguments in function call. if(search_fstab(str, &fsent)) ^ 2 errors detected in the compilation of "getfsent.c". *** Error code 1 (bu21) *** Error code 1 (bu21) On Thu, 26 Jul 2001, John R. Jackson wrote: > >How do you apply this patch? > > Cd to the top of your Amanda source tree (the directory with the > ./configure script). Then run patch with advfs.diff as stdin. Depending > on what version of patch you have, you may need "-p0" on the command line. > > Then remove config.cache (or "make distclean"), run "make" and (as root) > run "make install". > > Note that this patch applies to the client, so that's what needs to be > updated, not the server (although updating the server as well won't hurt). > > >Travis > > John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] >
Re: badly formatted requests
>Two letters just came in with the same Subject but (somewhat) different >From: values. i apologize. i was having much trouble with the list and tried sending through egroups (yahoo). >There are a couple of possibilities. One is that you've added some >"disks" and the request (or corresponding reply) is now longer than a >UDP packet (roughly 65 KBytes). i did add a disk recently, but it is on a remote client, which doesn't appear to be having problems. >Look for "Amanda 2.4 REP HANDLE ...". Following that is the reply >being sent back to the server. Copy from the next line to the "" >line to another file and see how big it is. wc -c reports 2959 bytes, but as i mentioned in one of the two messages i posted (again, sorry everyone), the problem only seems to arise when actually backing up, as opposed to running amcheck (which subsequently overwrites the amandad.debug file, so the log only reflects the successful amcheck run). >The other thing you can do is look through the reply and see if anything >looks goofy. It should just be a bunch of entries like this: > > / 0 SIZE 606750 > / 3 SIZE 13030 > /opt 0 SIZE 690390 > /opt 1 SIZE 172 > >(disk, level, "SIZE" and estimated KBytes) i am not seeing anything that looks like this (a size report) in any of the logfiles. sendsize.debug is still timestamped with the last 'real' backup request time (early this morning). this may be normal, however (ie, amcheck does not request sizes). btw, does amanda normally write sendbackup.debug by opening and closing on each write? it seems that there is only one entry (presumably the last) in the sendbackup.debug log (which corresponds to the last successful backup a couple days ago.) >If the problem is the request/response has gotten too large, the current >242 CVS source tree contains a workaround. You could either upgrade >your server to that, or I can probably find the patch in the mailing >list archive and you could apply it (assuming you're running 2.4.2p2). i probably forgot to mention in the last *two* messages that sendsize.debug says: sendsize: debug 1 pid 12995 ruid 34 euid 34 start time Thu Jul 26 00:06:44 2001 /usr/lib/amanda/sendsize: version 2.4.1p1 REQ packet is bogus: bad level sendsize: pid 12995 finish time Thu Jul 26 00:06:45 2001 which may just be a general parse error on an oversized packet, if that is the case. unfortunately, i can't run amdump at the moment, so i will have to wait until tonight's backup to get a a look at the troublesome amandad.debug. thanks john, i appreciate your help. -c __ Get Your FREE FlashMail Address now at http://www.flashmail.com It's Free, Easy, & Fun !!!
problem with changer
Hi, I'm an amanda newbie running it on a Solaris 8 server with a Sun STORedge L9 tape drive and controller (that's actually a Quantum DLT 8000 tape drive coupled with HP Changer robotics). The problem I have is with the tape changer, it seems that amcheck, amtape and other programs don't understand the output of the changer script I'm using (chg-zd-mtx). If I don't put manually the tape amanda is expecting in the drive, I got the following after running amdump: *** A TAPE ERROR OCCURRED: [label WT1004 or new tape not found in rack]. Some dumps may have been left in the holding disk. Run amflush to flush them to tape. The next 2 tapes Amanda expects to used are: WT1004, WT1005. In this case, both tapes WT1004 and WT1005 were in slots inside the Sun STORedge, but it didn't find them. If I run an amcheck, I get the following: Amanda Tape Server Host Check - Holding disk /backup: 77994756 KB disk space available, using 77993732 KB amcheck-server: slot 3: date 20010723 label WT1003 (active tape) amcheck-server: slot : could not read result from "/usr/local/libexec/chg-zd-mtx" amcheck-server: slot : could not read result from "/usr/local/libexec/chg-zd-mtx" amcheck-server: slot : could not read result from "/usr/local/libexec/chg-zd-mtx" amcheck-server: slot : could not read result from "/usr/local/libexec/chg-zd-mtx" amcheck-server: slot : could not read result from "/usr/local/libexec/chg-zd-mtx" amcheck-server: slot : could not read result from "/usr/local/libexec/chg-zd-mtx" amcheck-server: slot : could not read result from "/usr/local/libexec/chg-zd-mtx" ERROR: label WT1004 or new tape not found in rack (expecting tape WT1004 or a new tape) NOTE: skipping tape-writable test Server check took 882.012 seconds It seems that amcheck doesn't understand the output of chg-zd-mtx, does anyone know if there's another script that supports barcodes reader? Any idea 'bout how to solve this? Thanks!! Ignacio Tripodi
Re: badly formatted requests
Two letters just came in with the same Subject but (somewhat) different From: values. I'm hoping they are really from the same person. >here are two error lines typical of the two types (local and >smb) of shares: > >thehost //axon/Users lev 0 FAILED [badly formatted response from thehost] > >thehost /usr/local/data17 lev 0 FAILED [badly formatted response from theh >ost] What version of Amanda are you using? Take a look at the /tmp/amanda/amandad*debug file on "thehost" (the client). At the top it should say the SERVICE is "sendsize". There are a couple of possibilities. One is that you've added some "disks" and the request (or corresponding reply) is now longer than a UDP packet (roughly 65 KBytes). Look for "Amanda 2.4 REP HANDLE ...". Following that is the reply being sent back to the server. Copy from the next line to the "" line to another file and see how big it is. The other thing you can do is look through the reply and see if anything looks goofy. It should just be a bunch of entries like this: / 0 SIZE 606750 / 3 SIZE 13030 /opt 0 SIZE 690390 /opt 1 SIZE 172 (disk, level, "SIZE" and estimated KBytes) If the problem is the request/response has gotten too large, the current 242 CVS source tree contains a workaround. You could either upgrade your server to that, or I can probably find the patch in the mailing list archive and you could apply it (assuming you're running 2.4.2p2). >cj John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: advfs.diff patch
>How do you apply this patch? Cd to the top of your Amanda source tree (the directory with the ./configure script). Then run patch with advfs.diff as stdin. Depending on what version of patch you have, you may need "-p0" on the command line. Then remove config.cache (or "make distclean"), run "make" and (as root) run "make install". Note that this patch applies to the client, so that's what needs to be updated, not the server (although updating the server as well won't hurt). >Travis John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
badly formatted requests
hello all. i've searched around and i can't seem to find too much regarding this subject. the server that runs amandad also backs itself up, and none of the shares local to the backup server, in addition to the smbclient windows shares it backs up are not being backed up due to this type of funny business: thehost //winbox/profiles lev 0 FAILED [badly formatted response from thehost] thehost /usr/local/data17 lev 0 FAILED [badly formatted response from thehost] the only errors are on the backup server; all other clients are being backed up without an problem (well, without complaint). this has happened every night for the past three nights (nightly backups). i don't recall changing anything on the server side, but i did add another client to the list, but there were several days without event before this came about. someone had problems regarding bad request packets that were traced down to exclude entries. that does not seem to be the case. also, running amcheck does not report problems, only when backups are actually run. unfortunately amcheck overwrites amandad.debug, so i am only left with the debug session of the successful selfcheck from amcheck. i'll have to wait until tonights (predicted) failure to overwrite (i can't afford to dump during the day...). does anyone have any ideas anyway about this? the especially odd thing to me is that amcheck succeeds, but the backups fail on the backup server. thanks in advance -c
advfs.diff patch
How do you apply this patch? patch -l client-src/getfsent.h advfs.diff Travis
badly formatted requests
this just popped up the other day, and happened again with last night's run. i don't recall if i changed anything, but i am assuming that i must have. here are two error lines typical of the two types (local and smb) of shares: thehost //axon/Users lev 0 FAILED [badly formatted response from thehost] thehost /usr/local/data17 lev 0 FAILED [badly formatted response from thehost] unfortunately, the backups of all the shares on the backup server itself (which includes all our smbclient windows shares) are being skipped accordingly (of course). does anyone have a clue to what this would be caused by (so i can get it fixed ASAP)? thanks in advance cj __ Get Your FREE FlashMail Address now at http://www.flashmail.com It's Free, Easy, & Fun !!!
Re: amdump taking a long time
>So how do I get the CVS version (2.4.2 preferably) ? http://amanda.sourceforge.net/fom-serve/cache/136.html http://amanda.sourceforge.net/fom-serve/cache/156.html http://amanda.sourceforge.net/fom-serve/cache/170.html You want "-ramanda-242-branch". You will need a very recent version of automake. I build from CVS: pserver:[EMAIL PROTECTED]:/cvs/automake And I use the stock autoconf-2.13. >Gerhard den Hollander John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
SCSI sense error with OnStream ADR30
Hi, I'm trying to get a Onstream ADR30i SCSI drive to under Debian 2.2 with kernel 2.2.19 and Amanda 2.4.1p1. I have an Inition controller and the drive is all new. It works fine when I do a amdump, but amverify doesnt work. I get the following errors: st0: error with sense data: Info fld=0x1, current st09:00; sense key medium error Additional sense indicates unrecovered read error. This is followed by a couple of kernel messages like this: scsi: aborting command due to timeout pid 2109, scsi0 channel0, id4, lun0 read (6) 01 00 00 40 00 And then the scsi host is reset. There might be a couple of mistakes in the above since it's a transcript of the screen. The machine hangs and becomes completely inaccessible after the scsi host is reset. Does anyone have a clue about what is wrong here? Rewinding the tape doesn't help. I have searched the archive and google for information, but it only seems to be about the IDE drive. (I would be surprised if patching the IDE driver would affect my SCSI drive). -- Martin Skøtt [EMAIL PROTECTED] Xenux Aps - The Linux People
Re: problems with nfs mount snap-server.
All had several responses to this, but the way that worked the best was to treat it as an smbclient. 'root' had access to the device on the nfs mount, but it still didn't seem to like it. Maybe I should upgrade the 2.4.2p2 and try again, but at the moment it works so i shan't fix it :-) Thanks for all the advice -- Martin Hepworth Senior Systems Administrator Solid State Logic Ltd +44 (0)1865 842300 Martin hepworth wrote: > > Hi all > > We've been using amanda 2.4.2.p1 for a while now and every in the garden > is rosey. > > We recently got a snap-server to try and off - load some of our desktop > machines that are being used as file servers (yes I know...). > > I'm trying to backup the snap server by mounting thing via nfs on the > amanda server itself and then simply backup the nfs mount as a normal > local filesystem. > > However when I do this is get the following error... > > /caxton lev 0 FAILED [disk /caxton offline on dns?] > > I also get this error if I use amcheck. > > Any ideas anyone??? > > BTW if you could cc me directly on any rely that would be great as I;ve > only just subscribed and not seen any messages yes so majordomo may not > have have reset the aliases. > > -- > Martin Hepworth > Senior Systems Administrator > Solid State Logic Ltd > +44 (0)1865 842300 ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **
Re: Problems with amrecover/index/amcheck after tape problems
I've pressed the "send" button too quickly and sent the answer to John only - here is a copy for the mailing list... Christina > Hi John, > > "John R. Jackson" wrote: > > > >This is the content of our tapelist file. I think it should have more than > > >one line?!? > > > > > >20010725 NEURO007 reuse > > > > Ooops. You've lost your tapelist file, which is a very bad thing. > > That's why Amanda is asking about new tapes and complaining about backups > > being overwritten. > > > > It's also why I make a backup of it (and a lot of other critical Amanda > > files) before each run and save several copies, just in case. > > Is there a list of those critical files? And maybe a description which files are > used for which purpose? Otherwise I just don't know what to backup manually > before running amanda... > > > You may be able to put it back together, though. I just tried the > > following ksh code. It finds the taper START line in each log.MMDD.NN > > file and rebuilds the tapelist file from that. > > > > rm tapelist.log > > cat log.* | grep '^START taper' | while read x x x datestamp x label x > > do > > echo $datestamp $label reuse >> tapelist.log > > done > > sort -rn < tapelist.log > tapelist.new > > > > At this point, you will hopefully have 25 tapes listed in tapelist.new. > > Look through it and make sure thing seem right. In particular, make > > sure a tape is not listed twice. > > With this script I've gathered the information from /var/log/amanda/NEURO and > .../oldlog together and got a tapelist.new which was too long (104 lines) and > removed the oldest entries and now I have a nice tapelist again :-) > Your great... > > > Check your current tapelist file. It should be owned by your Amanda user > > and mode 0600. Move it out of the way and copy tapelist.new to tapelist, > > setting the ownership and mode. > > > > Finally, try "amadmin tape" again and see if it's happier. > > ...yes, it's singing and smiling all the time and requests tape NEURO009 for > tonight (as expected :-) ) > > Just amrecover is complaining about missing logfiles. The date 2001-07-19, which > I'm interested in, isn't affected because this logfile exists. I think I could > move the missing logfiles, which have obviously been moved too early, from oldlog > to the log directory... > > Now amrecover finished successfully :-) > > Thanks a lot for your help. Using amrecover is much more fun than using > amrestore... > > Christina Rossmanith
Re: amdump taking a long time
* John R. Jackson <[EMAIL PROTECTED]> (Tue, Jul 24, 2001 at 03:15:42PM -0500) > And remember that when you need to make mods to a Makefile, they need to > be to Makefile.am (which is only in the CVS), not Makefile.in. Which, > in turn, means you need to be conversant with automake (another of life's > adventures :-). Which means it's probably a good idea if I get everything out of CVS and try to amke it wokr with the CVs version. So how do I get the CVS version (2.4.2 preferably) ? (I know how to use CVS, I just dont know how to get into amanda CVS) Kind regards, -- Gerhard den Hollander Phone +31-10.280.1515 Global Technical SupportFax +31-10.280.1511 Jason Geosystems BV (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.
