The usual approach for trimming your window uses host-based volume shadowing; host-based RAID-1) as Bob is suggesting. Possibly in conjunction with what Mark is referring to with the controller-level RAID-10, too.
Details on splitting off volumes are in the recent OpenVMS volume shadowing manual. In general terms, you quiesce the database operations, split off the volume, and off you go. You have a disk with a parallel copy of the database and the rest of the data on the disk, and can spin it off to tape at your leisure.
The downside of this technique applied to a database is the possibility of inconsistent data due to in-flight changes. Which is why most production databases including Oracle offer archival processing. Similarly, with MySQL, you'd use the mysqldump tool, and with Rdb you'd use RMU /BACKUP.
SDLT and Ultrium tapes are often faster than disks for various common operations, so I'd have to wonder if the host can supply the data fast enough to keep the drive streaming. SDLT and Ultrium are very sensitive to speeds and feeds, but (when they're streaming) very fast.
BACKUP on OpenVMS is sensitive to the process quotas and (when quotas are tuned correctly, and dependent on the particular setting of /LOAD on recent versions of BACKUP on OpenVMS) can consume an entire processor; it'll drive a tape drive at pretty close to its theoretical limit. The usual limits are then I/O bandwidth, I/O contention or (commonly) disk fragmentation.
http://labs.hoffmanlabs.com/node/49I'd expect Oracle also has quota recommendations.
