You've see two answers that explain why demultiplexed tapes are more
efficient for recovery. I'd like to like the two parts of your question
and show that you could get the best of both worlds by doing what you
are doing.

By backing up to disk you can send many streams to the same device
without having to worry about the multiplexing effect that you see with
tape. When you either clone or stage data from disk it will
automatically save savesets as single streams as fast as the disk can
give it or as fast as the tape can take it (depending on the bottleneck,
there's always a bottlneck somewhere).

We backup to disk, clone daily for offsite tapes and then stage data off
disk to tape for longer term storage (we aim to keep a week's worth but,
during times of high data volumes, that can be shortened to ensure
sufficient disk space available). Would like to move onto replicating
offsite instead of producing tapes onsite, but that's another project.

When estimating required disk space, double the answer you end up with.
I'll tell you why, backing up to disk is fine, it gives you all of the
advantages mentioned, but the more you do it, the more data there is to
shift. Shifting more data takes time, not something that's in abundance
in the backup world. If it takes you 12 hours to backup your clients to
disk, it could well take you near on 12 hours to shift the data from
disk, the way that Networker's automatic staging works it doesn't free
space up until it has staged all of the savesets in its staging list
(you can get round this by scripting but you have to be aware of it).
One way round this is to have twice the number of disk devices and
alternate between them each week so you are filling one lot up during
one week while emptying the other one (this will also prevent the
staging/cloning contention you get with single read on 7.2.x)

Summarise, then. Backing up to disk is a GOOD thing to do. Benefits
include fast recovery from disk, faster DR from tape (no multiplexing),
beter utilisation of tape (writes faster in single streams, fils tape
then moves to next tape). Gotchas include needing much more space than
initial estimates show, need to manage data movement and spot when
things are going awry.

Regards
Bob


>-----Original Message-----
>From: EMC NetWorker discussion 
>[mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On Behalf Of Patricia Neal
>Sent: 15 May 2007 06:25
>To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
>Subject: [Networker] 2 Part Question
>
>Can someone explain the cloning process to me as to why it 
>would be more efficient to do a restore from a clone pool 
>tape, and why this would be a good idea to use the cloned 
>tapes at a disaster recovery test site to speed up things?
>
>Also, when setting up advanced file systems, what is the rule 
>as far as how much free space I need in order to be 
>successful. An example would be, on the weekends I might 
>create my full backups from 4 separate groups containing 
>approx. 300GB's of data each. How much disk space will I need 
>in order to perform this task and also move the data to tape 
>eventually. ( like within the week)
> 
>Patricia Neal
>Production Support Specialist
>C.S.E.A.
>
>To sign off this list, send email to 
>listserv AT listserv.temple DOT edu and type "signoff networker" in 
>the body of the email. Please write to 
>networker-request AT listserv.temple DOT edu if you have any problems 
>with this list. You can access the archives at 
>http://listserv.temple.edu/archives/networker.html or via RSS 
>at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
>

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER