amrecover: cannot connect to host (connection refused)
Hello,
I am using RedHat 7.0 with xinetd-2.1.8.9pre11-1.
amcheck and amdump are working properly, but if I want
to restore files from dump using amrecover, the tool
is not working.
Everything is called from the same host (localhost).
This is what the amrecover sends to stdout:
AMRECOVER Version 2.4.1p1. Contacting server on localhost ...
amrecover: Unexpected server end of file
And this is what I found in /var/log/messages:
Jan 29 07:51:51 myhost xinetd[1318]: xinetd Version 2.1.8.9pre11
started with
Jan 29 07:51:51 myhost xinetd[1318]: libwrap
Jan 29 07:51:51 myhost xinetd[1318]: options compiled in.
Jan 29 07:51:51 myhost xinetd[1318]: Started working: 8 available
services
Jan 29 07:51:54 myhost xinetd: xinetd startup succeeded
Jan 29 07:52:07 myhost xinetd[1318]: warning: can't get client
address: Invalid argument
Jan 29 07:52:07 myhost xinetd[1318]: file descriptor of service
amandaidx has been closed
Jan 29 07:52:07 myhost xinetd[1318]: select reported EBADF but no bad
file descriptors were found
I think, the problem is:
warning: can't get client address: Invalid argument
but do you know when this could happened?
This happens only the very first time, if I try to connect
via amrecover the next time, nothing happens in the syslog,
but the amrecover client barfs:
AMRECOVER Version 2.4.1p1. Contacting server on localhost ...
amrecover: Error connecting to server: Connection refused
It is possible for operator and root to do an rsh localhost .
The permissions for /root/.rhosts
-rw---1 root root25 Jan 28 23:44 /root/.rhosts
The permissions for /root/.amandahosts
-rw---1 operator disk 107 Jan 29 00:29 /root/.amandahosts
Amanda-User: operator
User Operator is in 'disk' group.
If you need the information of /etc/xinet.d/am*
I will attach these files. I tried to use the amanda inetd-entries
w/o tcp_wrappers, but the errors are still the same.
I will also put the debug output of /tmp/amanda to this mail.
So, I am not subscribed to the mailing list, please
do a CC to mailto:[EMAIL PROTECTED]
Any suggestions?
thanx in advance,
Sebastian
# default: on
#
# description: Part of the Amanda server package
service amanda
{
socket_type = dgram
protocol= udp
wait= yes
user= operator
group = disk
server = /usr/lib/amanda/amandad
disable = no
}
# default: off
#
# description: Part of the Amanda server package
#
service amandaidx
{
socket_type = stream
protocol= tcp
wait= yes
user= operator
group = disk
server = /usr/lib/amanda/amindexd
disable = no
}
# default: off
#
# description: Part of the amanda server package
#
service amidxtape
{
socket_type = stream
protocol= tcp
wait= no
user= operator
group = disk
server = /usr/lib/amanda/amidxtaped
disable = no
}
amandad: debug 1 pid 932 ruid 11 euid 11 start time Mon Jan 29 07:34:19 2001
amandad: version 2.4.1p1
amandad: build: VERSION="Amanda-2.4.1p1"
amandad:BUILT_DATE="Mon Aug 21 16:31:37 EDT 2000"
amandad:BUILT_MACH="Linux porky.devel.redhat.com 2.2.5-22smp #1 SMP Wed Jun 2
09:11:51 EDT 1999 i686 unknown"
amandad:CC="gcc"
amandad: paths: bindir="/usr/bin" sbindir="/usr/sbin"
amandad:libexecdir="/usr/lib/amanda" mandir="/usr/share/man"
amandad:CONFIG_DIR="/etc/amanda" DEV_PREFIX="/dev/"
amandad:RDEV_PREFIX="/dev/r" DUMP="/sbin/dump"
amandad:RESTORE="/sbin/restore" SAMBA_CLIENT="/usr/bin/smbclient"
amandad:GNUTAR="/bin/tar" COMPRESS_PATH="/usr/bin/gzip"
amandad:UNCOMPRESS_PATH="/usr/bin/gzip" MAILER="/usr/bin/Mail"
amandad:listed_incr_dir="/var/lib/amanda/gnutar-lists"
amandad: defs: DEFAULT_SERVER="localhost" DEFAULT_CONFIG="DailySet1"
amandad:DEFAULT_TAPE_SERVER="localhost"
amandad:DEFAULT_TAPE_DEVICE="/dev/null" HAVE_MMAP HAVE_SYSVSHM
amandad:LOCKING=POSIX_FCNTL SETPGRP_VOID DEBUG_CODE BSD_SECURITY
amandad:USE_AMANDAHOSTS CLIENT_LOGIN="operator" FORCE_USERID
amandad:HAVE_GZIP COMPRESS_SUFFIX=".gz" COMPRESS_FAST_OPT="--fast"
amandad:COMPRESS_BEST_OPT="--best" UNCOMPRESS_OPT="-dc"
got packet:
Amanda 2.4 REQ HANDLE 000-90D50508 SEQ 980750029
SECURITY USER operator
SERVICE sendbackup
OPTIONS hostname=localhost;
GNUTAR /etc 1 2001:1:27:2:25:7 OPTIONS
|;bsd-auth;compress-fast;index;exclude-list=/usr/local/lib/amanda/exclude.gtar;
sending ack:
Amanda 2.4 ACK HANDLE 000-90D50508 SEQ 980750029
-
Re: DDS4 parameters
On Sat, 27 Jan 2001, Jason Winchell wrote:
> Does anyone know the parameters for DDS4, 150m, 20GB/40GB tapes?
I can offer the following:
define tapetype DDS4 {
comment "DDS 4 tapes 150 m"
length 19400 mbytes
filemark 32 kbytes
speed 2700 kbytes
}
This has been evaluated with a Seagate Scorpion 240.
Martin
RE: why | ufsrestore?
> >I have always wondered .. why does amanda pipe ufsdump output to > ufsrestore > >before sending it to the tape device? > > It's collecting the index data. John, thanks for clarifying... > >If amanda is dumping direct to tape (file systems that are > bigger than the > >holding disk), I'm lucky if i get 1mb/second. > > > >If it's going from the holding disk to tape, I get 3mb/second, > as expected. > > But you're comparing apples and oranges. As you've noted, going from > disk to tape on the same machine gets 3 MBytes/s whether you are using > ufsdump or Amanda is using taper to copy a holding disk image. > > But that's not what happens when Amanda is dumping a client direct to > tape. The data has to go across the network (even if it's all on the > local machine it still goes through the kernel network stack). And, > probably even more important, Amanda does compression when dumping, > not when writing to tape. > > So a dump to holding disk would be "slow" but the corresponding holding > disk to tape operation would be "fast". But a direct to tape backup > would pay the penalty and show the speed loss due to compression even > though the tape I/O portion is going as fast as it is given data. I should have mentioned, we have several ~10Gb file systems (on the same system as the tape drive, Amanda server), and none of these are dumped with compression (for speed reasons). > You didn't mention what kind of dump rates Amanda reports. Those should > more or less match your direct to tape numbers for large enough images > to get a good sample and with similar clients. The dump rates reported by Amanda are around 1.0-1.5mb/second (without compression). A direct ufsdump to tape without Amanda on the same file systems run at 3mb/second (which is the fastest that the tape drive can accept the data). Given the complexity of the Amanda sendbackup process this doesn't exactly surprise me, but I wondered if I could do anything to speed things up. The system is a little underpowered and perhaps when we get our much needed upgrade (a nice new dual cpu E220R), things will improve... g.
Re: why | ufsrestore?
>I have always wondered .. why does amanda pipe ufsdump output to ufsrestore >before sending it to the tape device? It's collecting the index data. The dump (or tar) output pipeline is rather complicated. The image data goes back to sendbackup who in turn tee's it to the restore program to gather the index information (if indexing is enabled) as well as sending the raw data (possibly through a compression program) back on the network to a dumper process on the server side. The restore program also feeds its results back through sendbackup to be sent to the dumper on a different socket (as I recall). So sendbackup is multiplexing five data streams: * reading the dump image coming in from the backup program * writing the image out to the index (restore) process * writing the image out the socket connected to dumper on the server or to a compression program * reading the output of the index process * writing the index data to another socket back to dumper >If I ufsdump direct to tape, eg. > >ufsdump 0f /dev/rmt/0n / > >I consistently achieve 3mb/second (Exabyte mammoth). > >If amanda is dumping direct to tape (file systems that are bigger than the >holding disk), I'm lucky if i get 1mb/second. > >If it's going from the holding disk to tape, I get 3mb/second, as expected. But you're comparing apples and oranges. As you've noted, going from disk to tape on the same machine gets 3 MBytes/s whether you are using ufsdump or Amanda is using taper to copy a holding disk image. But that's not what happens when Amanda is dumping a client direct to tape. The data has to go across the network (even if it's all on the local machine it still goes through the kernel network stack). And, probably even more important, Amanda does compression when dumping, not when writing to tape. So a dump to holding disk would be "slow" but the corresponding holding disk to tape operation would be "fast". But a direct to tape backup would pay the penalty and show the speed loss due to compression even though the tape I/O portion is going as fast as it is given data. You didn't mention what kind of dump rates Amanda reports. Those should more or less match your direct to tape numbers for large enough images to get a good sample and with similar clients. Note that I'm not saying something isn't wrong in Amanda. Just that we need to narrow down the list of culprits. >g. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amreport broken between 2.4.1p1 and 2.4.2
>The email output of amreport seems to have been broken somewhere between >2.4.1p1 and 2.4.2. What you call "broken", others call a new "feature" :-). Look for "columnspec" in "man amanda". FYI, here's what I use: columnspec "OrigKB=1:8,OutKB=1:8,DumpRate=0:7,TapeRate=0:7" >It would also make more sense (to me, at least) for the output figures to be >represented in Mb and Mb/sec rather than Kb and Kb/sec. This would probably >help the email readability. Patches are welcome. Probably as some extension to columnspec (maybe a multiplication factor and another field for the column heading text?). >g. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
why | ufsrestore?
I have always wondered .. why does amanda pipe ufsdump output to ufsrestore before sending it to the tape device? If I ufsdump direct to tape, eg. ufsdump 0f /dev/rmt/0n / I consistently achieve 3mb/second (Exabyte mammoth). If amanda is dumping direct to tape (file systems that are bigger than the holding disk), I'm lucky if i get 1mb/second. If it's going from the holding disk to tape, I get 3mb/second, as expected. g.
amreport broken between 2.4.1p1 and 2.4.2
The email output of amreport seems to have been broken somewhere between 2.4.1p1 and 2.4.2. The column widths are incorrectly determined and the output is particularly messy with large file systems (and/or large lengths of time, etc). It would also make more sense (to me, at least) for the output figures to be represented in Mb and Mb/sec rather than Kb and Kb/sec. This would probably help the email readability. Comments, thoughts? g.
