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 the 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
