No one has told us that the two backup runs have to be the same. The DR backups are only used if the primary data center is a pile of rubble. Who cares if they're a few hours older or newer than a set of tapes that is now unusable, and may be irrecoverable? The disaster time is unpredictable. The backup tapes may be 2 hours old or 22 hours old. In either case, the users get what they get. We don't make backups when most of the users are doing their work, but beyond that, it really doesn't matter when they're made.
The other advantage of separate onsite and offsite backup jobs is that your onsite backups aren't held up when your channel extension equipment is down. I'm certainly not advocating BLP. I was just pointing out one of the issues with a tape copy solution. Dennis O'Brien "Don't worry about biting off more than you can chew. Your mouth is bigger than you think." -- CVW-11 chaplain, "Carrier" -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Thursday, June 05, 2008 18:24 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit > This concept was considered, but is really last on the list - it's a bit > of a mine field. > Running two VM:Backup service machines has potential, though, instead of > running two backups serially on the same machine. And how...there be dragons, big time. Two VM:Backup runs (even "simultaneous" runs) have a high probability of being different enough to drive auditors berserk. The system isn't the same as it was with the first set, and you can't stand up and give evidence that the two backups contain the same data, particularly if the system is live during the backup runs. Also, anything that uses BLP tape options is pretty much automatically suspect (and your tape librarians are probably going to get hostile as well -- things like that tend to mess with their worldview of having One True Identifier That Is Immutable In the Whole Enterprise).