On Wednesday 31 January 2007 01:27, Toomas Aas wrote:
>Hello!
>
>First, the system details:
>FreeBSD 6.2-RELEASE
>Amanda 2.5.1p2
>GNU tar 1.16
>All DLEs use GNU tar for backup
>
>I noticed a strange problem today with this rather new Amanda setup.
> Yesterday, a level 0 backup was done of one particular DLE. This DLE is
> ca 50 GB in size, which compresses to ca 40 GB. Today's amdump run
> started doing level 1 of this same DLE and wrote ca 35 GB, at which
> point the HDD holding vtapes ran out of space.
>
>Level 1 backup of this particular DLE definitely shouldn't be so big. I
> looked at sendsize.debug and noticed an interesting problem. The
> estimates for level >0 backups for all DLEs are the same size as
> estimates for level 0.
>
>On previous night's amdump run, this problem did not happen - estimates
> for incremental backups were noticeably smaller than level 0.
>
>I noticed an interesting warning message about gnutar_calc_estimates in
> sendsize.debug, but this was also present in sendsize.debug for these
> amdump runs that didn't have the "incremental equal to full" problem.
> So I'm not sure if this is the problem at all.
>
>Below is the snippet of sendsize.debug for one DLE, which shows level 1
> estimated as big as level 0. I'd appreciate any ideas regarding what
> might be the reason for this.
>
>sendsize[11170]: time 0.636: calculating for amname /storage, dirname
> /storage, spindle 1 sendsize[11170]: time 0.636: getting size via
> gnutar for /storage level 0 sendsize[11170]: time 0.658: spawning
> /usr/local/libexec/amanda/runtar in pipeline sendsize[11170]: argument
> list: runtar BACKUP /usr/local/bin/gtar --create --file /dev/null
> --directory /storage --one-file-system --listed-incremental
> /var/amanda/gnutar-lists/server.domain.ee_storage_0.new --sparse
> --ignore-failed-read --totals --exclude-from
> /tmp/amanda/sendsize._storage.20070131052001.exclude .
>sendsize[11170]: time 139.437: Total bytes written: 51728097280 (49GiB,
> 357MiB/s) sendsize[11170]: time 139.440: .....
>sendsize[11170]: estimate time for /storage level 0: 138.782
>sendsize[11170]: estimate size for /storage level 0: 50515720 KB
>sendsize[11170]: time 139.440: waiting for runtar "/storage" child
>sendsize[11170]: time 139.440: after runtar /storage wait
>gnutar_calc_estimates: warning - seek failed: Illegal seek
>sendsize[11170]: time 139.441: getting size via gnutar for /storage
> level 1 sendsize[11170]: time 139.905: spawning
> /usr/local/libexec/amanda/runtar in pipeline sendsize[11170]: argument
> list: runtar BACKUP /usr/local/bin/gtar --create --file /dev/null
> --directory /storage --one-file-system --listed-incremental
> /var/amanda/gnutar-lists/server.domain.ee_storage_1.new --sparse
> --ignore-failed-read --totals --exclude-from
> /tmp/amanda/sendsize._storage.20070131052220.exclude .
>sendsize[11170]: time 206.462: Total bytes written: 51728097280 (49GiB,
> 745MiB/s) sendsize[11170]: time 206.468: .....
>sendsize[11170]: estimate time for /storage level 1: 66.563
>sendsize[11170]: estimate size for /storage level 1: 50515720 KB
>sendsize[11170]: time 206.468: waiting for runtar "/storage" child
>sendsize[11170]: time 206.468: after runtar /storage wait
>gnutar_calc_estimates: warning - seek failed: Illegal seek
>sendsize[11170]: time 206.468: done with amname /storage dirname
> /storage spindle 1
I wonder if that version of tar is biting us again. Can you back up to
1.15-1 and give that a try?
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2007 by Maurice Eugene Heskett, all rights reserved.
|
