ADSM-L

Re: [ADSM-L] NAS vs traditional fileservers

2010-06-23 12:52:25
Subject: Re: [ADSM-L] NAS vs traditional fileservers
From: "Prather, Wanda" <wPrather AT ICFI DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 23 Jun 2010 11:51:14 -0500
-TSM NDMP support will give you full or differentials only.  No file
level backups.  You CAN do file-level restores.
The nasty bit:  however many versions of files you want to keep, you
have to keep your NDMP fulls that far back.
(Can you say "buy stock in tape media companies and budget for a bigger
library"?)  

-Besides the excessive amount of media you need in order to keep
multiple versions of 20TB full dumps, it will change the way you do
restores.  The only person who will have access to the restore
capability is a TSM admin with SYSTEM level authority.  That is very
inconvenient for some of my customers, where the filesever admins can do
their own restores by starting the TSM client from their console.    

-I have no vested interest, I don't sell hardware, but I would opt for
the Netapp if possible because of the SNAPDIFF support.  Why other
vendors haven't provided that API I can't figure out.  That is
definitely the only true "solution" to the backup problem.

-Whether you can create copy pools or not, depends on how you set up the
TSM NDMP definitions.  How you set up the TSM NDMP definitions depends
on whether you have your tape drives direct-connected to the TSM server,
or you plan to do your NDMP dumps over TCP/IP.  Read Chap. 7 in the TSM
admin guide on using NDMP.  Read it again.  About the 3rd time, it will
start to make sense.

-If you are going to NAS, remember to keep your LUNS a reasonable size;
you don't want to have to scan a TB if you back up with CIFS, or dump a
TB if you decide to do it with NDMP.

-I think NDMP is just a bad idea all over, if you don't have SNAPDIFF.
You have a backup product with the architecture and capability to a)
back up only changed files, b) keep different files with different
retention rules, and c) dedup on the client end with TSM 6.2.  You give
all that up and go back to something totally primitive with NDMP.

-What I have done for some of my customers is go the CIFS route, but use
multiple proxy servers.  Have server A do its own backups, plus a PROXY
backup for one of the NAS shares.  Have server B do its own backups,
plus a PROXY backup for another one of the NAS shares.  Etc.  So yes
CIFS is slow, but if multiple servers each do a bit, it all gets done,
which it won't if you have just 1 machine trying to scan a zillion tiny
files on all those shares.  And by using PROXYNODE, the backups all end
up as filespaces belonging to 1 TSM node.  That lets you move/change the
PROXY servers as your load moves, and makes it easy to find things when
restoring.     



-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard Rhodes
Sent: Wednesday, June 23, 2010 12:29 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] NAS vs traditional fileservers

We are in the same situation - possibly changing from Win Servers (using
some kind of
microsoft replication) with BA client backups to NAS systems . . .about
+20tb of data also.
 So I'm also interested in any comments.

I've been reading the vendor manuals, TSM doc's and Redbooks, this
mailing
list archive
and anything else that Google finds.

Here is what I "think" I've found out . .

2 ways to backup NAS:  BA client on a CIFS share,  and NDMP.

NDMP:
- uses full/incremental/differential backups
- ndmp on netapp can be either file level or block/volume level
- ndmp on celerra is only file level
- file level ndmp backups are still "file" backups - lots of little
files
will STILL be a challenge!
- a tsm ndmp pool cannot be migrated, reclaimed, movedata'ed - not sure
about copy pools
- it's the tsm management class that determines how long the backup is
retained

BA Client on a Share:
- no journal backups (it's not a win filsystem!)
- CIFS is slow - backups will take a long time
- you do get to keep using your normal TSM mgt class policies
- for netapp, there is a new snapdiff which provides journal like
capabilities (saw some emails that this was very good!)

The main point I've come away with is that switching to a NAS will not
solve our backup
problems  . . .just change problems somewhat.

I would appreciate any comments, additions, and especially  CORRECTIONS.


Thanks!

Rick


"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 06/23/2010
11:39:35 AM:

> We currently use traditional windows fileservers, but are being
presented
with an "opportunity" to start using a NAS device.
> I've been reading up on NDMP, doesn't sound to me like NAS is the
backup
admin's friend.
> Can anyone who has gone down this road share any of the biggest
pros/cons/gotchas?
> I seem to recall from several years ago that getting the backup data
offsite was an issue, but the NAS vendor claims this is no longer true.
>
> Currently using half a dozen fileservers to manage about 20TB of user
data.
>
> Thanks,
>
> Steve Schaub
> Systems Engineer, Windows
> BlueCross BlueShield of Tennessee
> -----------------------------------------------------
> Please see the following link for the BlueCross BlueShield of
Tennessee
E-mail disclaimer:  http://www.bcbst.com/email_disclaimer.shtm


-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.