Re: [ADSM-L] Isilon backup
2012-02-12 13:56:42
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).
|
|
|