On Thursday, 08/12/2010 at 11:36 EDT, "Martin, Terry R. (CMS/CTR) (CTR)" <terry.mar...@cms.hhs.gov> wrote:
> Yes, I knew that the backup would be a ?fuzzy? one but I have not had an issue > with restoring since I am doing a physical cylinder by cylinder backup. We do > use FDRUPSTREAM to handle the incremental and full backups of all the DASD for > each guest, but the DFDSS is a little different. Not had an issue *yet*, I think you meant to say. It may simply be fuzzy, or it may be positively hirsute. Out-of-band backups of dasd, particularly multiple volumes, is a disaster waiting to happen. Multiple volumes compound the risk (think: LVM). Bring the server down, snapshot/flashcopy/whatever all of its volumes, restart the server, then backup the copies. This minimizes down time and ensures a *consistent* backup set. (The real requirement is that the volumes be unmounted, but it's just easier to bring down the server, IMO.) Linux's support for suspend/resume may be able to help with this as well and reduce the length of the outage even more. But since you're using FDRUpstream for incremental AND full backups, it seems that you only need a functioning Linux with FDRUpstream available, not a fully restored Linux image. That is, enough to kick off the restore from the FDR backups. No point in backing up, storing, and restoring data you're going to throw away anyway. IMO, of course. As a security person, it's my job to be paranoid. I don't worry about the 95% of the time that it works ok, I worry about the 5% of the time that it doesn't. Alan Altmark z/VM Development IBM Endicott
