Gene,
The saga on TAR was that I've just put in place a (newer) version
of amanda what was compiled to know about gnu tar. This was installed
on the SGI/IRIX that serves /usr/local to (most) of the sgi systems
on sight.
This allowed me to create a new amanda server on a system that had
no backups at all before. That machine has only itself as its single
client and has a .866 Terrabyte (raid array) and a 8-cartridge jukebox
with an SDLT 320.
We don't actually have been to move from dump to tar on the server
that has /usr/local, and for that matter is itself and amanda-server
with several clients (but not the system with the Terrabyte drive
and jukebox).
As an added benifit, I have another client of /usr/local which is
also another amanda-server with several clients. This is the target
of today's email.
That system was, as a pleaseant side-effect, now able to move from
dump to tar for one of its DLEs, now 3 DLEs. While the drive has
multiple partitions I'd created one so large that it would not dump
to the attached DLT 8000. It did for a few months and then the users
filled it enough that even after compression it would not fit on
the DLT.
The current tapetype here is "35000 mbytes" (I didn't know that when
I wrote the earlier email). I don't know why planner overestimated as
much as it did but I'm thinking I was ok in my settings, if anything
I erred on the small side.
The rest is a complete digression...
You are right, more tape would help, larger cartridge, another new
jukebox... something. But its all grantfunded, researcher controlled,
I'm just "supposed to make it go".
We now have 17 amanda servers on sight, we eliminated the last DDS
drive 2 weeks ago. Drives are DLT 4000, 7000, 8000, SDLT 110(?), 360,
DLT 220 and we have just added the 3rd jukebox, 2 Sun Storedge L9
which have the LTO drives and the new one, I know actually know the
vendor name but this info comes back from mtx.
[samar] ~ 2> /usr/local/sbin/mtx -f /dev/scsi/sc1d4l0 inquiry
Product Type: Medium Changer
Vendor ID: 'BDT '
Product ID: 'ThinStor AutoLdr'
Revision: 'T16r'
Attached Changer API: No
Oh, We use amanda on both Solaris (eliminated the last SunOS two
weeks ago) and IRIX.
16 of the 17 amanda-servers we manage, the 17th we are second line
of support for.
I should have just sent this as a new inventory.
thanks,
Brian
> On Friday 26 March 2004 10:18, Brian Cuttler wrote:
> >Hi amanda users,
> >
> >Just to confirm that I'm understanding what I'm seeing.
> >
> >"dumps too big" - the planner decided that there wasn't enough room
> >on the tape for all of the partitions given its estimates so it
> > decided to skip this one partition for the day.
> >
> >"out of tape" means that the planner 'missed', quite possibly
> > because I've given a tape length estimate that was too large, the
> > the dump was left in the amanda work area. This left laksha's root
> > in work area as well as the partition it was trying to put to tape
> > when EOT was hit.
> >
> >FAILURE AND STRANGE DUMP SUMMARY:
> > laksha /usr3/agrawal lev 0 FAILED [dumps too big, 4637885 KB,
> > but cannot incremental dump new disk] laksha /usr3/partha lev 0
> > FAILED [out of tape]
> >
> >Do I have that right ?
> >
> >If so I'll recheck my amanda.conf and make sure I'm not habitually
> >lying to the planner.
> >
> I don't seem to recall what size your tapes were Brian. If they are
> DDS2's, 4Gb native, then that DLE is still too large, and it will
> have to be broken down into the next level of subdirs, each a
> seperate DLE. I'm in that situation here, and I've found that amanda
> seems to handle the balanceing act with much more agility when she
> has numerous small (nearly 50 in fact) DLE's as opposed to maybe only
> 7 or 8 big ones.
>
> However, in your situation as I can see from your sig, I'd sure be on
> a campaign to acquire a larger, with robotics, drive or library if
> I'm guessing correctly that you are stuck with a DDS2 drive now. I'm
> just a home user, so nobody dies, or gets a benefit denied if I lose
> my system, but I'm not sure I'd want to trust your data to a travan
> (multiple yucky's) or DDS (somewhat better) tape. Its true, you
> really do get what you pay for...
>
> >Have to say - tar for user partitions is working out great, haven't
> >been able to backup /usr3 in a year.
> >
> > thanks,
> >
> > Brian
> >
> >---
> > Brian R Cuttler brian.cuttler AT wadsworth DOT org
> > Computer Systems Support (v) 518 486-1697
> > Wadsworth Center (f) 518 473-6384
> > NYS Department of Health Help Desk 518 473-0773
> >
> >
> >
> >
> >----- Forwarded message from Super-User -----
> >
> >These dumps were to tape LAKSHA17.
> >*** A TAPE ERROR OCCURRED: [[writing file: No space left on
> > device]]. Some dumps may have been left in the holding disk.
> >Run amflush to flush them to tape.
> >The next tape Amanda expects to use is: LAKSHA18.
> >
> >FAILURE AND STRANGE DUMP SUMMARY:
> > laksha /usr3/agrawal lev 0 FAILED [dumps too big, 4637885 KB,
> > but cannot incremental dump new disk] laksha /usr3/partha lev 0
> > FAILED [out of tape]
> >
> >
> >STATISTICS:
> > Total Full Daily
> > -------- -------- --------
> >Estimate Time (hrs:min) 0:06
> >Run Time (hrs:min) 9:09
> >Dump Time (hrs:min) 11:56 9:34 2:23
> >Output Size (meg) 50562.8 41349.9 9212.9
> >Original Size (meg) 71549.4 58072.1 13477.3
> >Avg Compressed Size (%) 70.7 71.2 68.4
> > (level:#disks ...) Filesystems Dumped 6 2
> > 4 (1:4) Avg Dump Rate (k/s) 1204.6 1230.4 1100.7
> >
> >Tape Time (hrs:min) 3:18 1:50 1:28
> >Tape Size (meg) 20694.2 11496.2 9198.1
> >Tape Used (%) 59.1 32.8 26.3
> > (level:#disks ...) Filesystems Taped 4 1
> > 3 (1:3) Avg Tp Write Rate (k/s) 1787.1 1791.2 1782.1
> >
> >USAGE BY TAPE:
> > Label Time Size % Nb
> > LAKSHA17 3:18 20694.2 59.1 4
> >
> >
> >NOTES:
> > driver: WARNING: /amanda/work: 92160000 KB requested, but only
> > 87585952 KB available. planner: Adding new disk
> > laksha:/usr3/manjuli.
> > planner: Adding new disk laksha:/usr3/agrawal.
> > planner: Adding new disk laksha:/usr3/partha.
> > taper: tape LAKSHA17 kb 38635360 fm 5 writing file: No space left
> > on device driver: going into degraded mode because of tape error.
> >
> >
> >DUMP SUMMARY:
> > DUMPER STATS
> > TAPER STATS HOSTNAME DISK L ORIG-KB OUT-KB COMP%
> > MMM:SS KB/s MMM:SS KB/s ------------------------
> > --------------------------------------- ------------- andaman
> > /dev/root 1 7206 916 12.7 0:04 222.4 0:02
> > 375.0 laksha /dev/root 1 39884 15203 38.1 0:34
> > 452.0 N/A N/A laksha /usr1 1 98 14
> > 14.3 0:26 0.5 0:02 6.3 laksha /usr2 1 13753599
> > 9417877 68.5 141:47 1107.0 88:01 1783.5 laksha /usr3/agrawal
> > 0 FAILED ---------------------------------------------- laksha
> > /usr3/manjuli 0 17146670 11772105 68.7 192:47 1017.7 109:32
> > 1791.2 laksha /usr3/partha 0 42319152 30570148 72.2 380:45
> > 1338.1 FAILED -----
> >
> >(brought to you by Amanda version 2.4.4p1-20030716)
> >
> >----- End of forwarded message from Super-User -----
>
> --
> 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.22% setiathome rank, not too shabby for a WV hillbilly
> Yahoo.com attornies please note, additions to this message
> by Gene Heskett are:
> Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
|
