I don't have any personal experience with Isilon, so these answers are based on other experience with NDMP and filer devices:
>>Can any of you provide real world backup times for full tree traversal >>backups to TSM using NDMP? I understand my mileage may vary depending on the >>data and it's size as well as the hardware configuration but there must be a >>fairly standard throughput rate for file server data. NDMP is a very old backup protocol without much smarts. It does not traverse the file tree, it dumps the entire share as a single object. The amount of time increases with the size of the share, and is affected by whether you are doing it via TCP/IP or direct to tape via fibre, the disk in the device, etc. The biggest problem is that you can only do fulls and differentials. That means you are pushing backups of the same unchanged data over and over again, and if you want to have 6 months coverage of your backup data, you have to keep 6 months of these enormous full dumps. >>Lastly I'm not sure I understand why an incremental backup cannot be run on >>the Isilon. Please explain. NAS devices are closed operating systems, so you can't install a TSM client on them. If you are accessing the data via CIFS shares, you can run an incremental backup by putting the TSM client on a Windows machine and backing up the data via the UNC name or mounted drive letter. (Or do the equivalent using a UNIX client for NFS shares.) The problem with that, it means that you are scanning the file tree via the CIFS share, which is much slower than scanning the file tree on a local hard drive. Then you are pulling the identified changed data across the network to the Windows machine running the TSM client, then across the network again to the TSM server. If your file tree is millions of files, it's dirt slow. But you get a true incremental TSM backup that way, and the data can be managed at the file level with normal TSM management classes/retention rules. Much better than keeping TB of NDMP dumps, but the question is how long it takes. KEEP YOUR SHARES SMALL if you want to do it that way. I have customers where we've solved the problem by running multiple proxy servers, each responsible for 1-2 shares, so that all the shares can get backed up daily. But it's a lot more work for you, than using the -snapdiff API, which is designed by Netapp to address the problem (and works well).
