On Mar 20, 2010, at 00:57, Edward Ned Harvey wrote:
I used NDMP up till November, when we replaced our NetApp with a
Solaris Sun
box. In NDMP, to choose the source files, we had the ability to
browse the
fileserver, select files, and specify file matching patterns. My
point is:
NDMP is file based. It doesn't allow you to spawn a process and
backup a
data stream.
Not quite.
It can reference files, but only by specifying where they are in an
opaque "data stream" (see §2.3.5.2 of the NDMPv4 spec [1]):
The file locator data in the file history record is in a data
service (OS) specific format. To the DMA this information is an
opaque string. This means that the DMA will not attempt to interpret
it. In order to determine the location of a file in the backup data
stream, the DMA will send the complete file history record for the
corresponding file history record to the data service, the data
service will calculate the starting location and the length of the
byte string to be read from the original backup data stream. The DMA
will use this data to manipulate the tape service to retrieve the
selected data.
So the backup software (DMA) simply knows the tape on which the file
is on, and the starting byte of that tape, but if you want to restore
a file from (say) a NetApp share or export, you have to send the bytes
to another NetApp which can interpret the stream. It's not like the
byte stream is in a known format (tar, cpio, or zip) that can be
interpreted by anyone. (Unless you reverse engineer the format of
course.)
After a filer ("NDMP Data Service") is told to start backing up, it
can tell the backup software ("NDMP Data Management Application"--DMA)
about files via the NDMP_FH_ADD_FILE command (see §4.3.1 [1]).
[1] http://www.ndmp.org/download/sdk_v4/draft-skardal-ndmp4-04.txt
So technically Oracle can implement an NDMP service on (Open)Solaris,
and backup vendors could interface with that and send the raw ZFS data
stream to tape. As the Solaris kernel traverses the file system, and
comes across directories and files, it would tell the backup software
about the file (path, owner, group, etc.) and where it is in the
stream sent to "tape" (LTO, VTL, etc.). On file restoration, the
backup software would then have to send the (opaque-to-it) data stream
from tape to another Solaris box that could interpret it.
This is of course in the case of a CIFS share or NFS export, where the
filer (NetApp, Sun 7000 series, Celerra) has some knowledge of the
file names, and wouldn't work on a raw LUN--unless the filer starts
parsing the LUN for disk formats like is done with VMware's VMDK
format and NetBackup, where they can figure out the files.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
