Re: where am i going wrong.
On Nov 3, 2000, brian <[EMAIL PROTECTED]> wrote:
> protocol packet receive: Connection refused
Some systems report this error when the UDP port to which you attempt
to send a message isn't active. Did you set up amandad in inetd, as
per the installation instructions?
> i couldnt find any help in the faq's on the website.
If this helps you find the problem, please make sure you add a new
entry in FAQ-O-Matic :-)
--
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: I had enough holding disk but part of the dump failed -
On Nov 3, 2000, "John R. Jackson" <[EMAIL PROTECTED]> wrote:
> There is not enough logging data about why the two disks were not allowed
> to go to the holding disk to tell for sure.
sda10 seems larger than MAX_INT, and chunksize was -1, IIRC. This may
have caused sda9 to fail to, even though it shouldn't.
--
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: amcheck & amverify ok, but selfcheck & amdump hang
On Fri, Nov 03, 2000 at 11:38:36PM -0500, John R. Jackson wrote: :You didn't mention if you needed the magic or not, but here it is just :in case (add to /etc/system and reboot): Oh, yes I did, thanks! :If you have multiple instances, select the specific one first, then do :the variables, e.g. for hme1: This should be interesting as there is no hme0 only hme1 (well, I suspect if I look at the box there will be an hme0 and an le0), also the router reports that it has auto-negotiated duplex mode on this port. Thanks again, -Jon -- I have no business being at work at 12am on Saturday morning (or Friday night depending on your perspective...)
Re: amcheck reports error: can't access a windows system
On Nov 2, 2000, Eric Wadsworth <[EMAIL PROTECTED]> wrote:
> ERROR: my.samba.server.here.com: [SMBCLIENT program not available]
The program name should be GNUTAR, not SMBCLIENT. If it's already
GNUTAR, make sure you've run `configure
--with-smbclient=/path/to/smbclient'
--
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: can amanda do this?
On Nov 2, 2000, "John R. Jackson" <[EMAIL PROTECTED]> wrote:
>> Mon-Sat: Incremental dump to holding disk sundev1:/dump (level 1).
>> Sun Eve/Mon AM: Full backup of everything to tape.
>> Flush incrementals to tape as well.
> It can do the first two parts with only minor hassle. However it cannot
> do the last (flush the incrementals to the same tape as the full dump).
> That's been requested but not implemented. So you're going to have to
> use two tapes per week, one for the full dump and one to flush the week
> of incrementals.
Either that or have the fulls left in the holding disk too (which will
require tweaking reserve) and have them amflushed to tape along with
the incrementals.
--
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: Compiling
On Nov 2, 2000, [EMAIL PROTECTED] wrote:
> I'm new to Amanda and I cannot compile it. ./configure says to me:
> "can't guess host type. you have to specify one".
Set the environment variable CC to the name of a working C compiler.
--
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: amcheck & amverify ok, but selfcheck & amdump hang
>I'm relieved to hear it only takes an incantation, I was affraid we >were going to have to slaughter the fatted calf and I've been saving >that for when the old drives in the next rack over decide to stick :) :-) You didn't mention if you needed the magic or not, but here it is just in case (add to /etc/system and reboot): set hme:hme_adv_100fdx_cap = 1 set hme:hme_adv_100hdx_cap = 0 set hme:hme_adv_autoneg_cap = 0 The first line says "use full duplex", the second says "don't use half duplex" and the third says "don't try to autonegotiate". I assume you flip the value in the first two lines if you use half duplex. Truth be told, I only have (and knew about) the first and third lines. But I just saw the second line and the following in a mailing list recently. I suspect the default is zero for these variables and so I don't need the half duplex set. If you want to test the values while the system is up (as root): ndd -get /dev/hme hme_adv_100fdx_cap ndd -get /dev/hme hme_adv_100hdx_cap ndd -get /dev/hme hme_adv_autoneg_cap If you have multiple instances, select the specific one first, then do the variables, e.g. for hme1: ndd -set /dev/hme instance 1 ndd -get /dev/hme hme_adv_100fdx_cap ... I'm not sure what you do in /etc/system for multiple instances. In theory you can also set these at run time, but that's braver than I'd want to be unless it was dead in the water and my local network guru was at my shoulder. >Jon John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: I had enough holding disk but part of the dump failed -
>I think that's what's happening, a dump with est_kps larger than the >bandwidth will never be scheduled to dump on holding disk. I agree it looks like that could happen in principle (in fact, I wonder if other such "don't do this now" states should be examined), but in this particular case the estimated bandwidth for the two disks not processed was well below the available. >Jean-Louis John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Tape failures
On Fri, 3 Nov 2000 at 6:30pm, John R. Jackson wrote > >Curiously, each of the three times, the tape error occurs just under > >3 minutes into the amdump run. Of course, the amflush the next day works > >just fine, taking almost an hour to do so. ... > > The only thing that pops to mind is a SCSI problem. Is your holding > disk on the same bus as the drives? That would be the main difference > between amdump and amflush -- during amdump one or more processes are > writing into the holding disk at the same time taper is dragging stuff > out and writing it to tape. A lot more disk and controller activity. > Yeah, SCSI issues would seem to be the likely culprit. The tape drive is actually on a different bus than the hard drives, though. I *was* having some issues with scsi0, but those seem to have gone away (knock on wood) with a hard drive replacement. scsi1 (the tape and a CD-R) was working fine before and after the switch, then started acting up. > Check the cable. Check the termination. Move the devices (if possible) > to other buses. > I actually swapped the tape drive with another (identical) one I had hooked to a different machine. The cable and termination got checked, of course, in the process. We'll see what happens tonight. Now, I did give scsi0 some blood during the hard drive swap. I'm thinking scsi1 got jealous and needs its taste... -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: amcheck & amverify ok, but selfcheck & amdump hang
On Fri, Nov 03, 2000 at 07:48:13PM -0500, John R. Jackson wrote: :Does this machine have an 100 Mbit/s Ethernet? Those are notorious :for not negotiating the duplex setting properly and things go downhill :in a hurry after that. I have the magic /etc/system incantion needed :(for hme on Sparc) to force the issue if you need it. Why yes...Sun Ultra1, 100Mbit/s sbus card. I'm relieved to hear it only takes an incantation, I was affraid we were going to have to slaughter the fatted calf and I've been saving that for when the old drives in the next rack over decide to stick :) :>Selfcheck on this machine producses the same results (permanent hang) : :Huh? Selfcheck is run by amcheck. Did you try to run it by hand? :You would have to know the proper input to give it to get it to do :anything. I was begining to suspect that since it is fairly (if not completely) undocumented and produces the same non-behavior on the working server. Thanks, Jon
Re: I had enough holding disk but part of the dump failed -
On Fri, Nov 03, 2000 at 05:55:20PM -0500, John R. Jackson wrote: > I looked at your amdump.1 log and the code for quite a while this > afternoon and am not sure what happened. It looks like the driver > algorithm for choosing the next dump to process may have trouble with > some restricting situations in conjunction with you not using a tape. > For instance, it looks like the code might decide to send a dump direct > to tape when there doesn't appear to be enough bandwidth. That does > not appear to be what's happening to you, but it would cause what you > are seeing. I think that's what's happening, a dump with est_kps larger than the bandwidth will never be scheduled to dump on holding disk. This patch will allow a dump to be scheduled if no other dumpers use the interface. Untested patch. Jean-Louis -- Jean-Louis Martineau email: [EMAIL PROTECTED] Departement IRO, Universite de Montreal C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529 Montreal, Canada, H3C 3J7Fax: (514) 343-5834 --- driver.c.orig Fri Nov 3 20:40:42 2000 +++ driver.cFri Nov 3 20:45:08 2000 @@ -559,7 +559,8 @@ sleep_time.tv_sec); any_delayed_disk = 1; } - else if(sched(diskp)->est_kps > free_kps(diskp->host->netif)) + else if(sched(diskp)->est_kps > free_kps(diskp->host->netif) && + diskp->host->netif->curusage > 0) cur_idle = max(cur_idle, IDLE_NO_BANDWIDTH); else if((holdp = find_diskspace(sched(diskp)->est_size,&cur_idle,NULL)) == NULL) cur_idle = max(cur_idle, IDLE_NO_DISKSPACE);
Re: running amcheck
>... the subject header does have this BOLD warning message. >Can this be ignored? >... >Subject: daily AMANDA PROBLEM: FIX BEFORE RUN, IF POSSIBLE Amanda is not meant to be run without a tape and that's what it is warning you about. Since you plan to work that way, it doesn't apply. Note that it may still indicate another problem in the output that you do need to deal with. For now, you may want to run amcheck with the -c option on the days you do not have a tape mounted. That will only check the clients and should stay quiet unless there is trouble. When you get to 2.4.2, you can run it with -c and -l to do all the checks except the tape. >Denise E. Ives John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amcheck & amverify ok, but selfcheck & amdump hang
>On the new server amcheck reports all is well, however amdump hangs. >Watching the CPU usage the amanda processes slowly drop off to 0% CPU >use and stay that way forever (well atleast 72hours). ... Does this machine have an 100 Mbit/s Ethernet? Those are notorious for not negotiating the duplex setting properly and things go downhill in a hurry after that. I have the magic /etc/system incantion needed (for hme on Sparc) to force the issue if you need it. >Selfcheck on this machine producses the same results (permanent hang) Huh? Selfcheck is run by amcheck. Did you try to run it by hand? You would have to know the proper input to give it to get it to do anything. >amlabel and amverify are also working correctly. You probably have a network problem so these don't matter. >Jon John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Exclusions not working
>In my exclude rules for the /var filesystem backup, I have some lines >like this: > >./spool/postfix/private/* >./lib/lists-archives/archives/* > >Which, according to the docs, are the right way to do this (there are >sockets in those directories which cause gtar warnings.) However, >they are ignored! ... What do you mean by "they are ignored"? In particular, I'm not sure GNU tar doesn't go ahead and throw a warning because it sees these entries before it tests them agains the exclusion list (which seems like a bug to me). >Also, lines like: > >*/no-backup/* > >are ignored -- even though this is basically EXACTLY like an example >in the book chapter. ... I set up a test case and played with it some and can't get it to fail with the minimal information here. A couple of suggestions (from someone who does not use GNU tar): * Are you certain you are updating the exclusion list on the client? Some people get confused and update it on the server. * Did you look at /tmp/amanda/sendbackup*debug on the client and verify it is using the exclusion list/file you think it is? * Are you sure Amanda/GNU tar is using the exclusion list? If you do an "ls -lu" on the file right after Amanda runs, is it being referenced? Actually, that might be a bad test because if it gets backed up, that will update the access time. To test the various cases for the book, I wrote a little shell script that might help: ftp://gandalf.cc.purdue.edu/pub/amanda/gtartest-exclude >I have GNU tar 1.13.17 ... FYI, I ran my tests today with 1.12+, 1.13.17 and 1.13.18. >-- John John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: where am i going wrong.
>I have not tried the permissions thing, but yes, i have successfuly run >amlabel. Then that makes absolutely no sense. It's the same code. I assume you ran amlabel as the Amanda user and not root? John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amrecover: Error binding socket: Permission denied
>The level 0 files came off the tape without any problems, but on trying to >recover files from the incremental tape >I received the following error: > >amrecover: Error binding socket: Permission denied I assume you are starting amrecover as root, right? You didn't make it setuid and are trying to run it as a normal user? The only thing I can think of is that your OS is being particularly annoying about changing back and forth between root and some other user. Amrecover is the only Amanda program that does that (as I recall). It doesn't really need to, it was just an early start at supporting user controlled restores. I'd try searching for seteuid in recover-src/amrecover.c (one occurance) and recover-src/extract_list.c (twice). Just comment those calls out (and the matching setegid) and see if that does any good. >Julian Stevens John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: where am i going wrong.
> Well, I don't know. This looks like it should work. > > What happens if you (temporarily) "chmod a+rx /dev/nst0" to allow access > to anyone? I'm trying to find out if the drive works at all. > > Were you able to run amlabel? I have not tried the permissions thing, but yes, i have successfuly run amlabel. > > John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] >
Re: where am i going wrong.
>bash-2.04# ls -lL /dev/nst0 >crw-rw 1 root mail 9, 128 Aug 7 12:08 /dev/nst0 > >- and - > >bash-2.04# groups amanda2 >amanda2 : amanda2 mail Well, I don't know. This looks like it should work. What happens if you (temporarily) "chmod a+rx /dev/nst0" to allow access to anyone? I'm trying to find out if the drive works at all. Were you able to run amlabel? >brian John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Compiling
>I'm new to Amanda and I cannot compile it. ./configure says to me: >"can't guess host type. you have to specify one". I plan to use >amanda 2.4.1.p1 on a RedHat 6.1 system. Thanks in advance. And are you building it on "a RedHat 6.1 system"? What does "uname -a" say? >Olaf John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: where am i going wrong.
> If it continues to happen, please post the results of: > > # ls -lL /dev/nst0 > > and: > > # su -c "id -a" > -- or -- > # groups bash-2.04# ls -lL /dev/nst0 crw-rw 1 root mail 9, 128 Aug 7 12:08 /dev/nst0 - and - bash-2.04# groups amanda2 amanda2 : amanda2 mail > > >brian > > John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] >
Re: Data Corruption, Amanda 2.4.1p1 on SCO Openserver 5.0
>Needed to restore some files only to find that somehow the files are >corrupt. For example a 46MB file restores as a 36MB file. Are you saying the dump image restored from tape, e.g. with amrestore, is bad (short) or that when you then process it with tar to extract a single file, that file is the one that is short? Does the size of the image match what Amanda told you when it dumped it? Either the E-mail report or "amadmin find " should show you the output size (or there are other ways, if this doesn't work). If you do a "tar t" of the whole image, does it whine about anything? Are you certain when you configured Amanda on this machine it found the right tar? What's in /tmp/amanda/amandad*debug and sendbackup*debug for a typical run? Were you using GNU tar 1.12+ to do the extract or did you just say "tar" and maybe get the vendor provided one? >John John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: where am i going wrong.
>... i will go back and double check, but i know ive gone over the >permissions numberous times. If it continues to happen, please post the results of: # ls -lL /dev/nst0 and: # su -c "id -a" -- or -- # groups >brian John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amdump error: lev 0 FAILED [/usr/bin/tar returned 1]
>I am trying to find why tar is failing. ... What's in /tmp/amanda/sendbackup*debug on the client? Are you getting FAILED or STRANGE messages logged in the E-mail? John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Tape failures
>Curiously, each of the three times, the tape error occurs just under >3 minutes into the amdump run. Of course, the amflush the next day works >just fine, taking almost an hour to do so. ... The only thing that pops to mind is a SCSI problem. Is your holding disk on the same bus as the drives? That would be the main difference between amdump and amflush -- during amdump one or more processes are writing into the holding disk at the same time taper is dragging stuff out and writing it to tape. A lot more disk and controller activity. Check the cable. Check the termination. Move the devices (if possible) to other buses. >Joshua Baker-LePain John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: where am i going wrong.
> >ERROR: /dev/nst0: Permission denied > > I assume this one is obvious. You need to enable read/write permission > to the tape device for the Amanda user. Typically this is done by putting > the device in the same group as the Amanda user and enabling group access. > Or you could put the Amanda user in whatever group owns the device. I am currently implimenting your latter suggestion.. yet i am getting the error. i will go back and double check, but i know ive gone over the permissions numberous times. brian
Re: where am i going wrong.
>... i am getting the following error(s?) when i run amcheck: >... >ERROR: /dev/nst0: Permission denied I assume this one is obvious. You need to enable read/write permission to the tape device for the Amanda user. Typically this is done by putting the device in the same group as the Amanda user and enabling group access. Or you could put the Amanda user in whatever group owns the device. >protocol packet receive: Connection refused This is coming from a recvfrom() system call. According to my (Solaris) documentation, ECONNREFUSED is **not** one of the errors it can return. So you'll have to look up in your own OS documentation for what situations can cause that and possibly ask your OS support for help. My guess would be some kind of TCP wrappers or firewall. The following folks have reported the same error recently (within a couple of months): C. Vijaya Lakshmi <[EMAIL PROTECTED]> Joe Prochazka <[EMAIL PROTECTED]> Iain O'Cain <[EMAIL PROTECTED]> Jeff Silverman <[EMAIL PROTECTED]> but I don't see any responses that indicate what the solution was, if they ever got it working. >brian John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Failure to allocate memory
>Finally got everything set up right (I think). Ran my first test dump, and >it mailed me a report saying it failed: > >taper: FATAL shmget: Cannot allocate memory Shared memory is a kernel feature that you may have to enable or turn on in some way. Try "ipcs -a", which should report all current shared memory segments, semaphores and message queues. With luck, it will either tell you there are a bunch of old shared memory segments for the Amanda user caused by your testing, in which case you can use ipcrm to clear them, or it will tell you shared memory is not enabled, in which case you'll have to find out from someone who knows about your OS (or from the system documentation) how to turn that on. >--- Eric John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: I had enough holding disk but part of the dump failed -
I looked at your amdump.1 log and the code for quite a while this afternoon and am not sure what happened. It looks like the driver algorithm for choosing the next dump to process may have trouble with some restricting situations in conjunction with you not using a tape. For instance, it looks like the code might decide to send a dump direct to tape when there doesn't appear to be enough bandwidth. That does not appear to be what's happening to you, but it would cause what you are seeing. There is not enough logging data about why the two disks were not allowed to go to the holding disk to tell for sure. Another thought: are you using the same dumptype for all the disks? Is there any chance these two are marked "holdingdisk no" or are different in some other way? At one point, when your holding disk was going to be part of /home, I told you you would have to do that. But now that it's a separate partition, you should definitely **not** be using this option. If this isn't it, the only thing I can think of to do is generate some temporary patches for your system to better track what is going on. But I know how much you enjoy applying patches :-), so you make the call. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
where am i going wrong.
i cannot seem to get a backup to run. i have gone through all my settings, recompiled, double checked everything, yet i must be missing something. i am getting the following error(s?) when i run amcheck: ---b Amanda Tape Server Host Check - /holding/amanda: 8367536 KB disk space available, using 8316336 KB. ERROR: /dev/nst0: Permission denied (expecting a new tape) NOTE: skipping tape-writable test. Server check took 0.002 seconds. protocol packet receive: Connection refused protocol packet receive: Connection refused protocol packet receive: Connection refused Amanda Backup Client Hosts Check WARNING: shiva.soltec.net: selfcheck request timed out. Host down? Client check: 1 host checked in 30.021 seconds, 1 problem found. ---e when i try to backup, i get this error: ---b *** THE DUMPS DID NOT FINISH PROPERLY! *** A TAPE ERROR OCCURRED: [no tape online]. *** PERFORMED ALL DUMPS TO HOLDING DISK. THESE DUMPS WERE TO DISK. Flush them onto a new tape. Tonight's dumps should go onto 1 tape: a new tape. FAILURE AND STRANGE DUMP SUMMARY: shiva sda4 lev 0 FAILED [Request to shiva timed out.] shiva sda3 lev 0 FAILED [Request to shiva timed out.] shiva sda2 lev 0 FAILED [Request to shiva timed out.] ---e i couldnt find any help in the faq's on the website. can anyone offer any assistance? brian
Re: I had enough holding disk but part of the dump failed -
On Fri, 3 Nov 2000, John R. Jackson wrote: > >Here is my amanda.conf file with respect to the holding disk - > >... > >use -500Mb ... > > That's OK. > > >chunksize -1 ... > > This is not related to your problem, but you should change this at > some point to something like "1000 Mb". > > >Is the use wrong? > > It might be a little large (why not let Amanda have almost all of that > file system?), but is probably not the problem. Much as I hate to do > this :-), please post the entire amdump.1 file that goes with this run. > It's the only way we'll be able to tell what was going on. > > John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] > -- Denise E. Ives [EMAIL PROTECTED] Systems Engineer734.822.2037 Multilingual Internet Domain Name Registrations - http://www.walid.com amdump: start at Fri Nov 3 01:15:00 EST 2000 planner: pid 14161 executable /usr/local/pkg/amanda-2.4.1p1/libexec/planner version 2.4.1p1 planner: build: VERSION="Amanda-2.4.1p1" planner:BUILT_DATE="Tue Oct 17 14:52:15 GMT 2000" planner:BUILT_MACH="SunOS sundev1.corp.walid.com 5.8 Generic sun4u sparc SUNW,Ultra-60" planner:CC="gcc" planner: paths: bindir="/usr/local/pkg/amanda-2.4.1p1/bin" planner:sbindir="/usr/local/pkg/amanda-2.4.1p1/sbin" planner:libexecdir="/usr/local/pkg/amanda-2.4.1p1/libexec" planner:mandir="/usr/local/pkg/amanda-2.4.1p1/man" planner:CONFIG_DIR="/usr/local/pkg/amanda-2.4.1p1/etc/amanda" planner:DEV_PREFIX="/dev/dsk/" RDEV_PREFIX="/dev/rdsk/" planner:DUMP="/usr/sbin/ufsdump" RESTORE="/usr/sbin/ufsrestore" planner:GNUTAR="/usr/local/bin/tar" COMPRESS_PATH="/usr/bin/gzip" planner:UNCOMPRESS_PATH="/usr/bin/gzip" MAILER="/usr/ucb/Mail" planner: listed_incr_dir="/usr/local/pkg/amanda-2.4.1p1/var/amanda/gnutar-lists" planner: defs: DEFAULT_SERVER="sundev1.corp.walid.com" planner:DEFAULT_CONFIG="daily" planner:DEFAULT_TAPE_SERVER="sundev1.corp.walid.com" planner:DEFAULT_TAPE_DEVICE="/dev/rmt/0bn" HAVE_MMAP HAVE_SYSVSHM planner:LOCKING=POSIX_FCNTL SETPGRP_VOID DEBUG_CODE BSD_SECURITY planner:USE_AMANDAHOSTS CLIENT_LOGIN="amanda" FORCE_USERID HAVE_GZIP planner:COMPRESS_SUFFIX=".gz" COMPRESS_FAST_OPT="--fast" planner:COMPRESS_BEST_OPT="--best" UNCOMPRESS_OPT="-dc" READING CONF FILES... startup took 0.025 secs SETTING UP FOR ESTIMATES... setting up estimates for sundev1.corp.walid.com:c0t0d0s0 sundev1.corp.walid.com:c0t0d0s0 overdue 11 days for level 0 setup_estimate: sundev1.corp.walid.com:c0t0d0s0: command 0, options: last_level 1 next_level0 -11 level_days 2 getting estimates 0 (2049855) 1 (255) 2 (0) setting up estimates for sundev1.corp.walid.com:c0t0d0s3 sundev1.corp.walid.com:c0t0d0s3 overdue 11 days for level 0 setup_estimate: sundev1.corp.walid.com:c0t0d0s3: command 0, options: last_level 2 next_level0 -11 level_days 1 getting estimates 0 (481183) 2 (52991) 3 (0) setting up estimates for sundev1.corp.walid.com:c0t0d0s7 sundev1.corp.walid.com:c0t0d0s7 overdue 11 days for level 0 setup_estimate: sundev1.corp.walid.com:c0t0d0s7: command 0, options: last_level 0 next_level0 -11 level_days 0 getting estimates 0 (5101407) 1 (737663) -1 (-1) setting up estimates for admin1.corp.walid.com:sda6 admin1.corp.walid.com:sda6 overdue 11 days for level 0 setup_estimate: admin1.corp.walid.com:sda6: command 0, options: last_level 1 next_level0 -11 level_days 2 getting estimates 0 (93824) 1 (490) 2 (0) setting up estimates for admin1.corp.walid.com:sda3 driver: pid 14160 executable /usr/local/pkg/amanda-2.4.1p1/libexec/driver version 2.4.1p1 driver: send-cmd time 0.022 to taper: START-TAPER 20001103 admin1.corp.walid.com:sda3 overdue 11 days for level 0 setup_estimate: admin1.corp.walid.com:sda3: command 0, options: last_level 1 next_level0 -11 level_days 2 getting estimates 0 (6020) 1 (19) 2 (0) setting up estimates for admin1.corp.walid.com:sda5 admin1.corp.walid.com:sda5 overdue 11 days for level 0 setup_estimate: admin1.corp.walid.com:sda5: command 0, options: last_level 1 next_level0 -11 level_days 2 getting estimates 0 (1594953) 1 (3698) 2 (0) setting up estimates for admin1.corp.walid.com:sda10 admin1.corp.walid.com:sda10 overdue 11 days for level 0 setup_estimate: admin1.corp.walid.com:sda10: command 0, options: last_level 0 next_level0 -11 level_days 0 getting estimates 0 (4550177) 1 (0) -1 (-1) setting up
Re: amdump error: lev 0 FAILED [/usr/bin/tar returned 1]
Alert: This only occurs when I try and dump a root partition. Seems to
work fine on others.
On Fri, 3 Nov 2000, Eric Wadsworth wrote:
> I am trying to find why tar is failing. Here is information, if anyone has
> ideas:
>
> 'amadmin DailySet1 version' shows where GNUTAR is set:
> GNUTAR="/usr/bin/tar"
>
> I verified, and yes, tar is there.
>
> These are in the amanda.conf file:
>
> define dumptype global {
> comment "Global definitions"
> index yes
> }
>
> define dumptype root-tar {
> global
> program "GNUTAR"
> comment "root partitions dumped with tar"
> compress none
> index
> exclude list "/usr/local/etc/amanda/exclude.gtar"
> priority low
> }
>
> There is only one line in the disklist file:
>
> this.system.consys.com /dev/da0s1a root-tar
>
> this.system is the amanda host (has the tape drive). This partition is the
> root partition on the computer.
>
> There is no such file /usr/local/etc/amanda/exclude.gtar as specified in
> the definition of root-tar (See above), but I tried a dump with that line
> commented out, same result.
>
> Thanks in advance for any ideas! --- Eric
>
>
Re: amdump.1 - dump failure -
root@sundev1:adm/amanda/daily# more amdump.1 amdump: start at Fri Nov 3 01:15:00 EST 2000 planner: pid 14161 executable /usr/local/pkg/amanda-2.4.1p1/libexec/planner version 2.4.1p1 planner: build: VERSION="Amanda-2.4.1p1" planner:BUILT_DATE="Tue Oct 17 14:52:15 GMT 2000" planner:BUILT_MACH="SunOS sundev1.corp.walid.com 5.8 Generic sun4u sparc SUNW,Ultra-60" planner:CC="gcc" planner: paths: bindir="/usr/local/pkg/amanda-2.4.1p1/bin" planner:sbindir="/usr/local/pkg/amanda-2.4.1p1/sbin" planner:libexecdir="/usr/local/pkg/amanda-2.4.1p1/libexec" planner:mandir="/usr/local/pkg/amanda-2.4.1p1/man" planner:CONFIG_DIR="/usr/local/pkg/amanda-2.4.1p1/etc/amanda" planner:DEV_PREFIX="/dev/dsk/" RDEV_PREFIX="/dev/rdsk/" planner:DUMP="/usr/sbin/ufsdump" RESTORE="/usr/sbin/ufsrestore" planner:GNUTAR="/usr/local/bin/tar" COMPRESS_PATH="/usr/bin/gzip" planner:UNCOMPRESS_PATH="/usr/bin/gzip" MAILER="/usr/ucb/Mail" planner:listed_incr_dir="/usr/local/pkg/amanda-2.4.1p1/var/amanda/gnutar-lists" planner: defs: DEFAULT_SERVER="sundev1.corp.walid.com" planner:DEFAULT_CONFIG="daily" planner:DEFAULT_TAPE_SERVER="sundev1.corp.walid.com" planner:DEFAULT_TAPE_DEVICE="/dev/rmt/0bn" HAVE_MMAP HAVE_SYSVSHM planner:LOCKING=POSIX_FCNTL SETPGRP_VOID DEBUG_CODE BSD_SECURITY planner:USE_AMANDAHOSTS CLIENT_LOGIN="amanda" FORCE_USERID HAVE_GZIP planner:COMPRESS_SUFFIX=".gz" COMPRESS_FAST_OPT="--fast" planner:COMPRESS_BEST_OPT="--best" UNCOMPRESS_OPT="-dc" READING CONF FILES... startup took 0.025 secs SETTING UP FOR ESTIMATES... setting up estimates for sundev1.corp.walid.com:c0t0d0s0 sundev1.corp.walid.com:c0t0d0s0 overdue 11 days for level 0 setup_estimate: sundev1.corp.walid.com:c0t0d0s0: command 0, options: last_level 1 next_level0 -11 level_days 2 getting estimates 0 (2049855) 1 (255) 2 (0) setting up estimates for sundev1.corp.walid.com:c0t0d0s3 sundev1.corp.walid.com:c0t0d0s3 overdue 11 days for level 0 setup_estimate: sundev1.corp.walid.com:c0t0d0s3: command 0, options: last_level 2 next_level0 -11 level_days 1 getting estimates 0 (481183) 2 (52991) 3 (0) setting up estimates for sundev1.corp.walid.com:c0t0d0s7 sundev1.corp.walid.com:c0t0d0s7 overdue 11 days for level 0 setup_estimate: sundev1.corp.walid.com:c0t0d0s7: command 0, options: last_level 0 next_level0 -11 level_days 0 getting estimates 0 (5101407) 1 (737663) -1 (-1) setting up estimates for admin1.corp.walid.com:sda6 admin1.corp.walid.com:sda6 overdue 11 days for level 0 setup_estimate: admin1.corp.walid.com:sda6: command 0, options: last_level 1 next_level0 -11 level_days 2 getting estimates 0 (93824) 1 (490) 2 (0) setting up estimates for admin1.corp.walid.com:sda3 driver: pid 14160 executable /usr/local/pkg/amanda-2.4.1p1/libexec/driver version 2.4.1p1 driver: send-cmd time 0.022 to taper: START-TAPER 20001103 admin1.corp.walid.com:sda3 overdue 11 days for level 0 setup_estimate: admin1.corp.walid.com:sda3: command 0, options: last_level 1 next_level0 -11 level_days 2 getting estimates 0 (6020) 1 (19) 2 (0) setting up estimates for admin1.corp.walid.com:sda5 admin1.corp.walid.com:sda5 overdue 11 days for level 0 setup_estimate: admin1.corp.walid.com:sda5: command 0, options: last_level 1 next_level0 -11 level_days 2 getting estimates 0 (1594953) 1 (3698) 2 (0) setting up estimates for admin1.corp.walid.com:sda10 admin1.corp.walid.com:sda10 overdue 11 days for level 0 setup_estimate: admin1.corp.walid.com:sda10: command 0, options: last_level 0 next_level0 -11 level_days 0 getting estimates 0 (4550177) 1 (0) -1 (-1) setting up estimates for admin1.corp.walid.com:sda9 admin1.corp.walid.com:sda9 overdue 11 days for level 0 setup_estimate: admin1.corp.walid.com:sda9: command 0, options: last_level 1 next_level0 -11 level_days 2 getting estimates 0 (58442) 1 (48454) 2 (0) setting up estimates for admin1.corp.walid.com:sda2 taper: pid 14162 executable taper version 2.4.1p1 admin1.corp.walid.com:sda2 overdue 11 days for level 0 setup_estimate: admin1.corp.walid.com:sda2: command 0, options: last_level 1 next_level0 -11 level_days 1 getting estimates 0 (250246) 1 (622675) 2 (0) setting up estimates took 0.043 secs GETTING ESTIMATES... driver: started dumper0 pid 14168 driver: started dumper1 pid 14169 driver: started dumper2 pid 14170 driver: started dumper3 pid 14171 dumper: pid 14170 executable dumper version 2.4.1p1, using port 858 dumper: pid 14171 executable dumper version 2.4.1p1, using port 859 dumper: pid 14169 executable dumper version 2.4.1p1, using port 857 dumper:
amdump error: lev 0 FAILED [/usr/bin/tar returned 1]
I am trying to find why tar is failing. Here is information, if anyone has
ideas:
'amadmin DailySet1 version' shows where GNUTAR is set:
GNUTAR="/usr/bin/tar"
I verified, and yes, tar is there.
These are in the amanda.conf file:
define dumptype global {
comment "Global definitions"
index yes
}
define dumptype root-tar {
global
program "GNUTAR"
comment "root partitions dumped with tar"
compress none
index
exclude list "/usr/local/etc/amanda/exclude.gtar"
priority low
}
There is only one line in the disklist file:
this.system.consys.com /dev/da0s1a root-tar
this.system is the amanda host (has the tape drive). This partition is the
root partition on the computer.
There is no such file /usr/local/etc/amanda/exclude.gtar as specified in
the definition of root-tar (See above), but I tried a dump with that line
commented out, same result.
Thanks in advance for any ideas! --- Eric
Re: strange dumps ?
>Can you tell me something about this report ? What does it mean FAILURE >AND STRANGE DUMP ... Amanda watches the stderr lines from the backup program and pattern matches them against things it expects (normal). Every other line is considered "strange". If the backup failed or there were any strange lines, it reports them in this section of the E-mail. The character at the front of the line is a code for the class of line: | a normal (expected) line ? a strange (unclassified) line The latest 2.4.2 version has a pattern to treat your "socket ignored" messages as normal and thus ignore them. And I think it also ignores all that noise from smbtar. >Michael John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: I had enough holding disk but part of the dump failed -
>Here is my amanda.conf file with respect to the holding disk - >... >use -500Mb ... That's OK. >chunksize -1 ... This is not related to your problem, but you should change this at some point to something like "1000 Mb". >Is the use wrong? It might be a little large (why not let Amanda have almost all of that file system?), but is probably not the problem. Much as I hate to do this :-), please post the entire amdump.1 file that goes with this run. It's the only way we'll be able to tell what was going on. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Data Corruption, Amanda 2.4.1p1 on SCO Openserver 5.0
Anybody? John - NetRom Internet Services973-208-1339 voice [EMAIL PROTECTED] 973-208-0942 fax http://www.netrom.com - On Mon, 30 Oct 2000, John Vozza wrote: > I've successfully run Amanda on many different platforms and thought I had > the above platform working fine. Its been doing backups for almost a year. > > Needed to restore some files only to find that somehow the files are > corrupt. For example a 46MB file restores as a 36MB file. > > No indication of problems or errors during the backup or restore. Tried > both compressed and uncompressed backups (using gzip and tar 1.12 patched) > > Doing a tar directly to tape, an HP DAT DSS1 drive, and then restoring the > files is fine. > > This is a single machine backing up to its own tape drive. > > I realize there's not alot to go on here but can anyone point me in the > right direction on how to isolate this issue? > > Thanks > > John > - > NetRom Internet Services 973-208-1339 voice > [EMAIL PROTECTED] 973-208-0942 fax > http://www.netrom.com > - > >
Re: gradually adding resourses to back up
>... Can I just >haphazardly add lines to my disklist file, or should I do something >special? As Nate said, you can probably just add them however you want. The only thing to keep in mind is that the first time Amanda sees a new disk it will insist on doing a full dump. So if you load it up with more than will fit on a single tape (or however many tapes you've told it it can use), there will be problems until things get a chance to spread out. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: I had enough holding disk but part of the dump failed -
Here is my amanda.conf file with respect to the holding disk -
holdingdisk hd1 {
comment "main holding disk"
directory "/dump/amanda"# where the holding disk is
use -500Mb # how much space can we use on it
# a negative value mean:
#use all space except that value
chunksize -1# size of chunk if you want big dump to be
# dumped on multiple files on holding disks
# N Kb/Mb/Gb split disks in chunks of size N
# 0 split disks in INT_MAX/1024 Kb
chunks
# -1 same as -INT_MAX/1024 (see below)
# -N Kb/Mb/Gb dont split, dump larger
# filesystems directly to tape
# (example: -2 Gb)
Is the use wrong?
**
On Fri, 3 Nov 2000, Scot W. Hetzel wrote:
> From: "Denise Ives" <[EMAIL PROTECTED]>
> > claiming there was [no more holding disk space] -
> >
> > What do you think went wrong?
> >
> > Filesystemkbytesused avail capacity Mounted on
> > /dev/md/dsk/d20 11560144 1847220 959732317%/dump
> >
> > Subject: daily AMANDA MAIL REPORT FOR November 3, 2000
> >
>
> >
> > FAILURE AND STRANGE DUMP SUMMARY:
> > admin1.cor sda9 lev 2 FAILED [no more holding disk space]
> > admin1.cor sda10 lev 1 FAILED [no more holding disk space]
> >
> >
> Your amanda.conf file may be specifying a maximum amount of drive space to
> use for the holding disk.
>
> holdingdisk hd1 {
> comment "main holding disk"
> directory "/dumps/amanda" # where the holding disk is
> use -20 Mb # how much space can we use on it
> # a negative value mean:
> #use all space except that value
> chunksize 1 Gb # size of chunk if you want big dump to be
> # dumped on multiple files on holding disks
> # N Kb/Mb/Gb split disks in chunks of size N
> # 0 split disks in INT_MAX/1024 Kb chunks
> # -1 same as -INT_MAX/1024 (see below)
> # -N Kb/Mb/Gb dont split, dump larger
> # filesystems directly to tape
> # (example: -2 Gb)
> # chunksize 2 Gb
> }
>
> Try, changing the "use" size to a more appropriate valuse for your setup.
>
> Scot
>
Re: I had enough holding disk but part of the dump failed -
From: "Denise Ives" <[EMAIL PROTECTED]>
> claiming there was [no more holding disk space] -
>
> What do you think went wrong?
>
> Filesystemkbytesused avail capacity Mounted on
> /dev/md/dsk/d20 11560144 1847220 959732317%/dump
>
> Subject: daily AMANDA MAIL REPORT FOR November 3, 2000
>
>
> FAILURE AND STRANGE DUMP SUMMARY:
> admin1.cor sda9 lev 2 FAILED [no more holding disk space]
> admin1.cor sda10 lev 1 FAILED [no more holding disk space]
>
>
Your amanda.conf file may be specifying a maximum amount of drive space to
use for the holding disk.
holdingdisk hd1 {
comment "main holding disk"
directory "/dumps/amanda" # where the holding disk is
use -20 Mb # how much space can we use on it
# a negative value mean:
#use all space except that value
chunksize 1 Gb # size of chunk if you want big dump to be
# dumped on multiple files on holding disks
# N Kb/Mb/Gb split disks in chunks of size N
# 0 split disks in INT_MAX/1024 Kb chunks
# -1 same as -INT_MAX/1024 (see below)
# -N Kb/Mb/Gb dont split, dump larger
# filesystems directly to tape
# (example: -2 Gb)
# chunksize 2 Gb
}
Try, changing the "use" size to a more appropriate valuse for your setup.
Scot
I had enough holding disk but part of the dump failed -
claiming there was [no more holding disk space] -
What do you think went wrong?
Filesystemkbytesused avail capacity Mounted on
/dev/md/dsk/d20 11560144 1847220 959732317%/dump
Subject: daily AMANDA MAIL REPORT FOR November 3, 2000
*** THE DUMPS DID NOT FINISH PROPERLY!
*** A TAPE ERROR OCCURRED: [no tape online].
*** PERFORMED ALL DUMPS TO HOLDING DISK.
THESE DUMPS WERE TO DISK. Flush them onto a new tape.
Tonight's dumps should go onto 1 tape: a new tape.
FAILURE AND STRANGE DUMP SUMMARY:
admin1.cor sda9 lev 2 FAILED [no more holding disk space]
admin1.cor sda10 lev 1 FAILED [no more holding disk space]
STATISTICS:
Total Full Daily
Dump Time (hrs:min)0:02 0:00 0:00 (0:02 start)
Output Size (meg) 370.40.0 370.4
Original Size (meg) 370.40.0 370.4
Avg Compressed Size (%) -- -- --
Tape Used (%) 1.00.01.0 (level:#disks ...)
Filesystems Dumped7 0 7 (1:1 2:5 3:1)
Avg Dump Rate (k/s) 1642.0-- 1642.0
Avg Tp Write Rate (k/s) -- -- --
?
NOTES:
planner: Incremental of admin1.corp.walid.com:sda2 bumped to level 2.
planner: Incremental of admin1.corp.walid.com:sda9 bumped to level 2.
planner: Incremental of admin1.corp.walid.com:sda5 bumped to level 2.
planner: Incremental of admin1.corp.walid.com:sda3 bumped to level 2.
planner: Incremental of admin1.corp.walid.com:sda6 bumped to level 2.
planner: Incremental of sundev1.corp.walid.com:c0t0d0s3 bumped to level
3.
planner: Incremental of sundev1.corp.walid.com:c0t0d0s0 bumped to level
2.
?
DUMP SUMMARY:
DUMPER STATS TAPER
STATS
HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS
KB/s
-- --
--
admin1.co sda10 1 FAILED
admin1.co sda2 26380863808 -- 0:21 3095.4N/A
N/A
admin1.co sda3 2 32 32 -- 0:00 126.4N/A
N/A
admin1.co sda5 2 6272 6272 -- 0:21 293.6N/A
N/A
admin1.co sda6 2 1184 1184 -- 0:03 419.8N/A
N/A
admin1.co sda9 2 FAILED
sundev1.c c0t0d0s0 26387263872 -- 0:52 1228.8N/A
N/A
sundev1.c c0t0d0s3 36329663296 -- 0:24 2630.6N/A
N/A
sundev1.c c0t0d0s7 1 180800 180800 -- 1:50 1645.3N/A
N/A
(brought to you by A
root@sundev1:adm/amanda/daily# more log.20001103.0
START planner date 20001103
START driver date 20001103
ERROR taper no-tape [no tape online]
INFO planner Incremental of admin1.corp.walid.com:sda2 bumped to level 2.
INFO planner Incremental of admin1.corp.walid.com:sda9 bumped to level 2.
INFO planner Incremental of admin1.corp.walid.com:sda5 bumped to level 2.
INFO planner Incremental of admin1.corp.walid.com:sda3 bumped to level 2.
INFO planner Incremental of admin1.corp.walid.com:sda6 bumped to level 2.
INFO planner Incremental of sundev1.corp.walid.com:c0t0d0s3 bumped to
level 3.
INFO planner Incremental of sundev1.corp.walid.com:c0t0d0s0 bumped to
level 2.
FINISH planner date 20001103
STATS driver startup time 132.610
SUCCESS dumper admin1.corp.walid.com sda3 20001103 2 [sec 0.253 kb 32 kps
126.4 orig-kb 17]
SUCCESS dumper admin1.corp.walid.com sda6 20001103 2 [sec 2.820 kb 1184
kps 419.8 orig-kb 1163]
SUCCESS dumper sundev1.corp.walid.com c0t0d0s3 20001103 3 [sec 24.061 kb
63296 kps 2630.6 orig-kb 63263]
SUCCESS dumper admin1.corp.walid.com sda5 20001103 2 [sec 21.361 kb 6272
kps 293.6 orig-kb 6274]
SUCCESS dumper admin1.corp.walid.com sda2 20001103 2 [sec 20.613 kb 63808
kps 3095.4 orig-kb 63793]
SUCCESS dumper sundev1.corp.walid.com c0t0d0s0 20001103 2 [sec 51.977 kb
63872 kps 1228.8 orig-kb 63839]
SUCCESS dumper sundev1.corp.walid.com c0t0d0s7 20001103 1 [sec 109.887 kb
180800 kps 1645.3 orig-kb 180767]
FAIL driver admin1.corp.walid.com sda9 2 [no more holding disk space]
FAIL driver admin1.corp.walid.com sda10 1 [no more holding disk space]
Re: amcheck reports error: can't access a windows system
From: "Eric Wadsworth" <[EMAIL PROTECTED]> > This was the tip I needed to resolve this, thanks John. > > It was actually more complex, becuase I am using FreeBSD's ports system to > work with software applications. I modified the Makefile in the skeleton > for the Amanda24 port to include this item in the configuration parameter > section: > --with-smbclient > > After doing a 'make deinstall' and then 'make' and then 'make install' > the problem persisted, I assumed that my modification of the make file in > the skeleton wasn't being perpetuated down to the level where it actually > calls ./configure, so I dove into the "make deinstall" just removes the port from your system, and deletes the .install-done flag from the work directory. You need to do a "make clean" (after the "make deinstall") in order to re-build the port with your changes. Scot
amcheck & amverify ok, but selfcheck & amdump hang
Hi, I have several machines backing up to a linux box sucessfully using amanda, however trying to migrate these to a Solaris server isn't working out... On the new server amcheck reports all is well, however amdump hangs. Watching the CPU usage the amanda processes slowly drop off to 0% CPU use and stay that way forever (well atleast 72hours). Selfcheck on this machine producses the same results (permanent hang) amlabel and amverify are also working correctly. Ideas? TIA, Jon
amrecover: Error binding socket: Permission denied
I'm still in urgent need of help with this problem, so if anyone can shed any light on it I'd be very grateful. I've searched the egroups archive and the nearest I can get to it is a problem raised by Marco Bagni (message no. 24,532). However, his error message is not quite the same and it doesn't get me any further on. Quick recap... Running amrecover (2.4.1p1) to restore some NT files via Samba (2.06), 2 amanda tapes were requested. The level 0 files came off the tape without any problems, but on trying to recover files from the incremental tape I received the following error: amrecover: Error binding socket: Permission denied I can't understand why the first tape works fine but the second one doesn't. Has anyone else seen this? Is there a fix for it or can anyone suggest a work around. I know I could go back to using amrestore manually for each of the tapes indicated by amrecover but, I think our customers would find this a bit fiddly TIA, Julian Stevens -- BAE SYSTEMS Land & Sea Systems Grange Road Christchurch Dorset BH23 4JE - Tel +44 (0)1202 404426 Fax +44 (0)1202 408308 e-mail [EMAIL PROTECTED]
RE: syntax of .amandahosts
It has the same format as .rhosts THat is : hostname optional-user-name -john -Original Message- From: brian [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 02, 2000 6:46 PM To: [EMAIL PROTECTED] Subject: syntax of .amandahosts maybe i am not looking hard enough, but i cannot find solid documentation on the actual syntax of the .amandahosts file. i am running amanda with the user bin and i have /usr/bin/.amandahosts with what i think is the correct format. unfortunately, i am getting an error message: shiva sda4 lev 0 FAILED [shiva: [access as bin not allowed from [EMAIL PROTECTED]] shiva sda3 lev 0 FAILED [shiva: [access as bin not allowed from [EMAIL PROTECTED]] shiva sda2 lev 0 FAILED [shiva: [access as bin not allowed from [EMAIL PROTECTED]] i am assuming that there is something wrong with the /usr/bin/.amandahosts file. can someone point me in the right direction of .amandahosts documentation or just show me my problems? thanks brian
Tape failures
Of course, once I mailed the list thanks and said I was up and running, I started having problems. They listen to us, I tell you. Anyway, on each of the last three nights, I've had tape errors. This is what amanda says in her mail: These dumps were to tape DailySet1-09. *** A TAPE ERROR OCCURRED: [[writing file: Input/output error]]. Some dumps may have been left in the holding disk. Run amflush to flush them to tape. The next tape Amanda expects to use is: a new tape. And, in /var/log/messages (this is RedHat 6.2), I get: Nov 3 03:02:44 chaos kernel: st0: Error with sense data: Info fld=0x400, Deferred st09:00: sense key Medium Error Nov 3 03:02:44 chaos kernel: Additional sense indicates Write append position error Nov 3 03:02:44 chaos kernel: st0: Error with sense data: [valid=0] Info fld=0x0, Current st09:00: sense key Medium Error Nov 3 03:02:44 chaos kernel: Additional sense indicates Write append position error Nov 3 03:02:44 chaos kernel: st0: Error on write filemark. Curiously, each of the three times, the tape error occurs just under 3 minutes into the amdump run. Of course, the amflush the next day works just fine, taking almost an hour to do so. All of these runs (both the dumps and the flushes) are to brand new tapes. I'm running 2.4.2 pulled out of CVS on 10/19/00, and my tape drive is an EXB8505XL in a Sun enclosure hanging off an AHA2940UW. I'm using Exabyte 160m XL tapes. Any ideas? Thanks. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
strange dumps ?
Can you tell me something about this report ? What does it mean FAILURE
AND STRANGE DUMP
(magnus is a nt client, technix the tape server).
Thanx, Michael
These dumps were to tape ordix05.
Tonight's dumps should go onto 1 tape: a new tape.
FAILURE AND STRANGE DUMP SUMMARY:
technix.kn /var lev 0 STRANGE
technix.kn //magnus/download lev 0 STRANGE
technix.kn //magnus/orpheus lev 0 STRANGE
STATISTICS:
Total Full Daily
Dump Time (hrs:min)0:41 0:40 0:00 (0:00 start,
0:00 idle)
Output Size (meg)1771.1 1771.10.0
Original Size (meg) 4641.1 4641.10.0
Avg Compressed Size (%)38.2 38.2--
Tape Used (%) 17.3 17.30.0
Filesystems Dumped 11 11 0
Avg Dump Rate (k/s) 749.0 749.0--
Avg Tp Write Rate (k/s) 746.5 746.5--
FAILED AND STRANGE DUMP DETAILS:
/-- technix.kn /var lev 0 STRANGE
sendbackup: start [technix.kn.ordix.de:/var level 0]
sendbackup: info BACKUP=/bin/gtar
sendbackup: info RECOVER_CMD=/bin/gtar -f... -
sendbackup: info end
? gtar: ./run/ndc: socket ignored
? gtar: ./tmp/.oracle/s#1139.1: socket ignored
? gtar: ./tmp/.oracle/s#14346.1: socket ignored
? gtar: ./tmp/.oracle/s#1538.1: socket ignored
? gtar: ./tmp/.oracle/s#26530.1: socket ignored
? gtar: ./tmp/.oracle/s#29216.1: socket ignored
? gtar: ./tmp/.oracle/sEXTPROC: socket ignored
? gtar: ./tmp/.oracle/sSNMP_ADDRESS_FOR_ORACLE_SUBAGENT: socket ignored
| Total bytes written: 17592320 (17MB, 2.4MB/s)
sendbackup: size 17180
sendbackup: end
\
/-- technix.kn //magnus/download lev 0 STRANGE
sendbackup: start [technix.kn.ordix.de://magnus/download level 0]
sendbackup: info BACKUP=/opt/samba/bin/smbclient
sendbackup: info RECOVER_CMD=/opt/samba/bin/smbclient -f... -
sendbackup: info end
?2802409 ( 624.4 kb/s) \apache131.exe
? 552720 ( 431.8 kb/s) \COMCTL32.DLL
? directory \FlopImager\
?1474560 ( 449.0 kb/s) \FlopImager\9xboot.dsk
? 112981 ( 158.8 kb/s) \FlopImager\flpimg13.zip
?1505032 ( 541.5 kb/s) \instmsi.exe
? 19415 ( 167.8 kb/s) \md5.exe
?5134365 ( 193.2 kb/s) \perl5win_tar.gz
? 35720696 ( 650.7 kb/s) \SP6I386.EXE
? tar: dumped 9 files and directories
| Total bytes written: 47324160
sendbackup: size 46215
sendbackup: end
\
/-- technix.kn //magnus/orpheus lev 0 STRANGE
sendbackup: start [technix.kn.ordix.de://magnus/orpheus level 0]
sendbackup: info BACKUP=/opt/samba/bin/smbclient
sendbackup: info RECOVER_CMD=/opt/samba/bin/smbclient -f... -
sendbackup: info end
? directory \BIN\
?6322831 ( 556.3 kb/s) \BIN\orp3.05.01.exe
?6323060 ( 631.4 kb/s) \BIN\orpheus.exe
?6280676 ( 672.4 kb/s) \BIN\orpheus3.04.01.exe
?6307697 ( 574.3 kb/s) \BIN\orpheus3.05.00.exe
?6319795 ( 572.7 kb/s) \BIN\orpheus30501.exe
?2168256 ( 429.5 kb/s) \BIN\secure.exe
? directory \DOKU\
? directory \DOKU\NEU\
? 8628 ( 172.0 kb/s) \DOKU\NEU\ORDIX.GID
? 89878 ( 358.3 kb/s) \DOKU\NEU\ORDIX.HLP
? 79360 ( 493.6 kb/s) \DOKU\ordix.FTS
? 8628 ( 115.4 kb/s) \DOKU\ordix.GID
? 249539 ( 618.5 kb/s) \DOKU\ORDIX.HLP
? 1177 ( 54.7 kb/s) \DOKU\QRP.TXT
[]
? tar: dumped 277 files and directories
| Total bytes written: 67033600
sendbackup: size 65463
sendbackup: end
\
NOTES:
planner: Adding new disk technix.kn.ordix.de:/etc.
planner: Adding new disk technix.kn.ordix.de:/home.
planner: Adding new disk technix.kn.ordix.de:/opt.
planner: Adding new disk technix.kn.ordix.de:/lib.
planner: Adding new disk technix.kn.ordix.de:/oracle.
planner: Adding new disk technix.kn.ordix.de:/oradata1.
planner: Adding new disk technix.kn.ordix.de:/oradata2.
planner: Adding new disk technix.kn.ordix.de:/usr.
planner: Adding new disk technix.kn.ordix.de:/var.
planner: Adding new disk technix.kn.ordix.de://magnus/download.
planner: Adding new disk technix.kn.ordix.de://magnus/orpheus.
taper: tape ordix05 kb 1813920 fm 11 [OK]
DUMP SUMMARY:
DUMPER STATS
TAPER STATS
HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s
MMM:SS KB/s
-- --
--
technix.k -gnus/download 0462158 96.21:32 481.3
1:33 480.6
technix.k -agnus/orpheus 06546345888 70.12:44 280.0
2:44 279.8
technix.k /etc 0 2590 672 25.90:03 212.6
0:05 140.1
technix.k /home 0 314240 236288 75.24:37 851.9
4:38 849.6
technix.k /lib 02920011360 38.90:14 812.6
0:15 772.1
technix.k /opt 026720 8928 33.40:11 825.0
0:12 773.5
technix.k /oracle0 2583050 1122048 43.4 22:43 823.1
22:44 822.6
technix.k /oradata1 0 1100360 1087
Re: back to square 1 (fwd)
Sorry, wrong mailinglist address on the first try.
-- Forwarded message --
Date: Fri, 3 Nov 2000 13:31:34 +0100 (CET)
From: Peter Schaffrath <[EMAIL PROTECTED]>
To: Denise Ives <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: back to square 1
Hi Denise!
One point first: make sure you always reply to amanda-users,too. It
increases chances that somebody knows what to answer you. I'm definitely
not the most experienced one on the list. And it helps my mail filter to
sort your mail to the amanda folder... :-)
> Are you saying - any of the below example dumptypes from amanda.conf will
> work? Which one of these is the default dumptype to use?
>
> define dumptype always-full {
> global
> comment "Full dump of this filesystem always"
> compress none
> priority high
> dumpcycle 0
> }
As I said, this one won't do incrementals. "dumpcycle 0" is the code in
dumptypes that says: always do full dumps.
There are two locations where the dumptype entry may appear in
amanda.conf. One in general, at the beginning. It says, as the comment in
the example file states: "the number of days in the normal dump cycle". In
other words: it's the maximum number of days during full dumps. The number
you specify there is valid for all dumps, unless you specify something
else in a dumptype definition. This is a second possible location of a
dumpcycle statement, which is then only valid for the disk you use this
dumptype with (due to the entry in your disklist file).
I can't tell you which dumptype you should use. Just put together all
aspects you need in one dumptype and use this:
- never use "dumpcycle 0" if you want incremental dumps
- use "index yes" if you want to have amanda index what files are dumped
to which tape on which date (to use amrecover)
- choose wether you want compression or not
- if yes, chose if the date should be compressed on the client or the
server
...
I use quite simple dumptypes:
define dumptype global {
comment "Global definitions"
program "GNUTAR"
index yes
compress none
holdingdisk no
}
That is I use gtar as the dump program, I want an index, I don't compress
the data and I do not have a holding disk.
Sometimes I use two other dumptypes:
define dumptype always-full {
global
comment "Full dump of this filesystem always"
dumpcycle 0
}
This has all the functions from my global dumptype but always does full
dumps.
define dumptype sissi {
global
exclude list "exclude-file"
}
This reads an exclude list from "exclude-file" on the client, all the
other settings are inherited from "global" again.
Hope this helped, Peter
Re: HP-UX 11.00 client not responding
> What's in /tmp/amanda/*.debug on the client? > Here's the complete file: Start amandad: debug 1 pid 12061 ruid 401 euid 401 start time Fri Nov 3 11:44:02 2000 /usr/local/libexec/amandad: version 2.4.1p1 /usr/local/libexec/amandad: build: VERSION="Amanda-2.4.1p1" /usr/local/libexec/amandad:BUILT_DATE="Thu Nov 2 11:30:34 SAST 2000" /usr/local/libexec/amandad:BUILT_MACH="HP-UX heri2000 B.11.00 A 9000/819 23631322 two-user license" /usr/local/libexec/amandad:CC="gcc" /usr/local/libexec/amandad: paths: bindir="/usr/local/bin" sbindir="/usr/local/sbin" /usr/local/libexec/amandad:libexecdir="/usr/local/libexec" mandir="/usr/local/man" /usr/local/libexec/amandad:CONFIG_DIR="/usr/local/etc/amanda" DEV_PREFIX="/dev/dsk/" /usr/local/libexec/amandad:RDEV_PREFIX="/dev/rdsk/" DUMP="/usr/sbin/dump" /usr/local/libexec/amandad:RESTORE="/sbin/restore" VXDUMP="/sbin/vxdump" /usr/local/libexec/amandad:VXRESTORE="/sbin/vxrestore" /usr/local/libexec/amandad:COMPRESS_PATH="/usr/contrib/bin/gzip" /usr/local/libexec/amandad: UNCOMPRESS_PATH="/usr/contrib/bin/gzip" /usr/local/libexec/amandad:MAILER="/usr/bin/mailx" /usr/local/libexec/amandad: defs: DEFAULT_SERVER="backups.its.uct.ac.za" /usr/local/libexec/amandad:DEFAULT_CONFIG="tssunix2" /usr/local/libexec/amandad: DEFAULT_TAPE_SERVER="backups.its.uct.ac.za" /usr/local/libexec/amandad:DEFAULT_TAPE_DEVICE="/dev/nrsa0" HAVE_SYSVSHM /usr/local/libexec/amandad:LOCKING=POSIX_FCNTL SETPGRP_VOID DEBUG_CODE BSD_SECURITY /usr/local/libexec/amandad:USE_AMANDAHOSTS CLIENT_LOGIN="amanda" FORCE_USERID HAVE_GZIP /usr/local/libexec/amandad:COMPRESS_SUFFIX=".gz" COMPRESS_FAST_OPT="--fast" /usr/local/libexec/amandad:COMPRESS_BEST_OPT="--best" UNCOMPRESS_OPT="-dc" amandad: error receiving message: timeout -- End - Austin -- Austin Chamberlain +27 21 650 4121 Technical Support Services, ITS, University of Cape Town What's this stuff about people being "released on their own recognizance"? Aren't we all out on our own recognizance?
Re: HP-UX 11.00 client not responding
> I have an unusual problem with an HP-UX 11.00 client running Amanda > 2.4.1p1. The backup server is running FreeBSD 4.0-STABLE. amcheck > returns the following: > > heri2000.u /usr lev 0 FAILED [Request to heri2000.uct.ac.za timed out.] > > The same client configuration works successfully on HP-UX 10.20 and > several FreeBSD and Linux machines. It seems that amandad simply is not > responding to any attempts to connect to amandad - logs show the > registrar service, on port 1712, responding to the amcheck request! What's in /tmp/amanda/*.debug on the client? -Mitch
changer.conf for Breecehill QT2.15 tape robot
Hello, Does anyone have a working changer.conf file for a Breecehill QT2.15 robot?? This tape robot has 15 cartridges and a DLT4000 dirive Clem Kumah Telinco Limited Tel: +44 (0)870 748 4000 [EMAIL PROTECTED]Fax: +44 (0)870 748 4001
HP-UX 11.00 client not responding
Hi all I have an unusual problem with an HP-UX 11.00 client running Amanda 2.4.1p1. The backup server is running FreeBSD 4.0-STABLE. amcheck returns the following: heri2000.u /usr lev 0 FAILED [Request to heri2000.uct.ac.za timed out.] The same client configuration works successfully on HP-UX 10.20 and several FreeBSD and Linux machines. It seems that amandad simply is not responding to any attempts to connect to amandad - logs show the registrar service, on port 1712, responding to the amcheck request! Does anyone have any ideas? Austin -- Austin Chamberlain +27 21 650 4121 Technical Support Services, ITS, University of Cape Town What's this stuff about people being "released on their own recognizance"? Aren't we all out on our own recognizance?
Re: running amcheck
On Thu, 2 Nov 2000, Denise Ives wrote: > Looks like there is no problem with client connections - > but the subject header does have this BOLD warning message. > Can this be ignored? No! You don't have a problem with your client connections, as you realized. But have a look at the server report: you don't have any tape loaded! So, if you only wanted to check the connections and the settings of your clients, everything is ok. But you can not run amanda/amdump now, of course. You have to insert a tape. If you've already inserted a tape, then there's a problem with your tape drive. It doesn't recognize your tape. Is this the case? I had to cope with this problem a few days ago. Turned out that the SCSI cable was broken. > > Subject: daily AMANDA PROBLEM: FIX BEFORE RUN, IF POSSIBLE > > Amanda Tape Server Host Check > - > /dump/amanda: 9977052 KB disk space available, using 9465052 KB. > ERROR: /dev/rmt/0cbn: no tape online. >(expecting a new tape) > NOTE: skipping tape-writable test. > Server check took 20.064 seconds. > > Amanda Backup Client Hosts Check > > Client check: 2 hosts checked in 0.112 seconds, 0 problems found. > > (brought to you by Amanda 2.4.1p1) > >
Amanda + smbclient: about the archive bit
hello there, I'm backing up (full & incremental) my windows PCs using Amanda & Samba's "smbclient". Smbclient unset the archive bit on all the backed up files onto the PC hardisk, so as to make incremental backups possible. Does someone have heard about any conflicts with some Windows programs that may use the archive bit for other matters? Any feedback helpful! thanks, Pierre.
