Thanks to all for the information this will help prepare backup and recovery processes moving forward:
First, we do not count on Full pack backups for our restores normally we use FDRUPSTREAM to backup the guests file systems on a daily and weekly basis, however the guests are still running when this is done other than the Data Base backups where the guest is shutdown and a full backup is taken of the Oracle data base using FDRUPSTREAM. Since we just started adding the z/VM and z/Linux environment as part of the DR testing we are still feeling things out. For instance this will be the first time that we will be taking FDRUPSTREAM with us. The last DR test which was the first one we restored one guest all ECKD DASD from FULL DFDSS backups running on z/OS. Second, for this exercise there is no LVM involved these are just ECKD devices. So synchronization will be less of an issue for these guests and for this test. Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 -----Original Message----- From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of David Boyes Sent: Monday, August 16, 2010 10:51 AM To: [email protected] Subject: Re: How to copy a disk using a z/Linux guest On 8/16/10 10:37 AM, "Macioce, Larry" <[email protected]> wrote: > What about Bacula? Dr Boyes could speak could speak on this point better > And you always want to shutdown the guest to get a good backup Long term, setting up Bacula would probably be a Good Thing, but probably doesn't help much in this scenario, other than to give you a convenient way to dump and restore the contents of the filesystem onto a new disk that doesn't have the missing VTOC problem. The question in my mind is whether the last cylinder of the pack is actually in use and/or whether the filesystem could be resized online to be 180K smaller (so as to free up the last cylinder). DDR is smart enough to be able to relocate the disk image (eg, restore it to cyl+1 on another disk), but that won't fix up any internal references to the filesystem size or LVM magic that might be there, and you will get Weird Failures that you really don't want to try to track down. If it can't be resized or is part of a LVM, then you're SOL on that solution. Ultimately, if you want to keep using DFDSS (and I'll point out that you have been EXTREMELY lucky if you haven't had failures of your backups) the solution is to allocate a new pack with a proper VTOC in cyl 0, and follow the instructions on linuxvm.org to migrate the filesystem from the current disk to the new disk. Short of that, you'll have to use DDR for those two packs (if you use CMSDDR, you can store those two disks as CMS files on one of the other packs, and then restore them back to real DASD from there). That's probably the only way you'll be able to do this quickly enough for your DR test. Larry's suggestion of Bacula is a better long term solution, but that takes a bit of planning you probably don't have time to do now. -- db
