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: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Jon LaBadie > > Sent: Thursday, October 16, 2003 9:37 AM > > To: [EMAIL PROTECTED] > > 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 [EMAIL PROTECTED] > > JG Computing > > 4455 Province Line Road (609) 252-0159 > > Princeton, NJ 08540-4322 (609) 683-7220 (fax) > > > > > >