--On Sunday, August 29, 2004 15:17:50 +0200 Reidar Nordin <reidar AT tedk DOT 
com> wrote:

> 
>> Your 'tape' is full.  It doesn't necessarily mean the disk
>> is full, it could be that your backups exceed your tape length.
>> Look farther down in your report for the taper line and see if it
>> wrote as many bytes as you specified for the length in your tapetype.
>> If so, either increase your tape length (since you're really writing
>> to a file instead of to a tape) or increase runtapes to write to
>> multiple 'tapes'.
> 
> I have increased the length in tapetype from 10GB to 20GB but still got the 
> same error as desc. before
>  
> The dumpsummary for just this server (awe) says:
> ***
> 
>                                DUMPER STATS            TAPER STATS 
> HOSTNAME     DISK        L ORIG-KB OUT-KB COMP% MMM:SS  KB/s MMM:SS  KB/s
> awe          /home       0 FAILED ---------------------------------------
> awe          /httpd/conf 0     200     55  27.5   0:00 272.6   0:00 240.5
> awe          -/local/adm 0      30      2   6.7   0:00   5.0   0:00   7.0
> awe          -/lib/mysql 0  184160  22300  12.1   1:19 282.1   1:19 282.0
> ***
> 
> From the end of my amanda log:
> ***
> INFO taper tape backup09 kb 2188064 fm 30 writing file: short write

Looks like it died around 2 GB.

> FAIL taper awe /home 20040828 0 [out of tape]
> ERROR taper no-tape [[writing file: short write]]
> FAIL driver awe /home 20040828 0 [dump to tape failed]
> FAIL dumper awe /home 20040828 0 ["data write: Broken pipe"]
>   sendbackup: start [awe:/home level 0]
>   sendbackup: info BACKUP=/bin/tar
>   sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/bin/tar -f... -
>   sendbackup: info COMPRESS_SUFFIX=.gz
>   sendbackup: info end
> FINISH driver date 20040828 time 2188.326
> ***
>  
>> I'm guessing you're not using a holding disk.  While it's not as
>> necessary using the file driver, it would allow multiple dumps to
>> occur in parallel, which can shorten your backup window (using a
>> different disk is recommended to lessen I/O contention)
> 
> I am using hdb1 for my backup's (mounted FAT32 disk)

I think this is your problem, I don't think FAT32 can't handle files
greater than 4 GB (twice what you are erroring out at, but much smaller
than your configured 'tape' size), but I think smbmount may have a 2 GB
limit.

Can you create a bigger file using dd ?
dd if=/dev/zero of=/mounted/fat32disk/testfile bs=1024 count=5000000

should create a 5 GB file in the path you specify with the of=, if it
bombs at 2 GB then look into how it is mounted (could be samba or kernel
problem).  If you need files bigger than 4 GB on windows it needs to
be NTFS and not fat32.

> I am using hda2 as holding disk, this is my config in amanda.conf:
> 
> ***
> holdingdisk hda2 {
>     comment "main holding disk"
>     directory "/usr/local/etc/amanda/holdingdisk"       # where the holding 
> disk is
>     use -10 Mb          # how much space can we use on it
>                         # a non-positive value means:
>                         #        use all space but that value
>     chunksize 10Gb      # size of chunk if you want big dump to be
>                         # dumped on multiple files on holding disks
>                         #  N Kb/Mb/Gb split images in chunks of size N
>                         #             The maximum value should be
>                         #             (MAX_FILE_SIZE - 1Mb)
>                         #  0          same as INT_MAX bytes
>     }
> ***
> 
> But the holdingdisk seems to be empty when Amanda tells me that some files 
> may have been left in the holdingsdisk and that I should run amflush to flush 
> them to tape.

Your backup was going direct to tape (FAIL driver awe /home 20040828 0 [dump to 
tape failed]) so there was nothing in the holding disk to flush.  The 'flush to
tape' message is always output on a failed backup whether there is anythng to
flush or not (it probably should check, but it doesn't).
   Perhaps your reserve parameter is set to not allow level 0s to holdingdisk.

Frank

> 
> \\Reidar
> 
>   
>    
> 
>