The NAS vendor is recommending that the NAS box both dedup and compress the
files on it. This sounds good for space, but I'm thinking that this will
cause NDMP backup to take even longer. I'm think if I do a NDMP full of
+20tb of data and that data is all compressed, it's the same as
uncompressing all that data to send it to TSM. ALso, the dedup would need
to be un-deduped before sending it.
Any thoughts on this?
Rick
"Sheppard, Sam"
<SSheppard@SDDPC.
ORG> To
Sent by: "ADSM: ADSM-L AT VM.MARIST DOT EDU
Dist Stor cc
Manager"
<[email protected] Subject
.EDU> Re: NAS vs traditional fileservers
06/23/2010 01:04
PM
Please respond to
"ADSM: Dist Stor
Manager"
<[email protected]
.EDU>
We're in the middle of doing something similar. We have 17TB of windows
file/print data being backed up by 5 servers, total of 33M files. Several
of the volumes are almost 2TB with several million files and all of the
problems associated with that. So the windows guy is moving all of this to
CIFS and we'll (hopefully) end up with several smaller volumes.
We did some testing using TSM 6.1.3.4 and NDMP full/diff to TS1120 tape.
Backup times for 2 of the 3 test volumes was not that great, around
18MB/sec. The third volume backed up in half the time. According to the
Netapp guy, some kind of contention/hotspot on the filer. This is backing
up filer-server, not filer-tape. And filer-server allows you to do all of
the traditional housekeeping tasks on the storage pools. Looked like it
would be doable, until we added up all of the problems:
1. As mentioned elsewhere, the differentials, though just a fraction of the
fulls estimate their size as the same as the fulls, so disk pools for the
differentials were out, meaning all of the dozens of differentials every
night would need a tape drive. A big scheduling headache, but not a
show-stopper.
2. We tested TOC to get individual file restore capability. Performance was
terrible; over an hour to restore one 50MB file. Only good news here is
that increasing the size and number of files restored did not have an
equivalent increase in restore time and the proposal was to keep enough
snapshots to restore back two weeks. So the individual restore would be a
last resort.
3. It appeared the tape compression on NDMP data was not nearly as good as
on normal backups, leading to an increase in the number of tapes needed.
4. You will need a filer at your DR site to perform restores there.
There was not enough upside to counteract the downsides for us, so we are
going to use the SNAPDIFF feature for this application and use NDMP for a
couple of big applications that were using image backups. NDMP ended up
being over twice as fast for these.
Sam Sheppard
San Diego Data Processing Corp.
(858)-581-9668
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Schaub, Steve
Sent: Wednesday, June 23, 2010 8:40 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] NAS vs traditional fileservers
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.
|
