Collocation is wonderful for onsite primary pools. But what about during a disaster where you lost your lovely collocated primary pools? The usual copy pool method, where you take tapes offsite each
Author: James SPORER <james.sporer AT CCMAIL.ADP.WISC DOT EDU>
Date: Fri, 12 Jun 1998 13:54:04 -0600
Colocate your copy storage pool. Jim Collocation is wonderful for onsite primary pools. But what about during a disaster where you lost your lovely collocated primary pools? The usual copy pool metho
Certainly collocate your copy stg pools, but only do that for data that really requires it. If you do it for all of your data, you will have way too many copy stg pool tapes to move to the off-site o
Hello John If this is a major concern, then you can collocate your copypools as well. This implies the same tape usage overhead, or greater than collocating primary pools. This aside it decrease the
Hello John If this is a major concern, then you can collocate your copypools as well. This implies the same tape usage overhead, or greater than collocating primary pools. This aside it decrease the
I'd love to collocate my copy pools. It's unfortunate that it doesn't work. Consider why you can't really use collocation in any useful way in a storage pool where you take tapes offsite: To pick a s
Author: Carl Makin <Carl.Makin AT IPAUSTRALIA.GOV DOT AU>
Date: Mon, 15 Jun 1998 17:26:00 +1000
How about limiting the number of scratch tapes that your copypool can have? From what I understand, ADSM will co-locate up to the limit of the number of scratches allowed and then go back and add ex
Author: Carl Makin <Carl.Makin AT IPAUSTRALIA.GOV DOT AU>
Date: Mon, 15 Jun 1998 17:26:00 +1000
How about limiting the number of scratch tapes that your copypool can have? of scratches allowed and then go back and add extra nodes to existing tapes. If you limit the pool to just a few tapes mor
The point about being selective is this: not all data is created equal. I think that most sites have a few nodes that are absolutely critical. Let's define critical a little better: applications with
Author: John Tarella <gj_tarella AT IT.IBM DOT COM>
Date: Tue, 16 Jun 1998 09:53:49 +0000
There have been many recent appends on colocation for disaster recovery tapes, with the objective of speeding up a potential recovery, by reducing the number of tape mounts required for recovering a
This is the first time in this thread that I have seen the option of restoring the non colocated DR pool to a colocated primary pool before starting with the restores. It does waste some time, but th
Author: James SPORER [SMTP:james.sporer AT CCMAIL.ADP.WISC DOT EDU]
Date: Sun, 04 Oct 2015 17:57:46 -0500
Colocate your copy storage pool. Jim Collocation is wonderful for onsite primary pools. But what about during a disaster where you lost your lovely collocated primary pools? The usual copy pool metho
Author: Carl Makin [SMTP:Carl.Makin AT IPAUSTRALIA.GOV DOT AU]
Date: Sun, 04 Oct 2015 17:57:46 -0500
How about limiting the number of scratch tapes that your copypool can have? of scratches allowed and then go back and add extra nodes to existing tapes. If you limit the pool to just a few tapes mor
I'd love to collocate my copy pools. It's unfortunate that it doesn't work. Consider why you can't really use collocation in any useful way in a storage pool where you take tapes offsite: To pick a s