...- We can't use NFS mounts because we lose the ACLS. We ~could~ backup the ACLS separately and reapply them to restored files, but operations balks that creates too much room for error in these days of SOX/HIPPA regulations.
Curious, having been burned with the ACL issues before: How would one go about backing up the ACLs separately? And reapplying them to restored files? Thanks! -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Ben Bullock Sent: Wednesday, March 08, 2006 12:23 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: ndmp limitations We are dipping out toes in the NDMP pool for some of our largest Qtrees. There are some pros and cons, and I believe someone earlier today mentioned a few and I agree with them. In my mind, the biggest CON in using NDMP is the inability to make copypool duplicates. This suddenly puts a HUGE hole in your DR plan unless you start taking the primary tapes out of the library. And of course then the data is not available for the day-to-day end-user restores. IBM has indicated that NDMP data should be integrated into the Storage pool hierarchy by the end of the year, so that should fix that problem. The single thread per NDMP process can be a performance problem, as mentioned before. The Full -incr -incr -incr ..-Full methodology is a step backwards and if your retentions are very long, you will end up keeping MUCH more data in TSM than through normal TSM backups. I don't believe that there is any way to differentiate retentions for files in an NDMP backup. I believe that you have to keep the whole vol/qtree for the same amount of time, so that is also kind of a step backwards. Then there is the issue of needing one tape drive for every NDMP process you have going. This can be remedied with a VTL, but for those of us without one, it means tying up tape drives to NDMP... The one PRO that everyone sites is : faster backup times, and that is true, but depending on the TOC size, the restore performance may be very poor. So you can get tell I'm not really impressed with NDMP, however we are still looking into it. Our reason is that we have some NT filesystems with over 10- 24 million files that we back up using a Windows client so we can get the ACLs, and the performance is HORRIBLE. We are talking multiple days for an incremental backup. - We can't use the journaling feature, because that only works on local disks, not CIFS mounts. - We can't use NFS mounts because we lose the ACLS. We ~could~ backup the ACLS separately and reapply them to restored files, but operations balks that creates too much room for error in these days of SOX/HIPPA regulations. Ben -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Jason Lee Sent: Wednesday, March 08, 2006 9:37 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: ndmp limitations On Mar 8, 2006, at 7:25 AM, John Bremer wrote: > Greetings, > > We've been using TSM with NDMP for over a year, and while we want our > customers to use our service rather than Legato (the predecessor), > there are some limitations: > > (1) There are situations where TSM (or NetApp/NDMP) does not translate > certain file/path names properly, and TOC builds fail. We have been > working with IBM quite a lot on this, and have resolved > *most* issues; > > (2) TOC loads on the TSM server are *excruciatingly* slow. We have > thrown all the hardware and memory we can at the server, and some TOC > loads still take 4 hours (yes, that is not a typographical error). > Granted these are multi-TB volumes with millions of files, still there > should be a better way to get the TOC records from disk to database. > That's another problem we have open with IBM, and we are working with > their performance people. > > (3) We recommend defining as many virtual mapping points as possible: > volume restores can be done in parallel, and above mentioned TOC loads > are quicker. It adds another level of administration, but no big > deal. > > We recently restored a 3.3TB volume which took about 29 hours, using > one 9940B drive. > > Overall we are happier with TSM using NDMP than backing up these large > filers over TCP, through a TSM backup client (though file level > restore was/is a lot better there). > > John Hi John, you mention that overall you are happier with the TSM using NDMP rather than TCP. Could you expand on that for me? We're looking to perhaps use NDMP on our NetApp farm but would love to get a pro/con feel going before committing the resources. Thanks very much Jason -- Jason Lee DreamWorks Animation (818) 695-3782
