A run is one amdump. Amanda used to be limited to one *tape* per run. You
can now use more than one *tape* per amdump. However, You still have to be
able to fit each entry in the disklist one *one* tape. Any entry in the
disklist file which estimates out larger than your tapesize will not get
scheduled. Any disklist entry which is writing when you hit end of tape
will be rewritten on a new tape and if it doesn't fit on that tape you get
an error of some kind. I really don't know if the whole amdump abends or if
it just skips that disklist entry and continues.
The bottom line, you have the responsibility to make sure each entry in the
disklist will fit on one tape. Unless you want to get heavily involved in
the beta work being done to handle disklist entry splitting across tapes a
la Backup Exec, Netbackup, Networker, etc...
Dana Bourgeois
> -----Original Message-----
> From: owner-amanda-users AT amanda DOT org
> [mailto:owner-amanda-users AT amanda DOT org] On Behalf Of Danny Ybarra
> Sent: Sunday, November 16, 2003 9:50 PM
> To: gene.heskett AT verizon DOT net; amanda-users AT amanda DOT org
> Subject: Re: Spanning multiple tapes
>
>
> I found this statement in the WHATS.NEW file. Can you
> explain what it means? Sorry for being such a newbie
> but I really want to start using Amanda.
>
> * MULTIPLE TAPES IN ONE RUN
>
> I've rewritten the taper - it now supports one run
> spanning multiple tapes if you have a tape-changer.
> The necessary changes in support of this have also
> been made to driver and reporter - planner already had
> support. There are a couple other places that should
> probably be updated, like amcheck. Dumps are not
> split across tapes - when taper runs into the end of a
> tape,
> it loads the next tape and tells driver to try sending
> the dump again.
>
> If you are feeling brave, set "runtapes" to something
> other than 1.
>
> The new taper also keeps the tape open the entire time
> it is writing the files out - no more having amchecks
> or other accesses/rewinds in the middle of the run
> screw you royally if they hit when the tape is closed
> for writing a filemark.
>
>
> --- Gene Heskett <gene.heskett AT verizon DOT net> wrote:
> > On Sunday 16 November 2003 22:21, Danny Ybarra
> > wrote:
> > >Ok I'm confused then. If you have a list of
> > entries
> > >in your list how do you tell amanda what entries go
> > on
> > >what tape if you have a autoloader?
> >
> > You don't, thats all up to the 'planner'. You can
> > hint as to how its
> > supposed to order things a wee bit by use of the
> > 'dumporder'
> > directive in your amanda.conf.
> >
> > >Also will it just prompt you to put another tape in
> > if you
> > >are using a single HP DAT drive?
> >
> > Possibly one of the changer scripts, like
> > chg-manual, might do this.
> > Here I use chg-scsi, and its totally silent at the
> > console, sending
> > you an email if something goes toes up. As amanda
> > is designed to be
> > run in the middle of the night by cron, it really
> > doesn't expect
> > there to be a human 'lifeguard' around in case
> > something gets a tummy
> > ache. So it handles the errors it knows howto
> > handle, or sends you
> > an email so you can handle it the next day and then
> > goes silently
> > away.
> >
> > >--- Gene Heskett <gene.heskett AT verizon DOT net> wrote:
> > >> On Sunday 16 November 2003 01:18, Danny Ybarra
> > >>
> > >> wrote:
> > >> >I'm new to amanda but I read that amanda now
> > spans
> > >> >multiple tapes. How do you set that up on a
> > Dell
> > >>
> > >> 132T
> > >>
> > >> >LTO Autoloader? I also want to use that feature
> > on
> > >>
> > >> a
> > >>
> > >> >regular single HP DAT drive.
> > >>
> > >> Amanda can use more than one tape, however it
> > cannot
> > >> span a single
> > >> disklist entry to two or more tapes. Each
> > disklist
> > >> entry must be
> > >> smaller than 1 tape.
> > >>
> > >> I'm watching amanda use 2 tapes here, and just
> > saw
> > >> it switch to the
> > >> next tape. Unforch, the file it failed on was
> > over
> > >> half a tape, so
> > >> it wasted about 1.5 gigs in changing the tapes.
> > >> Looks like I'll need
> > >> to re-arrange that entry into 2 or 3 to make it
> > into
> > >> smaller pieces.
> > >> I'm seeing, in the status reports, that amanda
> > seems
> > >> to be ignoreing
> > >> my dumporder "STSTSTST", as its often been seen
> > to
> > >> do a 70 meg DLE, a
> > >> 600Mb DLE, then a 2.1Gb DLE and a 1.1Gb DLE, in
> > that
> > >> order while
> > >> filling up a teeny 4Gb tape which wound up with:
> > >>
> > >> dumped : 12 7721415k 7503717k
> > >> (102.90%) ( 22.21%)
> > >> wait for writing: 8 3018755k 2801057k
> > >> (107.77%) ( 8.68%)
> > >> wait to flush : 0 0k 0k
> > >> (100.00%) ( 0.00%)
> > >> writing to tape : 1 2296810k 2296810k
> > >> (100.00%) ( 6.61%)
> > >> failed to tape : 0 0k 0k (
> > >> 0.00%) ( 0.00%)
> > >> taped : 3 2405850k 2405850k
> > >> (100.00%) ( 6.92%)
> > >> tape 1 : 3 2405850k 2405850k
> > >> DailySet1-28
> > >> tape 2 : 0 0k 0k
> > >> DailySet1-01
> > >>
> > >> which says I'll have to run a flush in the
> > morning
> > >> as its going to EOT
> > >> the second tape with quite a bit left in /dumps.
> > >> 3018755k+2296810k
> > >> will be about a 1.6Gb overflow, and my indice
> > saver
> > >> will fail with
> > >> EOT.
> > >>
> > >> Suggested change to planner algorythm: When
> > >> runtapes is >1, juggle
> > >> the order to achieve a best fit within the
> > tapetypes
> > >> capacity as
> > >> entered in amanda.conf, overriding the
> > 'dumporder'
> > >> specified, setting
> > >> up a seperate list for each allowed tape.
> > >>
> > >> And even greater modifcation would be to write
> > that
> > >> amount of data,
> > >> then change tapes even without hitting EOT,
> > thereby
> > >> saving the time
> > >> and wear on the drive it wastes in writing till
> > EOT
> > >> is encountered
> > >> before doing the tape change. In this case it
> > would
> > >> have saved about
> > >> an 1 hr & 9 mins, or used that time to put about
> > >> another gigabyte of
> > >> smaller DLE's on the first tape used tonight.
> > >>
> > >> Just my $0.02. That, and another buck, might get
> > >> you a cuppa most
> > >> places :-)
> > >>
> > >> --
> > >> Cheers, Gene
> > >> AMD K6-III@500mhz 320M
> > >> Athlon1600XP@1400mhz 512M
> > >> 99.27% setiathome rank, not too shabby for a WV
> > >> hillbilly
> > >> Yahoo.com attornies please note, additions to
> > this
> > >> message
> > >> by Gene Heskett are:
> > >> Copyright 2003 by Maurice Eugene Heskett, all
> > rights
> > >> reserved.
> > >
> > >__________________________________
> > >Do you Yahoo!?
> > >Protect your identity with Yahoo! Mail AddressGuard
> > >http://antispam.yahoo.com/whatsnewfree
> >
> > --
> > Cheers, Gene
> > AMD K6-III@500mhz 320M
> > Athlon1600XP@1400mhz 512M
> > 99.27% setiathome rank, not too shabby for a WV
> > hillbilly
> > Yahoo.com attornies please note, additions to this
> > message
> > by Gene Heskett are:
> > Copyright 2003 by Maurice Eugene Heskett, all rights
> > reserved.
> >
>
>
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
>
>
|
