> I have a maintenance window of two days a month in which I COULD shutdown the guest, but it'll meet with resistance I'm sure.
Will shutting it down to get the backups meet with any more resistance than the system not being able to run after a restore has been performed? What you suggest is backing up one running system from a 1st level system that has no idea of the filesystems on the 2nd level system. Sure, VM:Backup on the 1st level system knows about CMS files - as long as the minidisks are defined to the 1st level system. But that 2nd level system has it's own CP Directory which cannot tell VM:Backup where the 2nd level systems minidisks start and end, or even who owns the minidisks. So... at best you'll get full-pack "physical" backups from VM:Backup, or from any other product or tool. That's: read a DASD cylinder of bits, write a DASD cylinder's worth of bits to tape. No file-level restores, just whole cylinders. And consider also that the applications on that 2nd level system may be writing to several difference minidisks on different DASD. The VM:Backups will be inconsistent, since the minidisks will be backed up when the app is writing data at different times than the individual cylinder backups are made. That's why database products have their own backup tools - they can ensure a consistent backup. Is there any reason that the 2nd level system could not have VM:Backup installed on it to run its own backups? Yes, you'd have to attach tape drives during the backups, but that is do-able. And if you are using VM:Tape, that 2nd level system would need to have VM:Tape installed as well - again, that's do-able. And that would require any added licensing costs system the CA products are still running on the same physical CPUID. All that said... for many years we had the MVS sysprogs make FDR backups up the VM system DASD, while the VM system was up and running. At no point during any of the (perhaps) 15+ semi-annual D.R. tests were we unable to bring up the VM system once the MVS sysprogs had FDR-restored the VM DASD. After a few tests I grew more leery (see the database/multi-minidisk considerations above). So we ran extensive CMS filesystem utility checks on every single minidisk looking for filesystem errors. None were ever found. We eventually switched to running VM's own VM:Backup D.R. backups (after the MVS guys stopped running any more VM DASD backups w/o telling us - twice!). Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. "KEETON Dave * SDC" <[email protected]> Sent by: "The IBM z/VM Operating System" <[email protected]> 09/20/2010 03:55 PM Please respond to "The IBM z/VM Operating System" <[email protected]> To [email protected] cc Subject Re: DEDICATED DASD - How to backup? I have a maintenance window of two days a month in which I COULD shutdown the guest, but it'll meet with resistance I'm sure. The hope was to back it up daily. There's a total of 42 3380 volume currently. As to the OS, it's VM 3.1 ... yeah, old stuff! We're migrating a customer from their old mainframe. This is a temporary solution. Dave From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of Gentry, Stephen Sent: Monday, September 20, 2010 1:53 PM To: [email protected] Subject: Re: DEDICATED DASD - How to backup? Can the guest be shutdown to do a backup? If so, try defining a full pack minidisk on the dedicated drive and then use vm:backup to backup the minidisk. Does the guest OS have a backup utility? (You didn?t mention what the OS of the guest is). From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of KEETON Dave * SDC Sent: Monday, September 20, 2010 4:48 PM To: [email protected] Subject: DEDICATED DASD - How to backup? I have a guest OS running on 3380 DASD. All of the DASD is defined with DEDICATE statements to that guest only. I'm now trying to determine how to backup that guest. I have the CA VM:Backup (with HiDRO) product, but I'm told it probably won't work because the guest has no minidisks. We have a VTS here, so all the data will be written to virtual tape using the DFSMS/VM (RMS) and CA's VM:Tape. Does anyone have any suggestions? Thanks in advance, Dave Keeton The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
