ADSM-L

Re: [ADSM-L] Isilon backup

2012-02-12 21:50:15
Subject: Re: [ADSM-L] Isilon backup
From: Grant Street <grants AT AL.COM DOT AU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 13 Feb 2012 13:43:31 +1100
On 13/02/12 05:48, Prather, Wanda wrote:
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).

To be clear the NDMP protocol can do incrementals (depending on the
storage and it's implementation of NDMP). It is TSM that does not
support incremental NDMP.

Grant

<Prev in Thread] Current Thread [Next in Thread>