> Along this same track - if one uses a Linux based backup and restore > utility, then how does one restore a "base image" in a disaster > situation? D.R. providers generally have a z/OS and z/VM environment. > How many have a Linux environment to do the restores? I would ASSuME > that if I used Linux to dump a filesystem to an FCP connected tape, that > the tape could be read on an FICON or ESCON connected drive (same type, > of course).
You back up from your client systems that actually do the work over an internal network (hipersocket, shared OSA, guest LAN/VSWITCH) to a designated Linux instance that acts only as a backup server, which you can shut down at will without disrupting real services. You then dump the Linux backup server with ADRDSSU or DDR or FDR as an image. On DR restore, you restore the backup server first, then boot a rescue system in the individual virtual machines that gets you on the network, and then you restore the guest from the backup server. If you can afford a periodic outage, you can take down each Linux guest periodically and do a image dump of it. That can form a base image that can be quickly restored, then use the Linux-based backup server to bring it up to date at a file level. > What about tape management on the Linux system? How do you determine > what volumes to send off-site? How do you track volumes (scratch vs. > in-use, on site vs. off site)? Since there is no concept of media management as we understand it in the mainframe world on any Unix or Linux variant, the applications have to do it themselves (and every application does it differently). Amanda and Bacula manage their own tapes, as does TSM. FDR Upstream communicates with a z/OS process and does the tape I/O on z/OS, so the data storage happens along with the z/OS backups. > Is there any way to integrate this with > CA-1 (our tape manager)? See above. It's one of the IMHO best selling points for FDR Upstream, but the trick I suggested with DFSMShsm and NFS works with all the Linux-based backup tools without having SCSI tape drives (or any tape at all on Linux, for that matter). The main reason I added IBM and ANSI SL support to Bacula was to make it behave better in the world of managed media. > I ask because I've recently seen the work that > our tape librarian goes thru managing the "open system" tapes. It is as > bad as back in the OS/360 (MVT) days! Lots of paper work. Yep. Thus the development of the trick, and why it annoys the hell out of me that IBM storage development doesn't provide a way for Linux guests to get better access to channel-attached tape, or that the ISV TMS vendors don't do a better job of providing a mtx extension that can communicate with an existing catalog. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
