Networker

Re: [Networker] NDMP - tar versus dump

2006-12-08 11:56:58
Subject: Re: [Networker] NDMP - tar versus dump
From: NetWorker <networker AT cresend DOT com>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Fri, 8 Dec 2006 09:26:12 -0600
Here's my explanation of NDMP. I got to see it invented and did some of the
first implementations back with Intelliguard, working initially with NetApp.
I'm going to use backup terminology instead of NDMP terminology because from
an NDMP perspective, the backup client is the NDMP server, and that can be a
little confusing. Here goes:

The most important thing to understand about NDMP is that NDMP is a control
protocol, not a backup format. The NDMP backup format is arbitrary
(implementation-specific) and defined individually by each storage platform
vendor. This is by design, because the goal was to drive the functions that
needed to be implemented out to the people who are motivated to get the
function done.

So NDMP simply defines the rules for how to create a universal backup client
that any (NDMP-compliant) backup vendor can control. The goal was to enable
anyone to make a file appliance that can be backed up in a standard way, and
anyone to be able to back it up.

But because the backup client software is written by the storage vendor
instead of the backup vendor (because backup vendors aren't motivated to
support every little appliance in the universe, but the vendor of the
appliance really wants his customers to be able to back his box up), that
means the contents of any particular backup image are opaque to any
particular backup vendor. It's a "black box" to all the backup vendors. The
only people who understand what is going on inside this black box are the
storage platform vendors.

But you can still do file restore, because the NDMP protocol tells backup
vendors how to do that in a standard way. The backup vendor positions the
tape to the right place (the start of the backup image) and tells the backup
client software what to restore. The backup vendor doesn't care about the
details of how the "client" software does it - he just sends the right codes
to the storage box, and the storage box restores the files that were
requested.

Legato now encapsulates NDMP backup images inside the standard NetWorker
save stream data, allowing it to be multiplexed with other save streams and
providing some pretty cool capabilities. But inside of the save stream that
contains this NDMP stream, the actual NDMP data itself is still opaque.

A lot of engineering work went into making this function smoothly in the
NetWorker universe. NetWorker transparently positions within a multiplexed
save stream and the NDMP backup client thinks it's talking to a
single-stream (non-multiplexed) tape drive. NetWorker creates an abstraction
that obscures this difference and NDMP is happy.

But that doesn't mean NetWorker knows what is inside the NDMP data itself.
NetWorker still needs the actual storage platform NDMP software to do the
work of unpacking this data into individual restored files.

Steve Warren
Cresend Consulting Services

-----Original Message-----
From: Stuart Whitby [mailto:swhitby AT DATAPROTECTORS.CO DOT UK] 
Sent: Friday, December 08, 2006 3:11 AM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: NDMP - tar versus dump

You can't take ndmp backups between different systems?  Any idea why?
=20
AFAIC, and I haven't tested this in any way, an ndmp backup is a =
standard way of backing up files.  Getting back those files should =
follow the same standard.  As such, the only problem that I'd maybe =
expect to see with the restore of these files would be with ownership =
and file permissions, and not with the data - the same problem that =
you'd get with tar, actually.  Or is it an "underlying filesystem" =
thing?
=20
Okay, I know this isn't specifically a NetWorker question, but I'd just =
be interested to have this clarified.  It's certainly something which we =
may have to do as backup admins at some point...
=20
Cheers,
=20
Stuart.

________________________________

From: EMC NetWorker discussion on behalf of Curtis Preston
Sent: Fri 08-Dec-06 07:17
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] NDMP - tar versus dump



I'd prefer tar.  It deals with active filesystems better than dump.  And
it's more portable.

Say you ever change your mind and decide to move to NetApp, Onstor, or
Agami.  Your NDMP backups won't work on any of them, so you'll have to
do legacy restores using a Unix box.  If the backup format is tar,
you'll be able to use just about anything that smells of Linux, possibly
even Windows.  If it's in dump format, your choices are much more
limited.

---
W. Curtis Preston, Author of Backup & Recovery and Using SANs and NAS
VP Data Protection
GlassHouse Technologies


-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On
Behalf Of Darren Dunham
Sent: Thursday, December 07, 2006 12:44 PM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] NDMP - tar versus dump

> We are setting up NDMP backup from our celerra (DDS attached LTO3
drives,
> 2gbit fibre channel) and have the option of either dump or tar.  Both
seem
> to work, I don't see major differences in the time to backup between
the
> two.  I'm seeing throughput averaging about 35MB/sec for both methods
on a
> single datamover.
>
> Any reason to go with one method over the other?
> Any tricks to improving the throughput?

Does DAR work with either or both?  If all the data is in both, and the
recovery setup can find the data, I don't know that I would care about
the format.

--
Darren Dunham                                           ddunham AT taos DOT com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=3DNETWORKER

To sign off this list, send email to listserv AT listserv.temple DOT edu and =
type "signoff networker" in the body of the email. Please write to =
networker-request AT listserv.temple DOT edu if you have any problems with this 
=
list. You can access the archives at =
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=3DNETWORKER



To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type
"signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=3DNETWORKER

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

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