>From what I understand the EMC/DD Best Practice is to use NFS/CIFS mounts
with File device classes over 10gb connections.   The main benefit cited
is the concurrent access to file volumes.  There is a TSM/DD Best
Practices document out there from Glasshouse a few years ago that mentions
this. (Which might be where EMC got it)

Regards,
Shawn
________________________________________________
Shawn Drew





Internet
tsm AT NETWORKC.CO DOT UK

Sent by: ADSM-L AT VM.MARIST DOT EDU
08/26/2010 04:38 PM
Please respond to
ADSM-L AT VM.MARIST DOT EDU


To
ADSM-L
cc

Subject
Re: [ADSM-L] Data Domain: Data Domain, and SQL-Backtrack with Sybase
databases






Curtis,

>> Data Domain has good market share, but very few DD customers use VTL.

Really? That surprises me a little (i.e., the marginalised VTL usage) and
isn't necessarily representative of the TSM customers I've spoken to or
worked with using DDRs, many of whom still use the VTL functionality. I
can't comment on whether this is so much the case with shops that use
other backup software though (e.g., I know NBU has its own OST interface).

In any case, whether through VTL or NFS/CIFS the principle is the same and
of course you're right, pre-appliance compression or even encryption can
be catastrophic to data de-dupe ratios. Without knowing any more, it
sounds like you may have to make a compromise somewhere without changing
your current config Nancy, either in terms of backup data storage
footprint or RPO.

Cheers,
__________________
David McClelland
London, UK

On 26 Aug 2010, at 19:10, Nobody <wcplists1 AT GMAIL DOT COM> wrote:

> Data Domain has good market share, but very few DD customers use
> VTL.



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.