On Wednesday 22 January 2003 08:31, Simon Young wrote: >On Thu, Jan 16, 2003 at 01:13:14AM -0500, Jon LaBadie wrote: >> On Fri, Jan 10, 2003 at 11:14:55AM +0000, Pavel Rabel wrote: >> > > > >Can amanda send a signal to my DLT IV to unload the tape >> > > > > after backups are finished, so whoever goes back to swap >> > > > > tapes can just do it without waiting to manually unload? >> > > >> > > For amdump this is easy. > >Is it really easy when using a tape changer?
Once configured, yes. >If you follow amdump with an amtape eject command, will you not be >ejecting the tape in the 'current' slot? Thats how it would work here at any rate. Amanda does not change her notion of "slot" until the next invocation of amdump or amcheck, both of which apparently start out by searching for the next reusable tape. Here, as a side comment, in order to have available on the days tape, a copy of todays indices and configuration, I have reduced the tapetype size by 100 megs, and after amdump is done and all its locks on those files removed, I am tarring up those two dirs and appending them to the tape immediately after amdump. This I'm doing because when amdump is running with indexing on, there are locks on those files and they will not be included in the regular file for that disklist entry. These indice and config backups are being kept in a seperate directory off of '/' which I have added to the disklist, and a script takes care of removing the oldest, incrementing the rest to make room for a new un-numbered one for every run. As that directory only compresses to about 70% of original size, there will be about 1.1 gigs to save every nite. Thinking out loud, if I was to just march thru that dir using the tapes number, that would reduce the size of that 'incremental' to just the 3 new files from the last run. I'll do that when I get to the loopback point in my cassette storage rack. My script gets ever more complex it seems. >Once amdump has finished, isn't the current slot incremented? Not here. This is all done at the start of the next run, which is why you run amcheck sometime earlier and have it email you if the right tape is not in the magazine. Once amdump can't find the right tape, the whole run goes into the holding disk, and it does that run no good to reload the magazine once amdump has looked at, and not found the tape it needs. > Implying that you'll be ejecting the tape in the next slot, which > is most likely the one amanda will be wanting to use next. I'd assume in those robots where it has an internal storage of 12 or more tapes, that an eject would mean it will bring that tape to the door for you to remove, in which case you would need to tell it which tape slot to give you the contents of. This would not be the same as ejecting a tape from a drive, which in larger libraries, there may be 2 or more of. I keep refering to 'magazine' because thats the 'style' mine is built as, which of course will not apply to all cases. >I'm not quite clear about this yet, so please correct me if I'm > wrong. > >And what if amanda uses more than one tape in a single run? Is > there a nice way to have it eject only the tapes it used? That would only be effective in the event you had a library robot capable of laying the tape(s) on an output "used" shelf or some such. There may be one or more that can do that, but normally the eject (rewoffl to mt) with either put that tape back into its slot in the magazine, or will (dip switches may control this behaviour, and they do on my mechanism so I shut that switch off) actually cause the robot to eject and store this tape back in its magazine slot, and load the next one if it is not at the end of the magazine. Not trying to confuse, my apologies if it does. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.22% setiathome rank, not too shabby for a WV hillbilly
