1. All recoveries happen from disk, as close to the application as physically possible.

2. All remote recoveries, required due to major outage at the primary facility(s), occur from disk.

3. Tape is used to create a certain confined number of deep archived backup copies of unique data sets, and is hopefully never, ever needed.

So in the first stage -- the Data Recovery stage -- we backup to a disk-based system. We want everything backed up to that system, and we want to keep stuff there forever if possible. It may be a simple array that becomes the target of our existing backup/recovery software, such as a block-based RAID array or a NAS system. It may be a VTL (virtual tape library), which is a disk box that emulates a tape device(s) to the backup software. Here you are limited only by size and money perhaps. That's why technologies like data de-duplication are so huge here -- if you only truly write unique blocks and/or files, you'll see 20:1 or greater "compression" capabilities. That means you can legitimately keep pretty much all the data ever created in one nice "recovery pool," forever. Any time you need to perform a recovery it is done from this disk pool, on-line, really quickly. Other features like CDP (continuous data protection) are also good here -- and everywhere else -- so that you can add increased granularity to the recoverable data.

The second stage, Disaster Recovery, simply implies that an exact replica of the first stage is remotely shipped off-site to another location. Again, having technology like data de-duplication makes this more than feasible and more than reasonable from an expense perspective. I can have all of my primary sites replicate their Data Recovery staged data to a single, or multiple, disaster sites so that now I can recover off of disk even if I lose a facility. Seems straight forward enough.