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)
>
>
|
