>>> On 9/28/2009 at 12:05 PM, "Hallock, Arthur T" <[email protected]> >>> wrote: -snip- > Since we can perform a consistency snap, that is a point in time copy of the > source volumes, we're considering leaving VM and the Linux servers up while > the snap occurs.
For the Linux piece, at least, that would be a pretty bad idea. Don't do it. > My concern has to do with the recovery of the DB/2 and Oracle databases. I'm > unsure of how the z/Linux and z/VM caching may affect write order sequence. > If the database and the database logs are on different file systems, is it > possible the writes may not be written to the DASD in the same order as they > were issued? Are there options to ensure the write order is maintain? Your databases should have utilities to generate their own backups. I would use them, and not try to outguess the Linux kernel. The chances are you'll lose big time, when you can least afford it. Backups taken from "outside" of Linux should only be used for laying down the file systems, etc. File level backups, taken from "inside" Linux should be used to put things back the way they were. I'm beginning to favor the idea of having "models" that are used as templates for installing new systems, and are kept maintained. DR backups are taken of the models while they are down, and file level backups are taken of the running guests while they are up. Use the models to lay down the base system in a disaster, and the file level backups to bring them up to date. Mark Post ---------------------------------------------------------------------- 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
