ADSM-L

Re: [ADSM-L] TSM client backup in a DiskXtender environment

2007-05-29 13:24:00
Subject: Re: [ADSM-L] TSM client backup in a DiskXtender environment
From: "Yang, Fred" <FYang AT NSHS DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 29 May 2007 13:23:08 -0400
You need to work with your storage admin to determine how you want to
backup and how the retention policy will be on Centera or DX side, below
are a few questions you need to have an answer:

1. Is the file being purged once it's migrated to Centera?
2. How frequent the purge rule was setup to run?
3. Is the files in Centera pool was configured to be never deleted?
4. Are there multiple Centera was configured to replicate each other?
5. How you want to recovery the system when the whole Windows server
with DiskXtender need to be recovered?

In our environment, since we have Centera configured to be replicated
between both site, so we do not need to backup original files which has
been migrated to Centera. In DiskXtender, you can configured whether you
want to trigger the file retrieval from Centera when your bakcup program
try to access the file, I have our DiskXtender configured to use
"Special application filtering", and edit the list to set "DSM.EXE",
"DSMC.EXE", "DSMCSVC.EXE", and "DSMAGENT.EXE" so when TSM need to backup
the file, it will only backup the stub file. 
However, if TSM backup always occur before DiskXtender move the files to
Centera, TSM will still backup the files which deemed to be moved to
Centera, but those files can be configured with shorter retention since
finally it will go to Centera. 
Also make sure your DX admin setup scheduled meta data export, so you
can configured TSM to backup the meta data (along with DiskXtender
registry), which is critical when you need to recover the whole
environment.

Regards,
Fred Yang
Sr. System Engineer
Northshore LIJ Health System

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Schneider, John
Sent: Friday, May 25, 2007 5:29 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: TSM client backup in a DiskXtender environment

Greetings,
        We are making plans to implement EMC DiskXtender on a Windows
Filesystem.  We are unclear how the TSM client backs up a filesystem
like this.  In a DiskXtender environment, as files get to a certain age,
say 90 days, they are sent to a DiskXtender backend store, which in our
case will be an EMC Centera.  The files are then replaced with a stub
file that looks like the original name, but is a very small file.  If an
application tries to open a stub file for reading, then DiskXtender
retrieves the file from its backend store, and returns it to the
filesystem This way the filesytem can seem to contain TBs of data, but
only be a couple hundred GBs in actual size.
        The functionality is similar to the TSM HSM software, I guess.
        So when TSM makes a pass through the filesystem the first time,
it is backing up original files.  Then eventually they get turned by
DiskXtender into stub files. But I am told the stub file has the same
date and name and size as the original file, so will TSM back up the
stub, or will it skip over it because it doesn't look changed?  Or, if
it tries to back it up, won't DiskXtender recall the original file, and
so TSM will back up the original?
        My storage guy is saying that TSM needs to back up the stubs, so
that if some sort of corruption happens in the filesystem, we can
restore all the stub files.   He is telling me that if TSM was smart
enough to undertand the Windows Extended Attibutes, it would know how to
back up a stub file. Or does DiskXtender have a way to recreate the stub
files?

        If anyone has this implemented, please describe how it works.

Best Regards,

John D. Schneider
Sr. System Administrator - Storage
Sisters of Mercy Health System
3637 South Geyer Road
St. Louis, MO.  63127
Email:  schnjd AT stlo.mercy DOT net
Office: 314-364-3150, Cell:  314-486-2359

>  -----Original Message-----
> From:         De la Fuente, Jason  
> Sent: Friday, May 25, 2007 12:13 PM
> To:   Dawson_Chris AT emc DOT com; Hansen_Bruce AT emc DOT com; Schneider, 
> John;
> Hoerchler_Scott AT emc DOT com; 'Dickerson_Charles AT emc DOT com'
> Subject:      Centera Stub Files/DX/TSM
> 
> Anyone,
> 
> At EMC World this week, some DX folks were telling me that TSM does
> not recognize the extended file attributes that are associated with
> stub files.  Consequently, a backup of a stubbed file would cause the
> entire file to be pulled back from the Centera.  In a later session,
> another customer stated that IBM had addressed this issue and that TSM
> does now support extended file attributes.
> 
> Can someone shed some light on this as it is relevant to our current
> direction of leveraging the Centera for the Enterprise Imaging and
> Medical Imaging (PACS) archive.
> 
> Thanks!
> 
> Jason de la Fuente
> MISD Enterprise Storage Lead
> 314-364-3148
> fuenjj AT stlo.mercy DOT net
> 



---------------------------------------------------------------------------------
The information contained in this electronic e-mail transmission
and any attachments are intended only for the use of the individual
or entity to whom or to which it is addressed, and may contain
information that is privileged, confidential and exempt from
disclosure under applicable law. If the reader of this communication
is not the intended recipient, or the employee or agent responsible
for delivering this communication to the intended recipient, you
are hereby notified that any dissemination, distribution, copying
or disclosure of this communication and any attachment is strictly
prohibited. If you have received this transmission in error, please
notify the sender immediately by telephone and electronic mail,
and delete the original communication and any attachment from any
computer, server or other electronic recording or storage device
or medium. Receipt by anyone other than the intended recipient is
not a waiver of any attorney-client, physician-patient or other
privilege. Thank you.

<Prev in Thread] Current Thread [Next in Thread>