The other side of this is that with 3rd party deduplicated replication, my 
offsite copy is rarely more than one hour behind the source copy.  Before 
I moved to this, we would schedule our backup-stg pools to run once a day, 
and they would have to run several hours before it was in sync.   If there 
was a real DR situation, we would lose much more data by being up to 
24-hours out of sync with the old "backup-stg" solution.   And it's always 
recent "just backed-up" data that is the most desirable after a DR 
situation. 

 The chances of a real DR situation seem higher to me than a logical 
error.  Perhaps just feeling like that after seeing a minor earthquake and 
a hurricane within a couple weeks of each other. 

 I have seen a few logical errors and a few DR situations in my career and 
even in my conservative bank environment, a 
single-pool-3rd-party-replicated is lower risk than the slow-backup-stg 
solution.  We still keep periodic longer term backups on Tape, so we would 
have a "last resort" restore source if there was a logical error, but it 
is still not a daily backup.

In the end, its a risk trade-off decision that you have to make for 
yourself.  And decide if you can afford the time that a backup-stg takes 
each day. 


Regards, 
Shawn
________________________________________________
Shawn Drew





Internet
steven.langdale AT GMAIL DOT COM

Sent by: ADSM-L AT VM.MARIST DOT EDU
10/04/2011 02:57 AM
Please respond to
ADSM-L AT VM.MARIST DOT EDU


To
ADSM-L
cc

Subject
Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: 
Re: [ADSM-L] vtl versus file systems for pirmary pool






The "logical error" question has come up before.  With no TSM managed copy
pool you are perhaps at a slightly higher risk.

An option is to still have a copy pool, but on the same DD.  So little 
real
disk usage, but some protection from a TSM logical error.  That obviously
does not protect you from a DD induced one.

FWIW, when we implement VTL's, and if the bandwidth allows, we use TSM to
create the copy.  Small sites with limited bandwidth, we rely on the
appliance.

Steven



On 4 October 2011 06:41, Daniel Sparrman <daniel.sparrman AT exist DOT se> 
wrote:

> > If someone puts a high-caliber bullet through my Gainesville DD, then
> > I recover it from the replicated offsite DD, perhaps selecting a
> snapshot.
> >
> > If someone puts a high-caliber bullet through both of them, then I
> > have lost my backups of a bunch of important databases.
>
> And if you have a logical error on your primary box, which is then
> replicated to your 2nd box? Or even worse, a hash conflict?
>
> I dont consider someone putting a bullet through both the boxes a high
> risk, I do however consider other errors to be more of a high risk.
>
> Best Regards
>
> Daniel
>
>
>
>
>
> Daniel Sparrman
> Exist i Stockholm AB
> Växel: 08-754 98 00
> Fax: 08-754 97 30
> daniel.sparrman AT exist DOT se
> http://www.existgruppen.se
> Posthusgatan 1 761 30 NORRTÄLJE
>
>
> -----"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> skrev: -----
> Till: ADSM-L AT VM.MARIST DOT EDU
> Från: "Allen S. Rout"
> Sänt av: "ADSM: Dist Stor Manager"
> Datum: 10/03/2011 23:38
> Ärende: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: 
[ADSM-L]
> vtl versus file systems for pirmary pool
>
> On 09/28/2011 02:16 AM, Daniel Sparrman wrote:
>
> > In this mail, it really sounds like you're using your DD as both
> > primary storage and for TSM storage.
>
> I am, right now, using the DD as a target for direct-written database
> backups, only.  So that's not really "primary storage", as I think
> about it.
>
>
> > If the DD box fails, what are your losses?
>
> If someone puts a high-caliber bullet through my Gainesville DD, then
> I recover it from the replicated offsite DD, perhaps selecting a 
snapshot.
>
> If someone puts a high-caliber bullet through both of them, then I
> have lost my backups of a bunch of important databases.
>
>
>
> > Sorry for all the questions, I'm just trying to get an idea how
> > you're using this box.
>
> No problem. Our conversation is fuzzed by the fact that I am also
> talking about how one _might_ use it for TSM storage.  I'm
> contemplating it, but not doing it at the moment.
>
> > [ ... if you lose a DD, then ... ] you have to restore the data from
> > somewhere else (tape?).
>
>
> In my planning, the DD gets copied / offsited to a remote DD, so
> that's the somewhere else.
>
> - Allen S. Rout
>



This message and any attachments (the "message") is intended solely for 
the addressees and is confidential. If you receive this message in error, 
please delete it and immediately notify the sender. Any use not in accord 
with its purpose, any dissemination or disclosure, either whole or partial, 
is prohibited except formal approval. The internet can not guarantee the 
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) 
not therefore be liable for the message if modified. Please note that certain 
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.