I agree with that strategy for non-NetApp NAS devices - divide and conquer by 
backing up one filespace at a time, using many proxy machines.  (Your backup 
domain controllers got nuthin' else to do at backup time, do they?)

Unless it's mostly non-changing data that you can replicate.  Some of my 
customers with massive NAS devices are using them for image apps.  Images get 
created and never change, so just 1 replicated copy is usually sufficient.  No 
need to trudge through the filetree every day.

And Skylar is right on that you need to partition the data into manageable 
filespace sizes to start with.  App folks don't like to hear that, but there 
are ways (even with Windows!) to mask drive architecture from applications and 
still have a design that makes it reasonable to back up in a timely fashion. 

NDMP is the horrible reptile/crocodile brain of the backup world.  It hasn't 
improved any, and you are constantly dumping stuff that hasn't changed, it's 
massive amounts of data, and you have to keep the tapes a lot longer than you 
want to, to make sure that you can recovery that 1 file that has extra-long 
retention requirements.  Better to back up just the files that are changed.

Once you get an NAS in the 10 TB range, you'll find you need a dead goat every 
full moon and an unreasonable amount of your time and tape to get those NDMP 
dumps completed.  The reason NAS vendors don't improve on NDMP is not because 
they can't (to wit the NetApp snapdiff API).  Let's just say those boxes aren't 
designed to help the customer in any way.  I wish when looking at a NAS device, 
customers would calculate the cost of backing it up into the TCO.  Then we'd 
get better stuff on the market.
(soapbox off)

W


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Skylar Thompson
Sent: Monday, December 17, 2012 3:02 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Isilon Backup

We only backup via NFS (we have no ACLs so CIFS would be an unnecessary and 
huge performance hit). Here's what we've done:

1. Partitioned our data such that we can have a large number of filespaces that 
we backup separately (in hindsight, we might have wanted to go with separate 
nodes, but oh well).

2. Setup a pool of schedules that are each responsible for some number of 
filespaces. Each schedule will proxy using asnode to the underlying storage 
node.

3. Setup one node definition per schedule that will hold one schedule, and that 
the dsmcad process will connect as.

4. Farm out those schedules to a pool of 5 pizza-box Dell systems with 10GbE 
adapters running RHEL5. These systems mount each filespace as a separate NFS 
mount point to keep TSM happy.

Using this strategy we're backing up a pair of Isilon clusters with about 2.5PB 
of aggregate disk space. Presently TSM is tracking 130 million file versions 
and 1.5PB in backups, and we rarely exceed our 24-hour per-filespace backup 
window.

There's a number of concerns I would have running NDMP backups:

1. It's unclear to me how to avoid doing a full backup. It seems that 
token-based backups would be an option but the documentation is fairly sparse.

2. It's one more thing to learn and that can break in mysterious ways.

3. When restoring the data you're tied to the specific platform that performed 
the backup. This means that if you no longer have an Isilon system, you can no 
longer access the backed up data. This for us was the most scary aspect out of 
NDMP.

-- Skylar Thompson (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine

On 12/17/12 11:42 AM, Huebner, Andy wrote:
> Just general questions on Isilon backup.
> How do you backup your Isilon, NDMP or CIFS/NFS?
> NDMP FC to tape or Ethernet through the TSM server?
>
> We are to the point in our project to figure out the backup bit.
>
>
> Andy Huebner
>