Paul, NDMP uses a full/differential method which does not fit well with our long retention requirements. Running daily differentials with a weekly full on 30TB of data would fill my library in less than 100 weeks with no consideration for any other backup data. The process for performing a restore was also a bit more complicated that a simple BA client restore.
Currently our file level restores take a few minutes - very acceptable - and are performed identically as a regular server file restore. Snapshot schedule: - every 4 hours keeping 24 hours -(RPO = 4 hours for the first 24 hours) - nightly keeping 5 nights - (RPO = 24 hours for 24 hrs < data < 5 days) - weekly keeping 2 weeks (not too usefull but it satisfies other peoples perceptions) We also mirror data once a day (more frequent for critical data) to a remote site. TSM provides the long term retention we need and fairly quick assisted data recovery. Users have the option to recover recently deleted data from snapshot or request assistance from our support team. Full scale failover to the remote site filer takes a few minutes. If the -snapdiff option improves backup times as I hope, I will be able to eliminate the weekly snapshots (saving disk space) and should be able to provide a firm 24 hour RPO for all data as well as a firm sync point. Currently, backups begin and run for about 26 hours (noodling through millions of files - not a data throughput problem) and there is no guaranteed point in time recovery because the files backed up at 8pm monday may change by the time other files are backed up at 10am Tuesday (during the same backup session). Cheers, Neil Strand Storage Engineer - Legg Mason Baltimore, MD. (410) 580-7491 Whatever you can do or believe you can, begin it. Boldness has genius, power and magic. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Paul Zarnowski Sent: Thursday, June 11, 2009 2:52 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Snapdiff option with V6.1 Windows client We are looking to do this down the road, but no experience yet. - What kind of NDMP backups were you trying to do, and what problems did you run into? - Are you concerned about how long it would take to do a file-level restore for such a large server? - Do you keep internal snaps in the NetApp for user restores? ..Paul At 02:18 PM 6/11/2009, you wrote: >Has anyone put this into production use yet? Our initial testing is >very positive. > > Currently we have to keep all user files for 7 years. I have 2 >NetApp filer clusters with about 35 million files in 130 CIFS shares. >NDMP backup is unworkable. It takes slightly over 24 hours to perform >one complete backup from 6 Windows backup clients noodling through all >of these files and sending about 200GB of changed data to 2 AIX TSM >servers (currently we have about 300TB of data on tape). The data >transfer is not the slow part - the search through the files is what >takes most of the time. > > We have done quite a bit of testing with -snapdiff and discovered a >few differences in how files are processed but nothing so far that will >keep us from putting this feature into production soon. I am expecting >to dramatically reduce my backup time while maintaining or improving >service levels and expectations. > > I would appreciate anyone's input with their experience with this >feature. > > >For those who would like to know, these filers are mirrored to a remote >site. TSM is a secondary recovery mechanism - I don't expect to >recover an entire filer with TSM, but could....with a couple of weeks >spare time >:) > > >Thank you, >Neil Strand >Storage Engineer - Legg Mason >Baltimore, MD. >(410) 580-7491 >Whatever you can do or believe you can, begin it. >Boldness has genius, power and magic. > >IMPORTANT: E-mail sent through the Internet is not secure. Legg Mason >therefore recommends that you do not send any confidential or sensitive >information to us via electronic mail, including social security >numbers, account numbers, or personal identification numbers. Delivery, >and or timely delivery of Internet mail is not guaranteed. Legg Mason >therefore recommends that you do not send time sensitive or >action-oriented messages to us via electronic mail. This message is >intended for the addressee only and may contain privileged or >confidential information. Unless you are the intended recipient, you >may not use, copy or disclose to anyone any information contained in >this message. If you have received this message in error, please notify >the author by replying to this message and then kindly delete the message. Thank you. -- Paul Zarnowski Ph: 607-255-4757 Manager, Storage Services Fx: 607-255-8521 719 Rhodes Hall, Ithaca, NY 14853-3801 Em: p...@cornell.edu IMPORTANT: E-mail sent through the Internet is not secure. Legg Mason therefore recommends that you do not send any confidential or sensitive information to us via electronic mail, including social security numbers, account numbers, or personal identification numbers. Delivery, and or timely delivery of Internet mail is not guaranteed. Legg Mason therefore recommends that you do not send time sensitive or action-oriented messages to us via electronic mail. This message is intended for the addressee only and may contain privileged or confidential information. Unless you are the intended recipient, you may not use, copy or disclose to anyone any information contained in this message. If you have received this message in error, please notify the author by replying to this message and then kindly delete the message. Thank you.
