Mark Llewellyn wrote on 06/05/2008 03:12:50 PM: > > Our other option is to simply run two backup jobs, one to the local drive
> and one to the remote, but that effectively doubles the hit of the backup > jobs. The (I/O) performance hit on this might not be as high as you think. If you ran the two backup jobs concurrently (allowed by VM:Backup), the second job (they won't be exactly in sync) can benefit by "drafting" (for all you NASCAR fans) behind the other through the magic of minidisk caching. In such a scenario, VMBACKUP should probably have OPTION NOMDCFS in its directory definition. This is also assuming that: 1) one job doesn't get too far out of sync with the other (ex remote tape drives much slower than local) 2) you have sufficient storage for MDC, to make it worthwhile as a tradeoff for I/O. That said, I would still avoid this option. Restores will be based (generally) on the "last" backup in the catalog, which will likely be associated with the slowest-running backup job. Meaning tapes at the remote (aka "slowest") location will be used. You could adjust for this (could casual users?), but it would be a PITA. Alternatively, you could configure two VMBACKUP machines (ex VMBACKUP and VMBREMOT), but that wouldn't be pretty either. Best regards, Mark Wheeler, 3M Company
