On Fri, Dec 03, 2010 at 09:55:14AM -0500, upengan78 wrote:
> Ok guys, I got busier with other tasks so could not reply. sorry about that.
>
> I did manage upgrading to Amanda 3.x version on solaris amanda server and
> solaris amanda client.
>
> I tried amcheck and it worked. So I tried amdump. However it seems to me I
> really need to adjust the numbers because I got below email when I ran the
> dump. May be using multiple DLEs is my only option rather than one here.
>
Congratulations on a successful amdump!
> Here is the Amanda email I got. I don't understand what it is trying to tell
> me to do.
>
>
> These dumps were to tapes TEST-1, TEST-2.
> The next 6 tapes Amanda expects to use are: 6 new tapes.
> The next 6 new tapes already labelled are: TEST-3, TEST-4, TEST-5, TEST-6,
> TEST-7, TEST-8
OK, you allow amanda to use up to six tapes, but it only needed two.
> STRANGE DUMP SUMMARY:
> TEST.domain.com /bk/location lev 0 STRANGE (see below)
Lots of "strange" messages are quite normal, particularly when
dumping an active/live file system.
>
> STATISTICS:
> Total Full Incr.
> -------- -------- --------
> Estimate Time (hrs:min) 0:29
> Run Time (hrs:min) 2:07
> Dump Time (hrs:min) 1:38 1:38 0:00
> Output Size (meg) 16131.3 16131.3 0.0
> Original Size (meg) 31043.7 31043.7 0.0
> Avg Compressed Size (%) 52.0 52.0 --
fairly compressible data.
> Filesystems Dumped 1 1 0
> Avg Dump Rate (k/s) 2795.5 2795.5 --
>
> Tape Time (hrs:min) 1:38 1:38 0:00
> Tape Size (meg) 16131.3 16131.3 0.0
> Tape Used (%) 157.5 157.5 0.0
> Filesystems Taped 1 1 0
> Parts Taped 33 33 0
Hmm, a 16.1GB dump written in "taped" in 33 parts. Sounds
like your splits are about 0.5GB. I wouldn't leave it that
low unless you are really concerned with maximizing each
vtape's filling.
> Avg Tp Write Rate (k/s) 2795.9 2795.9 --
>
> USAGE BY TAPE:
> Label Time Size % Nb Nc
> TEST-1 1:12 10485088k 100.0 1 20
> TEST-2 0:27 6556954k 62.5 0 13
>
Hmm, 20 parts successfully taped on the first (TEST-1) vtape.
So you must be sizing them at about 10GB.
> STRANGE DUMP DETAILS:
> /-- TEST.domain.com /bk/location lev 0 STRANGE
> sendbackup: start [TEST.domain.com:/bk/location level 0]
> sendbackup: info BACKUP=/opt/csw/bin/gtar
> sendbackup: info RECOVER_CMD=/opt/csw/bin/gzip -dc |/opt/csw/bin/gtar -xpGf
> - ...
> sendbackup: info COMPRESS_SUFFIX=.gz
> sendbackup: info end
> ? /opt/csw/bin/gtar: ./fall2010/ece429/albert/cpu32/filenames.log: File
> removed before we read it
> ? /opt/csw/bin/gtar: ./fall2010/ece429/albert/cpu32/sue/no_name.out: File
> removed before we read it
> ? /opt/csw/bin/gtar: ./fall2010/ece429/albert/cpu32/sue/no_name.out.BAK:
> File removed before we read it
> ? /opt/csw/bin/gtar: ./fall2010/ece429/albert/cpu32/sue/no_name.sim: File
> removed before we read it
> ? /opt/csw/bin/gtar: ./fall2010/ece429/albert/cpu32/sue/no_name.sp: File
> removed before we read it
> ? /opt/csw/bin/gtar: ./fall2010/ece429/albert/cpu32/sue/no_name.sp.cache:
> File removed before we read it
> ? /opt/csw/bin/gtar: ./fall2010/ece429/albert/cpu32/sue/no_name.st0: File
> removed before we read it
> ? /opt/csw/bin/gtar: ./fall2010/ece429/albert/cpu32/sue/tclIndex: File
> removed before we read it
> | Total bytes written: 32551710720 (31GiB, 5.3MiB/s)
> sendbackup: size 31788780
> sendbackup: end
> \--------
These are "strange", not "failed". I.e., tar noted something but
continued to run. Gtar makes a list of files it will backup up
then copies them. If during the interval between noting a file
to back up and the actual backup, some{one|thing} removes the
file, the above "strange" messages are produced. I'm not
concerned about missing backups of things that were just removed,
they were probably some type of temporary file.
Strange messages are also generaged about files that change while
being backed up (eg. log files) and the backup of these may be
inaccurate. Gtar does not backup network sockets nor (I think)
device files. But it generates unexpected, thus "strange" mesgs.
>
> NOTES:
> planner: Incremental of TEST.domain.com:/bk/location bumped to level 2.
> planner: TEST.domain.com /bk/location 20101202160419 0
> "/opt/csw/libexec/amanda/runtar exited with status 1: see
> /tmp/amanda/client/test/sendsize.20101202160241.debug"
> taper: Will request retry of failed split part.
> taper: tape TEST-1 kb 9961472 fm 20 [OK]
While attempting to put part 21 on the vtape, the end of the
tape was reached. Thus an error. But from the line below,
it successfully was sent to the next vtape.
> taper: tape TEST-2 kb 6556954 fm 13 [OK]
> big estimate: TEST.domain.com /bk/location 0
> est: 20791072k out 16518426k
Until amanda has some history, it makes assumptions about
compressibility of each DLE. Its assumptions during the
planning phase was not accurate.
> DUMP SUMMARY:
> DUMPER STATS TAPER
> STATS
> HOSTNAME DISK L ORIG-kB OUT-kB COMP% MMM:SS KB/s MMM:SS
> KB/s
> -------------------------- ---------------------------------------
> -------------
> TEST.ece.ii /bk/location 0 31788780 16518426 52.0 98:29 2795.5 98:28
> 2795.9
>
> (brought to you by Amanda version 3.1.1)
>
>
> Here is the amanda.conf
>
> dumpcycle 7
> runspercycle 7
> tapecycle 29
> runtapes 6
> dumpuser "amanda"
> tpchanger "chg-disk" # a virtual tape changer
> tapedev "file:/random/amanda/vtapes/test/slots"
> changerfile "/opt/csw/etc/amanda/test/changerfile"
> labelstr "TEST-.*"
> #label_new_tapes "TEST-%%"
> autolabel "TEST-%%"
> tapetype DVD_SIZED_DISK
> logdir "/opt/csw/etc/amanda/test"
> infofile "/opt/csw/etc/amanda/test/curinfo"
> indexdir "/opt/csw/etc/amanda/test/index"
> tapelist "/opt/csw/etc/amanda/test/tapelist"
> #etimeout 600 # number of seconds per filesystem for estimates.
> etimeout 3600 # number of seconds per filesystem for estimates.
> #etimeout -600 # total number of seconds for estimates.
> # a positive number will be multiplied by the number of filesystems on
> # each host; a negative number will be taken as an absolute total time-out.
> # The default is 5 minutes per filesystem.
> #dtimeout 1800 # number of idle seconds before a dump is aborted.
> dtimeout 3600 # number of idle seconds before a dump is aborted.
> ctimeout 30 # maximum number of seconds that amcheck waits
> # for each client host
>
>
> holdingdisk hd1 {
> directory "/anotherdisk/amanda/amandahold/test"
> }
>
> define dumptype comp-tar {
> program "GNUTAR"
> compress fast
> index yes
> record yes # Important! avoid interfering with production runs
> tape_splitsize 1 Gb
> fallback_splitsize 512 MB
> }
Apparently you have not specified a "splitdisk_buffer". This is a
disk location were parts to be taped are assembled from the chunks
saved on the holding disk. Thus amanda used the fallback size to
assemble parts in memory.
I define the splitdisk_buffer to be a directory on the holding
disk. Things are not left there and only one part (or a couple
at most) would ever be there.
>
> define tapetype DVD_SIZED_DISK {
> filemark 1 KB
> length 10240 MB
> }
>
> Total Virtual tapes are 29.
>
> df -kh /random/amanda/vtapes/
> 16G USED , 280G available
>
> I may not even be correct on fallback_splitsize and tape_splitsize and I may
> not even have to use runtapes in amanda 3.1? Please advise.
>
> Thank you !
>
> +----------------------------------------------------------------------
> |This was sent by upendra.gan...@gmail.com via Backup Central.
> |Forward SPAM to ab...@backupcentral.com.
> +----------------------------------------------------------------------
>
>
>
>>> End of included message <<<
--
Jon H. LaBadie j...@jgcomp.com
JG Computing
12027 Creekbend Drive (703) 787-0884
Reston, VA 20194 (703) 787-0922 (fax)
