Re: Infinite loop in amdump
>Everything goes well until amanda begins to beckup /myfs/sources. >At this point it seems to loop /myfs/sources dumping forever, each time >erasing dump file and >starting again. How do you know it's restarting? >This is the output of amstatus after I killed amanda at its 4th dump of >/myfs/sources: Amstatus is pretty much useless for this kind of debugging. What was in the Amanda E-mail report after you killed it? Looking at the matching amdump. file, find where it does either a FILE-WRITE or PORT-WRITE of that area. Anything out of the ordinary from that point on? Can you re-configure/re-build/re-install using --with-pid-debug-files, make another run and look at the /tmp/amanda/sendbackup*debug files on that client after it appears to restart? >Vincenzo John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amrecover problem
>I'm unable to see all backed up files while browsing trough the directorys >via amrecover, but viewing the index-files manualy showed that the files are >included in the backup... Please send me (it's probably too big for the whole list) the contents of the /tmp/amanda/amindexd*debug file that matches this error and also send the exact set of commands you entered to amrecover. >-- Mirko John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Help to solve a dump problem
>Everything was running smoothly until about 30 days ago. So the obvious question is, what did you change 30 days ago :-)? >driver: dumping sv:da0s1f directly to tape >driver: send-cmd time 3469.442 to taper: PORT-WRITE 00-00035 sv da0s1f 0 20001219 >driver: result time 3469.442 from taper: PORT 1596 This says driver told taper to get ready to do a direct to tape dump. Taper created a local socket and reported back the port number, 1596. All normal so far. >driver: send-cmd time 3469.443 to dumper0: PORT-DUMP 01-00036 1596 sv da0s1f 0 >1970:1:1:0:0:0 DUMP |;bsd-auth;compress-best;index; This is driver then telling dumper0 to start the direct to tape dump and that taper is listening on port 1596. Still normal. >driver: result time 3469.444 from dumper0: FAILED 01-00036 [taper port open: >Connection refused] This says dumper0 was not able to create the connection to taper due to "Connection refused". >driver: result time 3589.442 from taper: TAPE-ERROR 00-00035 [port connect timeout] Finally, this says taper got tired of waiting on a dumper to connect. So the real problem is why dumper could not connect to taper on localhost, and I'm afraid I don't have any good ideas. It's possible for that error to come out of stream_client in several places (although I strongly suspect it's the connect() call). The following patch will log which place threw the error (it's just for debugging, not a fix). You only need to rebuild/install the server, not the clients. Did you do anything "odd" with your network setup that would cause it to be confused about what "localhost" means? >Helio. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] stream.diff
Re: Amrecover Please Help
>AMRECOVER Version 2.4.2. Contacting server on cacoon ... >... >root@cacoon _test]# ls -al >total 12 >drwxr-sr-x 2 root root 4096 Dec 24 09:15 . >drwxr-sr-x 3 root root 4096 Dec 24 09:15 .. >-rw--- 1 root root 34 Dec 24 09:15 20001224_0.gz >[root@cacoon _test]# pwd >/usr/local/etc/amanda/DailySet1/index/clipper.monarch.net/_test What user is configured to run amandaidx in inetd.conf (or xinetd.conf)? If it's not root, you can't read the file because of the permissions. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Amrecover Please Help
I've been reading the archives, and have seen several posts on this. I can't read the index files. What could I be doing wrong. The server is 2.4.2 on RedHat 7 with a Treefrog Changer. The client I'm running in FreeBSD 3.2 Running 2.4.2. it dumps just fine, I can restore just fine. Here some info. Any help would be great. Running amrecover from client, same results as doing it from server: amrecover -s cacoon AMRECOVER Version 2.4.2. Contacting server on cacoon ... 220 cacoon AMANDA index server (2.4.2) ready. 200 Access OK Setting restore date to today (2000-12-24) 200 Working date set to 2000-12-24. 200 Config set to DailySet1. 200 Dump host set to clipper.monarch.net. Can't determine disk and mount point from $CWD amrecover> setdisk /test Scanning /dumps/amanda/secondary... Scanning /dumps/amanda/primary... 200 Disk set to /test. No index records for disk for specified date If date correct, notify system administrator On server its creating the index on dump root@cacoon _test]# ls -al total 12 drwxr-sr-x 2 root root 4096 Dec 24 09:15 . drwxr-sr-x 3 root root 4096 Dec 24 09:15 .. -rw--- 1 root root 34 Dec 24 09:15 20001224_0.gz [root@cacoon _test]# pwd /usr/local/etc/amanda/DailySet1/index/clipper.monarch.net/_test [root@cacoon _test]# === More info, heres my disklist clipper.monarch.net /test comp-user-tar === Heres a amadmin check [root@cacoon DailySet1]# amadmin DailySet1 disklist line 1: host clipper.monarch.net: interface default disk /test: program "GNUTAR" exclude list "/usr/local/lib/amanda/exclude.gtar" priority 0 dumpcycle 28 maxdumps 1 strategy STANDARD compress CLIENT FAST comprate 0.50 0.50 auth BSD kencrypt NO holdingdisk YES record YES index YES skip-incr NO skip-full NO
Re: Userid for pre-packaging binaries
Christopher Hamilton <[EMAIL PROTECTED]> wrote: > I am trying to set it up as an optional package for a Linux > distribution. "bin" does have a ~, it is /bin. /bin isn't exactly the You should not install it as bin, but as user backup (as e.g Debian does), or user amanda (as Amanda does by default). If you install it as user bin, then, yes, .amandahosts will have to be in ~bin, which is /bin in your case. > standard users to select from in our distribution, I can't add one just > for amanda. "root" is the only user we have that has an actual home You should. SuSE and Debian do.
