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:
> >> On Monday 31 October 2005 07:13, Jeff Allison wrote:
> >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.
> ISTR from a previous post of yours, your holding disk is smaller than
> that, 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.
> 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
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
\--------
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]
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:491014.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 -ome/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:392008.3 45:41 995.9
(brought to you by Amanda version 2.4.5)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jeff Allison
jeff.allison AT allygray.2y DOT net
ICQ 8142658
Messenger jeff_allison AT tokata.com DOT au
Yahoo Jeff Allison
Mobile +44 410 502 702
|
