> 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
