[prev in list] [next in list] [prev in thread] [next in thread] 

List:       adsm-l
Subject:    Re: [EXTERNAL] Re: How to backup ISILON storage
From:       "Rhodes, Richard L." <rrhodes () FIRSTENERGYCORP ! COM>
Date:       2018-02-08 12:06:49
Message-ID: BN6PR05MB3249B1EFE4CB87E459D6FD2DB6F30 () BN6PR05MB3249 ! namprd05 ! prod ! outlook ! com
[Download RAW message or body]

> I would seriously look into some form of async replication native to ISILON, \
> something like netapp's snapvault, first.

We are just just finishing the first phase of implementing a Isilon NAS, which \
consolidated dozens of Windows servers.  One of the reasons (by no means all of them) \
of going to the NAS was backups and getting out from under TSM.  We setup to use \
Isilon SyncIQ (replication) and SnapIQ (snapshots) for backups. So far it's worked \
very well.  These features cost $$$ in terms of licensing, disk space and network \
bandwidth. Besides getting the money, the snapshots require you to guestimate the \
change rate and retention of your data.  Right-click-restore-previous-version is \
wonderful!

We also have a document management system that has multiple databases with \
corresponding CIFS shares.  Originally the CIFS shares were just Win servers.  We \
used TSM to back it all up.  Again, it hit TSM right at its worst - many millions of \
little files. We were struggling to get 1 good backup of the CIFS shares per day.  \
When the user required 4 backups per day (and other reasons), we converted the whole \
thing to NetApp NAS/SAN and used snapshots and replication for backups and DR.



Rick






-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Remco Post
Sent: Thursday, February 8, 2018 4:17 AM
To: ADSM-L@VM.MARIST.EDU
Subject: [EXTERNAL] Re: How to backup ISILON storage

> On 7 Feb 2018, at 21:26, Zoltan Forray <zforray@VCU.EDU> wrote:
> 
> As you recall, we have been trying to figure out an alternative method to
> backing up DFS mounted ISILON storage since the current method of 80+
> separate nodes accessed via the Web interface of the BA client is going
> away.  Plus the backups are taking soooooo long, we have to determine a
> better way.
> 
> So, doing some digging, one solution that seems to be touted is using
> NDMP.
> 
> We have absolutely zero experience with NDMP  and are looking for some
> guidance / cookbook / real-world experiences on how we would use NDMP to
> backup ISILON storage (>400TB and hundreds of millions of files) and make
> it accessible so someone from a help-desk like environment could handle
> file-level restores!

I don't like TSM NDMP one bit, and I guess it's no worse than any of the other backup \
vendors' implementations, because NDMP is just what it is, and that is not much. I \
would seriously look into some form of async replication native to ISILON, something \
like netapp's snapvault, first. Yes that requires a a huge pile of disk just for \
backup, but it will probably be worth it. Even if the investment is quite high. Don't \
forget with TSM terabyte licenses you'll be paying a lot (a huge lot!) to IBM for \
your NDMP backups.

You can basically NDMP via LAN and via SAN. The latter has the disadvantage that the \
TSM server running the backups must be the library manager for those tape drives. I \
would have loved to see that IBM would make NDMP and Library Managers play nice, but \
alas… NDMP via LAN allows you to use normal disk and tape based storage pools, via \
SAN you'll need to create a separate tape pool in the right format (ndmpdump). Also, \
you can't run copy storage pool on those is you use SAN. On 8.1.2 and higher (if you \
dare go there) you could even use directory containers.

The current customer has NAS systems which share directories (called virtual volumes) \
rather than separate file systems. To be able to make a more granular backup/restore \
they use virtualfsmappings in TSM. This works surprisingly well. Now a huge NAS file \
system becomes (usually) a far more manageable directory. So not 200 TB in one huge \
lump to backup, but mostly directories of under 1 TB. The backups are slow, but on \
average manageable. We have a few exceptions that we backup via the share because \
they are just too big to manage via NDMP. Problem with NDMP is that if (with TSM 8.1) \
a single transaction spans more than 90% of the active log, the transaction gets \
killed by TSM. This is on average a good thing, but that makes the combination of a \
busy TSM server with loads of files and NDMP not a happy one, at least not for those \
few huge virtual volumes.

So basically:

- look at other solutions (snapvault or whatever it's called for your NAS)
- then again look at those solutions
- virtualfsmappings might make things more manageable if you decide to go with TSM \
                anyway
- SAN and LAN both have disadvantages, neither one is perfect
- maybe a dedicated TSM instance to avoid issues with long running ndmp dumps

> 
> Or if NDMP is the wrong direction, please tell us so.
> --
> *Zoltan Forray*
> Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
> Xymon Monitor Administrator
> VMware Administrator
> Virginia Commonwealth University
> UCC/Office of Technology Services
> www.ucc.vcu.edu
> zforray@vcu.edu - 804-828-4807
> Don't be a phishing victim - VCU and other reputable organizations will
> never use email to request that you reply with your password, social
> security number or confidential personal information. For more details
> visit http://phishing.vcu.edu/

-- 

 Met vriendelijke groeten/Kind Regards,

Remco Post
r.post@plcs.nl
+31 6 248 21 622
------------------------------------------------------------------------------

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.


[prev in list] [next in list] [prev in thread] [next in thread]