On Fri, Jun 02, 2006 at 11:46:57PM -0400, Jon LaBadie wrote:
> On Fri, Jun 02, 2006 at 08:28:40PM -0400, Jean-Louis Martineau wrote:
> > Jon LaBadie wrote:
> > >Following up to my own reply:
> > >
> > >I checked the most recent debug files and they show the "*.new" files
> > >are being used.  For example, corresponding to the last listing above,
> > >two lines from sendbackup...debug:
> > >
> > >sendbackup-gnutar: time 0.207: doing level 1 dump as listed-incremental \
> > >  to /var/lib/amanda/gnutar-lists/bigcowUSR_1.new
> > >
> > >sendbackup: argument list: gtar --create --file - --directory /usr \
> > >  --one-file-system \
> > >  --listed-incremental /var/lib/amanda/gnutar-lists/bigcowUSR_1.new \
> > >  --sparse --ignore-failed-read --totals \
> > >  --exclude-from /tmp/amanda/sendbackup.USR.20060602043755.exclude .
> > >  
> > sendbackup should rename the file (remove  the .new) when the backup finish.
> > Anything in the log showing why it don't rename it?
> > 
> > That's why you get full dump at every level.
> 
> 
> Nothing about failure to rename, just failure to open the *_0 file.  Here is
> a section from one of the clients.
> 
>   sendbackup: time 0.005: got all connections
>   sendbackup: time 0.006: spawning /usr/bin/gzip in pipeline
>   sendbackup: argument list: /usr/bin/gzip --fast
>   sendbackup-gnutar: time 0.007: pid 21554: /usr/bin/gzip --fast
>   sendbackup-gnutar: time 0.014: error opening \
>     /usr/local/var/amanda/gnutar-lists/butchU_0: No such file or directory
>   sendbackup-gnutar: time 0.014: doing level 1 dump as listed-incremental \
>     to /usr/local/var/amanda/gnutar-lists/butchU_1.new
>   sendbackup-gnutar: time 0.307: doing level 1 dump from date: 1970-01-01  
> 0:00:00 GMT
>   sendbackup: Can't open exclude file '/usr/local/lib/amanda/exclude.gtar': \
>     No such file or directory
>   sendbackup: time 0.309: spawning /usr/local/libexec/runtar in pipeline
>   sendbackup: argument list: gtar --create --file - --directory /u 
> --one-file-system \
>     --listed-incremental /usr/local/var/amanda/gnutar-lists/butchU_1.new 
> --sparse \
>     --ignore-failed-read --totals --exclude-from \
>     /tmp/amanda/sendbackup.U.20060530030800.exclude .
>   sendbackup: time 0.315: started index creator: "/usr/local/libexec/amgtar 
> -tf - \
>     2>/dev/null | sed -e 's/^\.//'"
>   sendbackup-gnutar: time 0.316: /usr/local/libexec/runtar: pid 21556
>   sendbackup: time 764.914: index created successfully
> 
> 
> BTW it is happening on the server and both direct clients.  Server is now 
> running
> the 2.5.0p2 rpm package from zmanda for Fedora Core 4.  It had the same 
> problem
> when running Fedora's 2.4.5 version.
> 
> One client is SuSE 10.0 running their 2.4.5 version, the other is Solaris 9
> running a self-built 2.4.4.
> 

Before my overnight amdump run I took the following steps on my 3 direct 
clients.

On one I left the gnutar-lists as they were, all with the ".new" extension.
On one (also the server) I renamed all the files, removing the ".new"
On the last, I removed the ".new" from the lists from half the DLEs (3 of 6).

Incrementals did work on those that had their gnutar-list files renamed.
(: and total dump size dropped from 75GB to 50GB ;)

HOWEVER, the recreated "*.new" files still were not renamed.
I was unable to find any error message related to renaming them.

For tonight, I plan to strip all the ".new" extensions.  This will of course
overwrite any list file with the same root name.  But at least incrementals
should work and I should see another substantial drop in the size of the dump.

Any ideas on why the automatic renaming is not happening.
Just to refresh, renaming is not occuring on each client with very different
installations (OS & amanda versions) and was also failing on a previous,
older version amanda installation on the server.

-- 
Jon H. LaBadie                  jon AT jgcomp DOT com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)