Right about the VM:Backup detection. Alas, HIDRO cannot (but it does run much faster :).
While it is a good idea to break your file systems up a bit, the swapping in and out is going to be way tricker. It will work for things like WAS6 (get ahold of IBM Steve Wehrs paper). But rpm based things like MQ Series and DB2 will need to write to your rpm database in /var . MQ Series also puts some license stuff in /tmp and plenty of stuff in /var/mqm . And many more products don't even give you a choice about where to stick them. Many will put it somewhere in /usr and configs in /etc. That's why there are vendor products to do these things for you :) Marcy Cortes "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Wednesday, March 22, 2006 1:14 PM To: [email protected] Subject: Re: [LINUX-390] VM MDISK assignments for Linux files Actually, Phil, I think VM:Backup can detect differences as long as one sets up an XCEPTS file with: - Backup Type: _ Logical _ CMS _ CMSALLOC x Physical - Change Detection: CMS: _ Date _ Hash Physical: x Hash _ None So far that appears to be working. I don't see most of out inactive guests MDISKs being backed up each day - only those that have changes on them, even though they are changes to files in the Linux filesystem. The "hash" Change Detection is likely costing us some cycles during the middle of the night. But we can afford cycles then, swapping hashing cycles against the savings in backup disk and tape I/O. I realize that we need a Linux-aware backup product. We're taking baby steps at this point. With the P.O.C. still underway VM:Backup physical backups are "good enough". I don't really want to negotiate product licensing (or install, test, implement a free Open Source product) during the P.O.C. But I do want to prepare to swap minidisks in and out as needed. A provisioning manager product trial will likely follow Sthe P.O.C. to make that easier. But we need to start with baby steps. So I'm asking about MDISK allocations as a baby step. Thanks, Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. ------------------------------------------------------------------------ --------- In reply to: Re: VM MDISK assignments for Linux files Phil Tully Wed, 22 Mar 2006 12:36:10 -0800 Mike, VMBackup will not be able to discern if changes occur or not, so it will be taking an image backup everytime. Backing up data on linux side requires a linux aware backup product, the image backup are useful for a point in time recover, but then only if the image is shutdown when taken. Phil Mike Walter wrote: We've just finished installing SLES9, WAS, MQ under z/VM and are preparing our actual Proof of Concept tests. In the meantime, assuming (but you already know it will) that this passes the P.O.C. objectives, I've been toying around with the VM minidisks locations that all this O.S. stuff, products, apps, and user data actually gets written to. To begin with, we'll be backing up the MDISKs with VM:Backup. That means that *any* change to anything on an MDISK will cause the full MDISK to get backed up. The amount of data can grow pretty quickly (right?), so I'd like to break things out onto separate MDISKS for to minimize backups of unchanged data, and very importantly, allow us to swap kernels, products, and business ass in and out by simply swapping MDISKs. We've come up with the following guidelines for Linux guests, but being the Linux newbie on the block, I'd appreciate suggestions. Might as well learn from others' hard-learned experience before we fight the same battles all over again! I hope this makes is through without lines being shifted to the left margin! MDISK range Usage ----- --------------------------------------------------------- 0191 CMS files... e.g. Filename Filetype LIN EXEC LIPL EXEC PROFILE EXEC SLES9 INITRD SLES9 KERNEL userid NETLOG LINUX PARM LINUX... 0200 SWAP (IBM recommends real DASD over VDISK) 0290 Kernel, /root (thinking of 290 as the CMS DISK for Linux) 0291 /tmp (thinking of 291 as the userid local disk, like the CMS 191) 0390 /apps (small MDISK, pointer to other File Systems) x39x /local (call it what you will, locally-written business apps) /wasmq (example - vendor app) x39x /db2 (example - vendor app) x39x /domino (example - vendor app) 0490 /home (small MDISK, pointer to other File Systems) /lxuser1 (example, user files) /lxuser2 (example, user files) Thanks in advance. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. 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. ---------------------------------------------------------------------- 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
