I manage my DASD in this fashion, i.e. there are DB2 DASD groups, SFS DASD groups, Linux DASD groups, etc. etc. When running a DR backup of a group of packs we shutdown, quiesce or otherwise take steps to ensure the integrity and consistency of everything in the "group" before SnapShotting all volumes in the group.
Linux is indeed a problem for all of the reasons discussed previously, particularly buffered I/O's to disk. It would be REALLY helpful if this were addressed in a future release of Linux, i.e. the ability to instruct the Linux server to flush it's buffers and write everything to disk, initiate no new applications or filesystem writes, etc. A QUIESCE and RESUME command set would be ideal. QUIESCE your Linux server prior to backup, and RESUME service once you have done everything you need to do. For Flash/SnapShot sites it would be quiesced for a matter of seconds as the DASD is snapped, but for shops without this technology the server might be QUIESCEd for hours while it's DASD is backed up to tape and RESUMEd later when it has completed. Michael Coffin, VM Systems Programmer Internal Revenue Service - Room 6527 1111 Constitution Avenue, N.W. Washington, D.C. 20224 Voice: (202) 927-4188 FAX: (202) 622-6726 [EMAIL PROTECTED] -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij Sent: Thursday, April 06, 2006 5:38 PM To: [email protected] Subject: Re: Freeze Linux Guests momentarily On 4/6/06, Alan Altmark <[EMAIL PROTECTED]> wrote: > If you could sync the disks and guarantee that it won't start writing > again before you complete the flash, that would be ok, but I would not > wish to depend on Divine Providence to protect the consistency of the > backup. What we're missing is the ability to flash a set of mini disks as one atomic action. If you just go over the disks and flash them one at a time, in theory there is the risk of inconsistent backups. If you really want you can use LVM to suspend all writes and make all your flash copy actions, and then resume writing to disk again. I am not sure the risk of inconsistent data in a backup is as real as some want you to believe. In a former life I worked on a backup strategy that provided a way to group disks to assure consistent backup copies. When asking application owners wether they needed this, I explained the consequence would also be that if one disk of such a group was lost and needed recovery, we would also restore the other disks in that group to assure the required consistency... And indeed, turned out people rarely had this desire and would rather re-arrange their data to have related stuff on the same disk. Rob -- Rob van der Heij Velocity Software, Inc ---------------------------------------------------------------------- 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
