Hi John, I am looking at amanda-2.4.3b3, but aside from docs/VTAPE-API I don't see any mention of how the "virtual tapes" can be set up with AMANDA. And the VTAPE-API looks to me, as a non-coder, like possibly more than I need to know (though if i need to hack some C code I can).
This sounds like it would be much easier for me, as having a "virtual tape" name to ask of ADSM is much easier than trying to figure out which tapes I need on my own, and restoring a dump disk for the purpose. Can you point me to any documentation, crude or otherwise, describing this process? If anyone else has gotten this to work, what does it involve? If I need to change tapeio.c, use special amanda.conf directives, etc etc etc (nothing is mentioned in sample files). I appreciate any assistance. Greg On Wed, 2002-04-03 at 22:39, John R. Jackson wrote: > >First off, for reasons beyond the scope of this email, my AMANDA server > >has no tape device. I am sending all backups to the holding disk. We > >also have a large IBM tape library running ADSM that I would like to > >incorporate into my AMANDA backup strategy. ... > > Sounds like a perfect setup for the tapeio code in 2.4.3 (now in beta > test, but the tapeio stuff has been stable for a long time). You would > set up a disk area to emulate a tape, then use the chg-multi tape changer > to move the data back and forth with your ADSM system. > > The current (2.4.3 beta) chg-multi has a posteject hook to a script you > provide that could move the date into ADSM. It would be easy to add a > preload step to do the other direction (don't know why I didn't think > of doing that when I did posteject). > > >A) I need a way of asking AMANDA, "If I want foo file from 3/20/2000 on > >machine bar, which dump 'directories' will I need?" ... > > The tapeio code would take care of this. Amanda would tell you you > needed "tapes" A, B and C, which would map directly to your ADSM areas. > > If you don't go with tapeio, then I think "amadmin <config> find ..." > is what you'll want. You may also need to be a bit sneaky about the data > motion to ADSM and leave the names and holding disk directories behind, > but truncate the files to zero length, or, worst case, truncate them to > just their 32 KByte header. I'm pretty sure that would fool amrecover > sufficiently into using them (obviously, you'd have to reload the rest > of the data before turning the restore completely loose). > > >Greg Mohney > > John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] -- Greg Mohney Technical Specialist, UNIX Administration APAC Customer Services (319) 896-5027
