On Tuesday 01 November 2005 04:10, Jeff_Allison AT blackshaw.dyn.dhs DOT org
wrote:
>owner-amanda-users AT amanda DOT org wrote on 01/11/2005 02:13:48 PM:
>> On Monday 31 October 2005 15:45, Jeff Allison wrote:
>> >On Mon, 2005-10-31 at 09:18 -0400, Gene Heskett wrote:
And I've added the list back to the Cc: line.
>> >
>> >The biggest DLE is /home/samba which is 11GB uncompressed.
>> >
>> >its got a user-tar dump-type would that kill it
>>
>> By kill it, please define 'kill'.
>
>Gene by kill it I mean stop it working.
I see, and thats whats happening.
>> ISTR from a previous post of yours, your holding disk is smaller than
>> that,
Is this not true?
>> which forces amanda to do a direct to tape write. If that write
>> then fails because of EOT, then the file is lost till the next run
>> tries it again.
>>
>> You need a holding disk thats about 150% (or more) of the total
>> backups size so that if a failure occurs, it can continue to use the
>> holding disk subject to the 'reserved' value in your amanda.conf. I
>> reserve enough that a full backup could be stored in it. Here, I have
>> 25Gb of spare on /, with seperate partitions for almost everything
>> else, so that space is not being used up at a very high rate. With
>> drives at about $0.50 Gb these days, enough storage is as close as
>> Circuit City or whomever has the market in your area.
>>
>> Once the failure is handled, then an amflush can continue the backup
>> write phase, starting at the head of the file it failed on IF it still
>> exists in the holding disk.
>
>This is different from my understanding of the way amanda dealt with
> EOT. I believed that when an EOT was encounterd than amanda retried to
> write on to the next tape, this is what appeared to be happening with
> the previous runs prior to the upgrade.
It will, provided the holding disk is large enough to hold the file, if
not the file is lost. And I'm not sure what error message amanda
outputs in that case, as its not a condition I've encountered here so
far. Can someone fill in this missing data please?
>> I'd assume that the /home/samba DLE is being software compressed? If
>> both software and hardware are in use, the result will usually be a
>> bigger file by several percentage points, and will possibly overflow
>> even an empty tape.
>>
>> The DDS family of tape drives, and I think many other formats, store
>> the state of the compression in a hidden header on the tape, and
>> generally speaking, if a tape has ever been written to with the
>> hardware compression enabled, its gonna be that way forever, or until
>> you use mt to turn it off while the tape is at BOT, and then force a
>> large enough write to cause the drive to flush its buffer, at which
>> point the tape will become uncompressed.
>>
>> Hardware compression off is the ideal because with it on, amanda has
>> no real clue how much tape has been used as amanda counts bytes sent
>> down the cable to the drive. And this is after any software
>> compression has been done. I have some directory trees that will
>> compress to about 15% of their original size, and others that contain
>> archives that waste gzips time trying to get another 5% squeezed out
>> of them. Adjust the dumptype used for those trees accordingly.
>
>I understand the issue about hardware versus software compression these
>tapes as far as I know have never been used with hardware complression
> and have allready been used in one cycle...
>
>> I'm rambling, something I'm good at at my age (71) but I hope there is
>> something usefull here too.
>
>I have no problem with rambling I'm good at it myself.
>
>Looking at the log and report I'm currently suspecting the change-manual
>script as it seems to request the tape and write 0k to it then exit with
>connection reset error.
>
>attached is the mail report from last nights backup
>
>I may try to reinstall 2.4.2 and see If that fixes it.
>
>These dumps were to tapes homes_06, homes_07.
>The next 3 tapes Amanda expects to used are: homes_08, homes_09,
> homes_10.
>
>FAILURE AND STRANGE DUMP SUMMARY:
> dalston / lev 1 STRANGE
> dalston //bw/backup lev 1 STRANGE
> dalston /home/samba lev 0 FAILED ["data write: Connection reset by
>peer"]
> dalston /home/samba lev 0 FAILED [dump to tape failed]
>
>
>STATISTICS:
> Total Full Incr.
> -------- -------- --------
>Estimate Time (hrs:min) 0:21
>Run Time (hrs:min) 15:27
WOW! Whats eating the cpu? Or is it short on horsepower to do the
compression?
>Dump Time (hrs:min) 1:28 0:00 1:28
>Output Size (meg) 3292.5 0.0 3292.5
>Original Size (meg) 3989.5 0.0 3989.5
>Avg Compressed Size (%) 82.1 -- 82.1 (level:#disks
> ...) Filesystems Dumped 12 0 12 (1:11 5:1)
> Avg Dump Rate (k/s) 640.2 -- 640.2
>
>Tape Time (hrs:min) 0:57 0:00 0:57
>Tape Size (meg) 3292.6 0.0 3292.6
>Tape Used (%) 28.2 0.0 28.2 (level:#disks
> ...) Filesystems Taped 12 0 12 (1:11 5:1)
> Avg Tp Write Rate (k/s) 982.1 -- 982.1
>
>USAGE BY TAPE:
> Label Time Size % Nb
> homes_06 0:57 3293M 28.2 12
> homes_07 0:00 0M 0.0 0
>
>
>FAILED AND STRANGE DUMP DETAILS:
>
>/-- dalston / lev 1 STRANGE
>sendbackup: start [dalston:/ level 1]
>sendbackup: info BACKUP=/usr/local/bin/amtar
>sendbackup: info RECOVER_CMD=/usr/local/bin/amtar -f... -
>sendbackup: info end
>? gtar: ./var/log/samba/log.smbd: file changed as we read it
>
>| Total bytes written: 107335680 (102MB, 191kB/s)
>
>sendbackup: size 104820
>sendbackup: end
>\--------
>
>/-- dalston //bw/backup lev 1 STRANGE
>sendbackup: start [dalston://bw/backup level 1]
>sendbackup: info BACKUP=/usr/bin/smbclient
>sendbackup: info RECOVER_CMD=/usr/bin/smbclient -f... -
>sendbackup: info end
>? INFO: Debug class all level = 3 (pid 1974 from pid 1974)
>? NT_STATUS_SHARING_VIOLATION opening remote file \NTUSER.DAT (\)
>? NT_STATUS_SHARING_VIOLATION opening remote file \Application
>Data\Skype\allygray\profile16384.dbb (\Application Data\Skype\allygray\)
>
>| tar: dumped 5367 files and directories
>| Total bytes written: 1207558144
>
>sendbackup: size 1179256
>sendbackup: end
>\--------
>
>/-- dalston /home/samba lev 0 FAILED ["data write: Connection reset
> by peer"]
>sendbackup: start [dalston:/home/samba level 0]
>sendbackup: info BACKUP=/usr/local/bin/amtar
>sendbackup: info RECOVER_CMD=/bin/gzip -dc |/usr/local/bin/amtar -f... -
>sendbackup: info COMPRESS_SUFFIX=.gz
>sendbackup: info end
>\--------
Thats not an EOT error. It looks as if something in samba has become
more paranoid about accessing the data. I do not use samba here for
access as I run a client on each machine and samba therefore isn't in
the picture. By useing the client, I bypass all that windows
filesystems lack of proper ctimes & permissions fooforall that makes for
level 4's that look like level 0's.
>
>
>NOTES:
> planner: Last full dump of dalston:/home/samba on tape overwritten in
> 1 run.
> taper: tape homes_06 kb 11350144 fm 13 writing file: No space left on
>device
> taper: retrying dalston:/home/samba.0 on new tape: [writing file: No
>space left on device]
> taper: tape homes_07 kb 0 fm 0 [OK]
This is certainly beginning to look as if there is a bug if there is no
space left on a new tape (homes_07) but the next line says no filemarks
were written, eg the tape is empty. But it could also be because the
holding disk wasn't used as it wasn't big enough for the file, which
must be completely in the holding disk before amanda will write it. If
the holding disk isn't big enough, then there is no file to write when
the new tape is loaded.
>
>DUMP SUMMARY:
> DUMPER STATS TAPER STATS
>HOSTNAME DISK L ORIG-MB OUT-MB COMP% MMM:SS KB/s MMM:SS
> KB/s
-------------------------------------------------------------------
>dalston / 1 102 102 -- 9:10 190.6 2:06 831.0
>dalston //bw/backup 1 1152 524 45.5 55:06 162.4 8:49 1014.4
>dalston -betterware 1 0 0 10.0 0:00 0.0 0:01 0.8
>dalston /home/bw 1 0 0 10.0 0:01 0.0 0:01 0.7
>dalston /home/chris 1 0 0 6.7 0:04 0.8 0:02 2.4
>dalston /home/debs 1 0 0 14.6 0:14 4.0 0:06 9.3
>dalston /home/jeff 1 1 0 10.0 0:26 2.2 0:01 85.5
>dalston /home/jim 1 0 0 6.7 0:02 1.4 0:01 3.1
>dalston /home/mark 1 0 0 13.3 0:02 1.6 0:22 0.2
>dalston /home/samba 0 FAILED-----------------------------
>dalston /home/stuart 1 0 0 10.0 0:01 0.0 0:01 0.8
>dalston /home/tony 1 0 0 10.0 0:01 0.0 0:01 0.8
>leyton /home/jeff 5 2734 2666 97.5 22:39 2008.3 45:41 995.9
>
>(brought to you by Amanda version 2.4.5)
--
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)
99.35% setiathome rank, not too shabby for a WV hillbilly
Free OpenDocument reader/writer/converter download:
http://www.openoffice.org
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
|
