Re: tape backups
> We are considering (and we should) backup our linux guests on z/VM. Any > suggestion? > Perhaps Tivoli TSM... Works, but is expensive. Also requires SCSI/FCP tape drives. > Or Amanda with NFS server on z/OS and SMS doing the backup is interesting. Use Bacula instead of Amanda. Better features, and the same technique with SMS works fine. Also has multi-level migration and better reporting. -- 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
Re: tape backups
On Monday, 08/06/2007 at 08:38 EDT, David Boyes <[EMAIL PROTECTED]> wrote: > > We are considering (and we should) backup our linux guests on z/VM. > Any > > suggestion? > > Perhaps Tivoli TSM... > > Works, but is expensive. Also requires SCSI/FCP tape drives. Assuming the TSM server is on Linux or on another distributed system. If it's on z/OS, channel-attached drives work just fine. Caveat emptor: Just because you have z/OS in-house, don't *assume* your z/OS folks are willing to pick up that kind of workload. An analysis of the increased CPU requirements would have to be performed and weighed against the costs of integration into your SCSI/FCP tape ecosystem (that does assume you have one to integrate into!). Alan Altmark z/VM Development IBM Endicott -- 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
Re: tape backups
> > > Perhaps Tivoli TSM... > > Works, but is expensive. Also requires SCSI/FCP tape drives. > Assuming the TSM server is on Linux or on another distributed system. If > it's on z/OS, channel-attached drives work just fine. Given the proportionally larger cost of the resources required, it seems unlikely that the cost case is viable for running TSM on z/OS compared to Linux. TSM can easily consume a complete physical CPU all by itself (and want more), and standard engine CPUs don't come cheaply, especially given the spike in z/OS-based licensing you'll enjoy by enabling that additional processor(s). It'd be interesting to think about whether the TSM database back end could be offloaded to z/OS. That might be an idea that would combine some interesting value to the z/OS and Linux combination. Another option might be a remote tape server on z/OS that had a Linux device driver, analogous to the capability on VSE (note: idea mine.). That'd be a generally attractive thing to have as well, especially if it also allowed a VM implementation. > An analysis of > the increased CPU requirements would have to be performed and weighed > against the costs of integration into your SCSI/FCP tape ecosystem (that > does assume you have one to integrate into!). Don't forget that those new drives won't be able to use your existing TMS and operations procedures on z/OS, and won't appear in your standard tape library management reports, so you'll need to invent additional tools to manage them. The people cost of "exceptions" are the killer here. -- 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
Re: tape backups
TSM client to a z/OS TSM server works very well for file-level backups. Our Disaster Recovery backups are still done from outside the Linux server while the Linux server is NOT logged on. We already had TSM server on our OS/390-z/OS system so it was nothing to add our Linux workload. As we add more and more Oracle databases (GBs of database backed up every night), the load on the z/OS TSM will increase but z/OS based TSM is the basis for all file-level recovery in our environment. /Tom Kern /301-903-2211 --Original Message- From: Alan Altmark <[EMAIL PROTECTED]> Subject: Re: tape backups Assuming the TSM server is on Linux or on another distributed system. If it's on z/OS, channel-attached drives work just fine. Caveat emptor: Just because you have z/OS in-house, don't *assume* your z/OS folks are willing to pick up that kind of workload. An analysis of the increased CPU requirements would have to be performed and weighed against the costs of integration into your SCSI/FCP tape ecosystem (that does assume you have one to integrate into!). Alan Altmark z/VM Development IBM Endicott -- 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
Re: tape backups
Our heads agree that TSM it's expensive. We will choose between: 1) Bacula / Amanda writing to z/OS by: FTP or NFS (hypersockets !!!). We'll backup approx 1 TB by month, then could be 250 GB weekly. I need this space in z/OS dasd, would be great writing directly to tape (maybe ftp'ing with a specific HLQ, so SMS allocates it in tape). 2) Connect the "tape ecosystem" to z/VM LPAR. The machine where it runs is already working with tapes. We have IBM VTS B20 on peer to peer (in progress...). I don't understand why Symantec discontinues Veritas Netbackup on z/Linux "Next major release following NetBackup 6.0 will not support this OS version. This status could change if market and/or vendor support positions change" Thanks 2007/8/6, Alan Altmark <[EMAIL PROTECTED]>: > > On Monday, 08/06/2007 at 08:38 EDT, David Boyes <[EMAIL PROTECTED]> > wrote: > > > We are considering (and we should) backup our linux guests on z/VM. > > Any > > > suggestion? > > > Perhaps Tivoli TSM... > > > > Works, but is expensive. Also requires SCSI/FCP tape drives. > > Assuming the TSM server is on Linux or on another distributed system. If > it's on z/OS, channel-attached drives work just fine. > > Caveat emptor: Just because you have z/OS in-house, don't *assume* your > z/OS folks are willing to pick up that kind of workload. An analysis of > the increased CPU requirements would have to be performed and weighed > against the costs of integration into your SCSI/FCP tape ecosystem (that > does assume you have one to integrate into!). > > Alan Altmark > z/VM Development > IBM Endicott > > -- > 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 > -- 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
Re: tape backups
> 1) Bacula / Amanda writing to z/OS by: FTP or NFS (hypersockets !!!). > We'll > backup approx 1 TB by month, then could be 250 GB weekly. I need this > space > in z/OS dasd, would be great writing directly to tape (maybe ftp'ing with > a > specific HLQ, so SMS allocates it in tape). You don't need to keep the entire 250G online at the same time. You need only enough space to hold two or three "tape" images per concurrent backup job, and to use DFSMShsm aggressively to move disk files to tape on the z/OS side. One or two mod 27s is usually sufficient. Some suggestions: 1) Allow Bacula to spool data on the Linux side and migrate to the z/OS NFS storage; it's a more effective use of disk space and processing time (in that more of the processing stays on the IFL side), and you have better tape mount utilization on the z/OS side. Yes, the VTS is robotic and virtual, but there's no sense in making it crazy mounting and dismounting stuff all the time. 1.5) Configure the z/OS NFS server for automatic recall from HSM, and use MVS datasets to store Bacula volumes where possible. HSM works on ZFS- and HFS-controlled filespace storage, but it's a lot harder to understand and track. 2) Create a separate Linux virtual machine for the Bacula server. This limits the exposure of the z/OS system to outside influences. This also minimizes the burden on the non-IFL system with doing the data transfer between individual guests and the backup server. If you're really paranoid, run the Bacula storage daemon managing the z/OS NFS disk pool on a separate virtual machine and do migration over IP using an internal VSWITCH or guest LAN that includes only the Bacula server and the Bacula storage director in question. 3) When you configure the Bacula storage pool for the tape images on disk, select a tape image size that's smaller than your VTS tape size, so that you can fit an entire Bacula volume on one VTS tape. HSM will like you much better if you do. 5G VTS volume sizes are nice, with 2.5G Bacula volumes. Smaller Bacula volumes make for faster recall from HSM, but add overhead in HSM processing to keep track of them. 3.5) Create two separate storage pools in Bacula, one for spooling the data directly from the clients and one for migration to the z/OS disk. This forces the most amount of processing to stay on the IFL side, and involves z/OS in only the transfer of data ready to go to tape. This also lets you leverage FCP disk for the spooling pool if it's available, which z/OS can't yet use. 4) Make sure you allocate enough space on the z/OS side to have at least two Bacula volumes on disk at a time per simultaneous job you want to have running. This allows you to be writing one tape image while HSM is migrating the previous one off to tape without getting in the way of the NFS server. It's also good to allow enough space for at least a third volume on disk so you can have restores going on as well w/o interfering with backups. 2.5G Bacula volume sizes with 2 simultaneous migration jobs going on against a mod 27 on the z/OS side work pretty well. 5) Put the volumes you use for Bacula dumps in a separate HSM policy group and make migration to tape for that policy group as aggressive as you can make it (immediately on close after write if you can). This frees up space for other dumps ASAP, w/o messing with migration policy for the rest of the system accidentally. If you spool to disk on the Linux side and then migrate to z/OS disk using Bacula capabilities (see item 1), then the contention for writing to that disk will be much reduced, and you can be a little less aggressive. 6) Don't try to use FTP. The combination of NFS and DFSMShsm is much more effective, and it's self-automating if you already have HSM active on z/OS (and if not, why not? You're wasting a huge amount of super-expensive disk space). FTP would require you to automate all the storage and transfer processing yourself, which is much harder than it looks. You have an operating system that genuinely understands HSM -- use it. This kind of fiddly recordkeeping is exactly what SMS was intended to be used for, and the computers are infinitely better at it than humans. > I don't understand why Symantec discontinues Veritas Netbackup on z/Linux > "Next major release following NetBackup 6.0 will not support this OS > version. This status could change if market and/or vendor > support positions change" Two key words: market position. Didn't make them enough money to justify the test cost and having to maintain a mainframe or buy time on somebody elses. -- 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
Re: tape backups
One of the things I've considered, but haven't had the time to try yet We are a VM/VSE shop, with Linux on the IFL. On the VSE side, our IP stack is from CSI. And they seem to allow us to FTP to/from a tape. The questions are: 1. When FTPing to a tape drive, can I drive the tape drive without excessive shoe shining? i.e. get any decent performance out of it? But then, at times, I'm not sure I care about performance, if it fits within the batch window. 2. With all the translation going on, when I ftp the tape file back to Linux disk, will it still be in the proper format (i.e. block size, recfm, or whatever it looks like on a Linux file system). Something for me to work on in June er...July... Ok August... Tom Duerbusch THD Consulting -- 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
Re: tape backups
> 1. When FTPing to a tape drive, can I drive the tape drive without > excessive shoe shining? i.e. get any decent performance out of it? But > then, at times, I'm not sure I care about performance, if it fits within > the batch window. Dunno about VSE, but when I've tried this with z/OS (yes, I know it's not supported, so sue me), the holdup is the tape, not the network (or at least from within the machine). It'll depend a lot on how efficient the OS is when moving network buffers to tape and how fast you can write on the tape and clear buffers. > 2. With all the translation going on, when I ftp the tape file back to > Linux disk, will it still be in the proper format (i.e. block size, recfm, > or whatever it looks like on a Linux file system). Linux files are just byte streams. There is no internal structure to preserve, so as long as you transfer in binary mode, Linux doesn't care. -- 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
Re: tape backups
Jorge, Where did you find the statement, "Next major release following NetBackup 6.0 will not support this OS version. This status could change if market and/or vendor support positions change"? I poked around in the NetBackup section of symantec.com, but didn't find it. Dennis O'Brien "I don't have a girlfriend. I just know a girl who would get really mad if she heard me say that". -- Mitch Hedberg -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Jorge Souto Sent: Monday, August 06, 2007 09:07 To: LINUX-390@VM.MARIST.EDU Subject: Re: tape backups Our heads agree that TSM it's expensive. We will choose between: 1) Bacula / Amanda writing to z/OS by: FTP or NFS (hypersockets !!!). We'll backup approx 1 TB by month, then could be 250 GB weekly. I need this space in z/OS dasd, would be great writing directly to tape (maybe ftp'ing with a specific HLQ, so SMS allocates it in tape). 2) Connect the "tape ecosystem" to z/VM LPAR. The machine where it runs is already working with tapes. We have IBM VTS B20 on peer to peer (in progress...). I don't understand why Symantec discontinues Veritas Netbackup on z/Linux "Next major release following NetBackup 6.0 will not support this OS version. This status could change if market and/or vendor support positions change" Thanks 2007/8/6, Alan Altmark <[EMAIL PROTECTED]>: > > On Monday, 08/06/2007 at 08:38 EDT, David Boyes <[EMAIL PROTECTED]> > wrote: > > > We are considering (and we should) backup our linux guests on z/VM. > > Any > > > suggestion? > > > Perhaps Tivoli TSM... > > > > Works, but is expensive. Also requires SCSI/FCP tape drives. > > Assuming the TSM server is on Linux or on another distributed system. If > it's on z/OS, channel-attached drives work just fine. > > Caveat emptor: Just because you have z/OS in-house, don't *assume* your > z/OS folks are willing to pick up that kind of workload. An analysis of > the increased CPU requirements would have to be performed and weighed > against the costs of integration into your SCSI/FCP tape ecosystem (that > does assume you have one to integrate into!). > > Alan Altmark > z/VM Development > IBM Endicott > > -- > 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 > -- 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 -- 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
Re: tape backups
Hello, Here is the support matrix: http://www.redflag-linux.com/ppd/product_files/application_doc/Veritas-netbackup6.0-dc41Ia32-dc50IA64EM64t.pdf I can't find it now in Symantec, but sure it is. See you son -- 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
Re: tape backups
Thank you very much David. I prefer NFS but we don't have it installed. I suppose it's no-cost, and comes with z/OS. We will store a lot of server's logs in z/linux (topic "file serving") for two weeks, or one month. After we'll migrate and store them in our recently bought EMC's Centera, for two years max (legal requirement). Then we'll migrate them to tape. How can I backup the z/VM and the linux resident minidiscs? I appreciate your help and knowledge of both platforms. -- 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
Re: tape backups
To backup the z/VM minidisks and the linux minidisks, we do image backups for Disaster Recovery using DDR. VM:Backup and IBM's Backup/Restore Manager can also do the job of full volume, minidisk-level image backups and CMS file-level backups. There are some homegrown CMS file-level Backup/Restore programs in old program collections, most are based on the VMFPLC2 utility. /Tom Kern /301-903-2211 --- Jorge Souto <[EMAIL PROTECTED]> wrote: > Thank you very much David. > > I prefer NFS but we don't have it installed. I suppose it's no-cost, and > comes with z/OS. > > We will store a lot of server's logs in z/linux (topic "file serving") for > two weeks, or one month. After we'll migrate and store them in our recently > bought EMC's Centera, for two years max (legal requirement). Then we'll > migrate them to tape. > > How can I backup the z/VM and the linux resident minidiscs? > > I appreciate your help and knowledge of both platforms. > Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC -- 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
Re: tape backups
> I prefer NFS but we don't have it installed. I suppose it's no-cost, and > comes with z/OS. I *think* it does nowadays, but you'd need to ask someone more familiar with z/OS packaging. I just configure 'em, I don't license 'em. See your system programmer. Void where prohibited. 8-) > We will store a lot of server's logs in z/linux (topic "file serving") for > two weeks, or one month. After we'll migrate and store them in our > recently > bought EMC's Centera, for two years max (legal requirement). Then we'll > migrate them to tape. Another reason to use Bacula. Bacula supports multiple pools for migration. Set up logrotate as normal, and include the directories where you store your logs in your normal Bacula backup jobs. Define a disk pool for the day-to-day backups as the first pool in the chain and use that for the target pool in the job definition. Define a pool on the Centera as the next pool in the chain and set up a migration job to move files older than two weeks or a month from the first pool to the Centera pool. Define a pool on z/OS NFS disk, and set up a migration job to move files older than 2 years from the Centera pool to the z/OS NFS pool. Set up DFSMShsm migration on the z/OS datasets in the NFS pool as ASAP migration, and you've got the whole ball of wax completely automated and hands-free. > How can I backup the z/VM and the linux resident minidiscs? 0) Take a dump of your z/VM IPL volume with regular DDR or ADRDSSU and put that tape away somewhere safe as an emergency 1-pack system. You should stick CMSDDR and/or PIPEDDR on a minidisk attached to the OPERATOR id so they end up on the z/VM IPL volume as part of your emergency system. Also, make sure MAINT 190 also stays on that volume so you can get in and use CMS if everything craters. 1) Separate your z/VM sysres and CMS-related data on one set of DASD. Put your Linux guests on a different group of DASD. Do not EVER mix the two. Keep PAGE and SPOL data on separate DASD from either one. 2) Use PIPEDDR or CMSDDR (both from the VM download library at www.vm.ibm.com/download) to dump the sysres and CMS-related data with the COMPRESS operand (for CMSDDR, PIPEDDR automagically does that) to CMS files (one per volume), and write a short exec to VMARC the CMS files containing the dumps (to protect the record structure) and copy them to your z/OS NFS area using the CMS NFS client. Migrate to tape them on the same schedule as you do your Bacula volumes. 3) Dump your SPOL data using SPXTAPE occasionally. On a system with few or no CMS users, this data changes rarely, so you don't have to do this very often (once a month is usually sufficient) -- note that this is the only piece which you need an actual real physical tape drive to perform. PAGE data is volatile, so you don't really have to care about those packs other than to know they're there and provide a similar amount of space in case of a disaster. 3.5) Use minidisks for your Linux installs that start at cyl 1, not 0, and are 1 cylinder short of the end of the volume. Wastes a little disk space, but lets you easily restore them 2nd level if you need to. 4) Back up your Linux guests with Bacula the same way I described for your log data. The only exception is your Bacula backup server guest, which needs to be dumped along with the z/VM and CMS data after it is shut down and logged off. If you have to restore from bare metal, you'll restore your IPL volume from the DDR or ADRDSSU tape, IPL, create some SPOL and PAGE volumes with ICKDSF, format and label a volume for the Bacula server guest, then restore the Bacula server from the CMSDDR or PIPEDDR dump. You then IPL the Bacula server and use it to restore everything else. 5) Make an IPLable emergency tape for your version of Linux as a safety net just in case something doesn't restore correctly and you need to boot Linux from tape and rerun zipl to re-establish boot blocks on a minidisk. You don't absolutely have to have the very latest, but something reasonably close (usually the same major release) is a Good Idea. -- 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
Re: tape backups
You won't like this, but "I think" bacula isn't "Novell supported" on SLES 10 SP1 (SLES 9 SP3 and SLES10) Thank you very much, I'll implement this (or nearly) migration/backup proc. 2007/8/7, David Boyes <[EMAIL PROTECTED]>: > > > I prefer NFS but we don't have it installed. I suppose it's no-cost, > and > > comes with z/OS. > > I *think* it does nowadays, but you'd need to ask someone more familiar > with z/OS packaging. I just configure 'em, I don't license 'em. See your > system programmer. Void where prohibited. 8-) > > > We will store a lot of server's logs in z/linux (topic "file serving") > for > > two weeks, or one month. After we'll migrate and store them in our > > recently > > bought EMC's Centera, for two years max (legal requirement). Then > we'll > > migrate them to tape. > > Another reason to use Bacula. Bacula supports multiple pools for > migration. Set up logrotate as normal, and include the directories where > you store your logs in your normal Bacula backup jobs. Define a disk > pool for the day-to-day backups as the first pool in the chain and use > that for the target pool in the job definition. Define a pool on the > Centera as the next pool in the chain and set up a migration job to move > files older than two weeks or a month from the first pool to the Centera > pool. Define a pool on z/OS NFS disk, and set up a migration job to move > files older than 2 years from the Centera pool to the z/OS NFS pool. Set > up DFSMShsm migration on the z/OS datasets in the NFS pool as ASAP > migration, and you've got the whole ball of wax completely automated and > hands-free. > > > How can I backup the z/VM and the linux resident minidiscs? > > 0) Take a dump of your z/VM IPL volume with regular DDR or ADRDSSU and > put that tape away somewhere safe as an emergency 1-pack system. You > should stick CMSDDR and/or PIPEDDR on a minidisk attached to the > OPERATOR id so they end up on the z/VM IPL volume as part of your > emergency system. Also, make sure MAINT 190 also stays on that volume so > you can get in and use CMS if everything craters. > > 1) Separate your z/VM sysres and CMS-related data on one set of DASD. > Put your Linux guests on a different group of DASD. Do not EVER mix the > two. Keep PAGE and SPOL data on separate DASD from either one. > > 2) Use PIPEDDR or CMSDDR (both from the VM download library at > www.vm.ibm.com/download) to dump the sysres and CMS-related data with > the COMPRESS operand (for CMSDDR, PIPEDDR automagically does that) to > CMS files (one per volume), and write a short exec to VMARC the CMS > files containing the dumps (to protect the record structure) and copy > them to your z/OS NFS area using the CMS NFS client. Migrate to tape > them on the same schedule as you do your Bacula volumes. > > 3) Dump your SPOL data using SPXTAPE occasionally. On a system with few > or no CMS users, this data changes rarely, so you don't have to do this > very often (once a month is usually sufficient) -- note that this is the > only piece which you need an actual real physical tape drive to perform. > PAGE data is volatile, so you don't really have to care about those > packs other than to know they're there and provide a similar amount of > space in case of a disaster. > > 3.5) Use minidisks for your Linux installs that start at cyl 1, not 0, > and are 1 cylinder short of the end of the volume. Wastes a little disk > space, but lets you easily restore them 2nd level if you need to. > > 4) Back up your Linux guests with Bacula the same way I described for > your log data. The only exception is your Bacula backup server guest, > which needs to be dumped along with the z/VM and CMS data after it is > shut down and logged off. If you have to restore from bare metal, you'll > restore your IPL volume from the DDR or ADRDSSU tape, IPL, create some > SPOL and PAGE volumes with ICKDSF, format and label a volume for the > Bacula server guest, then restore the Bacula server from the CMSDDR or > PIPEDDR dump. You then IPL the Bacula server and use it to restore > everything else. > > 5) Make an IPLable emergency tape for your version of Linux as a safety > net just in case something doesn't restore correctly and you need to > boot Linux from tape and rerun zipl to re-establish boot blocks on a > minidisk. You don't absolutely have to have the very latest, but > something reasonably close (usually the same major release) is a Good > Idea. > > -- > 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 > -- 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
Re: tape backups
> -Original Message- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On > Behalf Of David Boyes > Sent: Monday, August 06, 2007 8:49 PM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: tape backups > > > > I prefer NFS but we don't have it installed. I suppose it's no-cost, > and > > comes with z/OS. > Yes, at least with z/OS 1.6 and above the NFS client and server comes bundled with z/OS. On my system, the datasets start with SYS1.NFS* -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Re: tape backups
>>> On Tue, Aug 7, 2007 at 2:44 AM, in message <[EMAIL PROTECTED]>, Jorge Souto <[EMAIL PROTECTED]> wrote: > You won't like this, but "I think" bacula isn't "Novell supported" on SLES > 10 SP1 (SLES 9 SP3 and SLES10) No, it's not, but it's going to be in SUSE Linux 10.3, and I've already put in the request for it to be in SLES11. Hopefully it will make it. In the meantime, Amanda is in SLES, so you can use that for now. Mark Post -- 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
