Amanda-Users

Re: Backups fail on new client: too many dumper retry

2006-06-21 12:37:42
Subject: Re: Backups fail on new client: too many dumper retry
From: Charles Curley <charlescurley AT charlescurley DOT com>
To: amanda-users AT amanda DOT org
Date: Wed, 21 Jun 2006 10:31:37 -0600
On Wed, Jun 21, 2006 at 10:05:35AM -0600, Charles Curley wrote:
> On Wed, Jun 21, 2006 at 11:11:36AM -0400, Jon LaBadie wrote:
> 
> > > 
> > > Looking at the log files, I see a typical runtar log as follows:
> > > 
> > > --------------------------------------------------
> > > runtar: debug 1 pid 6507 ruid 33 euid 0: start at Wed Jun 21 08:24:02 2006
> > > /bin/tar: version 2.4.5p1
> > > running: /bin/tar: /bin/tar --create --file /dev/null --directory /var 
> > > --one-file-system --listed-incremental 
> > > /var/lib/amanda/gnutar-lists/themoose.localdomain_var_0.new --sparse 
> > > --ignore-failed-read --totals . 
> > > runtar: pid 6507 finish time Wed Jun 21 08:24:02 2006
> > > --------------------------------------------------
> > > 
> > > I notice that the file is /dev/null. Is that correct?
> > > 
> > 
> > During estimates is it.
> > 
> > If gnutar outputs to /dev/null, it goes through all the
> > normal steps without actually reading the ordinary file
> > data blocks.  Saves mucho time for estimates.
> 
> I checked all the runtar log files; they all indicate the same output
> file. Where do I look to see the results of a backup, if any? The
> amandad...debug files seem to be the right place, but the sizes are
> all way too small.

I get to answer my own question. The results I want are in the
sendbackup....debug files. Here is one:

--------------------------------------------------
sendbackup: debug 1 pid 6542 ruid 33 euid 33: start at Wed Jun 21 08:26:53 2006
/usr/lib/amanda/sendbackup: version 2.4.5p1
  parsed request as: program `GNUTAR'
                     disk `/var'
                     device `/var'
                     level 0
                     since 1970:1:1:0:0:0
                     options `|;bsd-auth;compress-fast;index;'
sendbackup: try_socksize: send buffer size is 65536
sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.40885
sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.35734
sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.33697
sendbackup: time 0.001: waiting for connect on 40885, then 35734, then 33697
sendbackup: time 30.001: stream_accept: timeout after 30 seconds
sendbackup: time 30.002: timeout on data port 40885
sendbackup: time 60.002: stream_accept: timeout after 30 seconds
sendbackup: time 60.002: timeout on mesg port 35734
sendbackup: time 90.003: stream_accept: timeout after 30 seconds
sendbackup: time 90.003: timeout on index port 33697
sendbackup: time 90.004: pid 6542 finish time Wed Jun 21 08:28:23 2006
--------------------------------------------------

It looks like the client is misinformed about the server's IP address
if it is waiting for a connection at 0.0.0.0.40885. On the client, I
have /var/lib/amanda/.amandahosts, with two different names for the
server.

--------------------------------------------------
charlesc amanda
charlesc.localdomain amanda
--------------------------------------------------

Both resolve correctly. I can su to the amanda user on the server.

-- 

Charles Curley                  /"\    ASCII Ribbon Campaign
Looking for fine software       \ /    Respect for open standards
and/or writing?                  X     No HTML/RTF in email
http://www.charlescurley.com    / \    No M$ Word docs in email

Key fingerprint = CE5C 6645 A45A 64E4 94C0  809C FFF6 4C48 4ECD DFDB

Attachment: pgpBoGiha1PyX.pgp
Description: PGP signature