Dana,
I have a jukebox on a Solaris 9 system and I've configured runtapes
to 2 because I expect to shortly exceed the capacity of a single
tape (LTO [110/220 ??]) shortly.
So far all runs have completed on a single tape, ie the second tape
is only called into play when the first is 'filled'.
On the other hand - I rotate these tapes out incase there is every
a problem in the computer room itself, I don't leave the tapes in
the jukebox.
Sorry, not yet using TAR though I should be testing that config out.
I have a .866 Tbyte drive I need to start backing up...
Dana Bourgeois writes:
> To follow up on this a little further..could you address 'runtapes'? If I
> set 'runtapes' to two or larger, then as long as every client dump is
> smaller than one tape, amanda will pack it all on (if I don't have
> tape/drive problems and don't hit the 'runtapes' limit first), is that true?
> I assume that if an amdump fits on one tape, a weekly cycle would use only
> the 7 tapes and be happy. No weird 'I need two tapes per amdump' side
> effects. The docs aren't real clear and I know this has been kicked around
> on the list but it would be nice to participate in a discussion. My
> apologies to the old hands who have gone through this before.
>
> Is there anyone who is using GNUTAR exclusively for its reported advantages
> in a heterogeneous environment? Is there anyone who has broken up large
> (100G) partitions with GNUTAR to fit on smaller (20G) tapes? How well does
> that work and how much extra tracking do you have to do? Does amanda track
> it all well enough?
>
> Last question. I just installed 2.4.4 (at home) and set up some disk
> 'tapes' on a 100G drive installed for that purpose. It rocks. Really nice
> and easy to setup. I don't have a tape drive so for now, it's all on disk.
> At some point, I will add a tape unit. I'm now wondering if there are
> advantages to bringing the tape unit into amanda or just writing the disk
> 'tape' files to tape directly with dd. It would mean a restore from tape
> would be two stage since I'd have to copy it back to disk (my changer) and
> run inventory to show it's in a slot. I would think that this would, on
> average, be slightly faster than having amanda directly address the tape
> drive plus I can hardware mirror the disk and potentially write large amanda
> disk 'tapes' to multiple real ones instead of buying a large-enough capacity
> tape drive. Has anyone come up with a nifty way to use this new disk 'tape'
> capability that they would like to share?
>
> A story on why I ask: a client has an 8 slot Sony autoloader. 8 tapes at
> 40G each is a max of 320G. They don't currently do even half that each
> week. However, they also archive by running a separate amdump on the
> weekends. Plus the autoloader tape handling is slow as molasses. They're
> talking about getting another one for about $2K which is a bargain compared
> to a real jukebox at 3 to 5 times that price. I, however, am thinking of
> how much mirrored disk I could buy for that, how many tape slots that much
> disk would represent in a really *fast* virtual jukebox and the time/hassle
> it would take to dump the disk file 'tape' image from disk. I would then
> have to delete the oldest disk 'tape' from the jukebox, inventory and
> relabel but I figure I could have at least 1000G of mirrored disk online for
> that $2K. The downside is the hassle of handling tape sets if you break up
> an amanda disk 'tape' into multiple real tapes. Is it worth the hassle?
> Maybe with a good UPS, you don't even go with a tape drive except for when
> you're sending something off-site? At what technology point does a tape
> drive equal a disk drive in I/O assuming dedicated 133 MHz 7200 RPM ATA
> channels? I don't think AIT2 or DLT8000 are as fast but AIT3, SDLT and LTO?
>
>
> Dana Bourgeois
>
>
> > -----Original Message-----
> > From: owner-amanda-users AT amanda DOT org
> > [mailto:owner-amanda-users AT amanda DOT org] On Behalf Of Jon LaBadie
> > Sent: Thursday, October 16, 2003 9:37 AM
> > To: amanda-users AT amanda DOT org
> > Subject: Re: terminology help
> >
> >
> > On Thu, Oct 16, 2003 at 04:25:48PM +0100, Tom Brown wrote:
> > > > > tapecycle 20 tapes:
> > > > > number of tapes to use per dumpcycle of 2 weeks. 10 tapes X 2
> > > > > dumpcycles
> > > =
> > > > > 20 tapes.
> > > >
> > > > Yes, but you really should have an extra tape or two in there to
> > > > lessen the chance of a failed backup overwriting your last full
> > > > backup. You should really consider doubling that number so you
> > > > always have two copies in case one should error on a restore (in
> > > > which case you would lose your newest data but you could at least
> > > > still recover older files.).
> > >
> > > really? in my case i allways have tapecycle as
> > dumpcycle*runspercycle
> > >
> > > is that bad?
> > >
> > > e.g ...
> > >
> > > dumpcycle 1 weeks # the number of days in the normal
> > dump cycle
> > > runspercycle 5 # the number of amdump runs in
> > dumpcycle days
> > > # (4 weeks * 5 amdump runs per week -- just
> > > weekdays)
> > > tapecycle 5 tapes # the number of tapes in rotation
> > >
> > > or another config....
> > >
> > > dumpcycle 2 weeks # the number of days in the normal
> > dump cycle
> > > runspercycle 10 # the number of amdump runs in
> > dumpcycle days
> > > # (4 weeks * 5 amdump runs per week -- just
> > > weekdays)
> > > tapecycle 10 tapes # the number of tapes in rotation
> >
> > Tom,
> > you don't have it as dumpcycle*runspercycle.
> > In your two examples you have it as "runspercycle" period.
> >
> > To demostrate the problem consider the simplest situation.
> > A dumpcycle of 1 day, a runspercycle of 1, and a tapecycle of 1.
> >
> > Each amdump uses the ONLY tape containing the last level 0's.
> > Each amdump overwrites, and destroys your only level 0's.
> >
> > Thus, if anything happens to that tape, and particularly if
> > anything happens during the amdump run, you have trashed the
> > only tape containing your level 0.
> >
> > The same thing can happen whenever tapecycle == runspercycle.
> > The tape being used by the current amdump "could" contain the
> > one and only level 0 of a DLE. If something happens to it,
> > you have nothing left to restore/recover from.
> >
> > --
> > Jon H. LaBadie jon AT jgcomp DOT com
> > JG Computing
> > 4455 Province Line Road (609) 252-0159
> > Princeton, NJ 08540-4322 (609) 683-7220 (fax)
> >
> >
>
>
|
