--On Tuesday, September 24, 2002 17:43:47 -0700 Alan Horn <[EMAIL PROTECTED]> wrote:
> > > If one has a robot library with multiple drives, it's my understanding > that amanda has to have a separate configuration for each of those > drives. In other words, you can't run a backup and use all drives against > one disklist. > > Correct me if I'm wrong there, if I _am_ wrong it'll make my life so much > easier :) I think the beta version will let you configure your drives as a RAIT (like a disk RAID but using tape drives), which should vastly increase your write speeds at the expense of quite a bit of complexity (like loading 6 tapes at a time to do a restore). > Now, how do people handle contention for use of the robot ? > > If I have 6 drives, and therefore 6 configs (call them tape1 thru tape6 > for simplicity), and a 238 slot jukebox with a robot changer. I divide up > the slots, 39 per drive (approx), and then have each chunk of 39 slots be > a separate stack as it were. > > However, as I've seen, when labelling (and I'm sure less commonly, but the > condition will also exist when taping). Two amanda processes can reach for > the robot at the same time,since in this configuration they have no > knowledge of other processes. > > This results in errors like : > > amlabel: could not load slot "current": open SCSI device '/dev/changer' - > Device busy > etc... > > Is this something that needs to be dealt with by the underlying mtx > changer code, or have I miconfigured amanda and it can be done more > effiiciently ? > > So far, I love amanda, it's very promising. But until I solve this changer > problem, I can't really deploy it. Amanda seems to be really lacking (to me) in its capabilities for simultaneous configs, both in its client-server communications and its handling of multiple drives and changers. You could put a wrapper around the changer script that would use a lock file to control accesses to the changer, where the wrapper would just sleep if the lock existed and retry a little later. Or it may be easier to build it into the existing changer scripts. Hopefully there are no internal timeouts in Amanda on the changer calls. Maybe I'm wrong too. I had troubles setting up a second config for offsites and finally just settled for staggering the runs so that the runs don't overlap. As the backup requirements grow, this will become more and more difficult to achieve. Perhaps this feature (concurrent runs) is in the new betas. Frank > > Cheers, > > Al > > > -- > Alan C. Horn > Inktomi - Unix Architect. > +1-650-653-5436 > [[EMAIL PROTECTED]] -- Frank Smith [EMAIL PROTECTED] Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
