Template Version: @(#)onepager.txt 1.30 06/09/28 SMI

Copyright 2009 Sun Microsystems

1. Introduction
   1.1. Project/Component Working Name:
        zfs-based ndmpd backup

   1.2. Name of Document Author/Supplier:
	Janice Chang (Janice.Chang@Sun.COM)

   1.3. Date of This Document:
|	February 16, 2010

   1.4. Name of Major Document Customer(s)/Consumer(s):
	1.4.1. The PAC or CPT you expect to review your project:
	       Solaris PAC

	1.4.2. The ARC(s) you expect to review your project:
	       PSARC

	1.4.3. The Director/VP who is "Sponsoring" this project:
	Mike Shapiro

	1.4.4. The name of your business unit:
	Open Storage

   1.5. Email Aliases:
	1.5.1. Responsible Manager: Dan.Maslowski@Sun.COM
	1.5.2. Responsible Engineer: Janice.Chang@Sun.COM
	1.5.3. Marketing Manager: mws@Sun.COM (Mike Shapiro)
	1.5.4. Interest List: archive-sw@sun.com, david.pacheco@sun.com,
		ryan.arneson@sun.com

2. Project Summary
   2.1. Project Description:

	This project introduces a new backup and restore method into ndmpd,
	zfs send and receive.  It also introduces support for ZFS volume
	backup and restore, also using send and receive.

   2.2. Risks and Assumptions:

	We are currently in the process of verifying compatibility with
	data management applications (DMAs) that are certified with
	Solaris ndmpd.  Some of the DMAs may not expect a backup type
	other than the standard (e.g. tar, dump, etc.), even though the
	NDMP protocol specifies that "Backup types are NDMP Server
	implementation dependent" (Section 3.2.5).  Though we have
	designed around this, we still need to test with each DMA and
	possibly have heads-up meetings with vendors regarding the new
	backup type.  It may not be necessary that we ensure
	compatibility with all currently certified DMAs before the new
	feature is delivered.

	The following is not a dependency but it would be good to have
	the below CR fixed in time for the delivery of this project:

		6884007 zfs_send() can leave temporary holds around 

	The following is a dependency:

		6921421 zfs receive: recursive restore fails


3. Business Summary
   3.1. Problem Area:

        Solaris ndmpd currently cannot perform block-level backup.
        Fast block-level backup for ZFS volumes and file systems 
	is a desirable feature. 

   3.2. Market/Requester:

        Gap in the SS7000 product portfolio. 

   3.3. Business Justification:

        Fast backup is a competitive advantage. 

   3.4. Competitive Analysis:

        This feature improves backup and is a competitive advantage. 

   3.5. Opportunity Window/Exposure:

        The SS7000 series of storage arrays are currently shipping. 
	Competitive backup is a requirement.

   3.6. How will you know when you are done?:

	A ZFS dataset (zvol or file system) will be able to be
	successfully backed up to tape and restored using the modified
	ndmpd, using the full and incremental options as well as the
	dataset, recursive, and package options.

	The test plan for the project will have been executed with 
	an acceptable level of success.
	

4. Technical Description:
    4.1. Details:

	This project introduces a new backup and restore method into ndmpd,
	zfs send and receive.  It also introduces support for ZFS volume
	backup and restore, also using send and receive.

	The Solaris NDMP service provides backup and restore services
	per the NDMP protocol when used in conjunction with client
	data management applications (DMA) (PSARC 2007/397).
	Currently, ndmpd, which implements the service, provides these
	capabilities for file systems only, via the "tar" and "dump" backup
	methods (internally implemented using "ustar").

	For file systems, the new method can be used in situations where full
	file system backup and restore is desired (such as disaster recovery).
	It will not allow for partial dataset backup/restore due to the
	current nature of the technology.

	The capability of backing up and restoring ZFS volumes (zvols)
	is intended to be used in conjunction with COMSTAR, where LUNs
	are created using zvols.

	Both full and incremental backup/restore will be supported.  For
	incrementals, only level-based backup/restore will be supported
	for the initial release.

	The new feature is targetted primarily for the SS7000 series
	appliance, and it will be delivered into Solaris Next.

	Three options will be available under the new backup type
	(which will be called "zfs").  These options are "dataset",
	"recursive", and "package."  The first is a backup/restore of
	the named dataset.  The second is a backup/restore of the
	dataset hierarchy, excluding intermediary snapshots.  The third
	is a backup/restore of the dataset hierarchy that includes
	intermediary snapshots.  (See the functional specification
	for details.)

	There are several advantages to the use of zfs send/receive
	within ndmpd.  These include the transparent handling of ZFS
	metadata; the preservation of ZFS dataset sparseness across a
	backup and restore; and the potential for improved performance
	over traditional backup methods.

	Note: The new method will be available for NDMP protocol
|	version 4 only.


    4.2. Bug/RFE Number(s):

	6801803 Use of ZFS to optimize NDMP performance
	6801805 NDMP Backup and restore COMSTAR zVOL at the
		block level

    4.3. In Scope:
	Full backup and restore of ZFS filesystems and zvols, with
		three options as described in Section 4.1.
	Incremental backup and restore (level-based)

    4.4. Out of Scope:
	Selective restore; direct access restore.  
	Backup of a partial dataset (except in the case of incrementals).  
	Token-based incremental backup.  
	Backup of clone origin snapshot if clone and origin snapshot
	are in different dataset hierarchies 
|	Support for NDMP protocol versions 2 and 3

    4.5. Interfaces:
	With other NDMP hosts: per NDMP protocol 
	With NDMP clients: per NDMP protocol, with
		specific instructions for "zfs" backup type
		(associated NDMP environment variables, path syntax, etc.)
	With admin: server-side SMF properties, errors to DMA,
		error logs, etc.
	Backup stream format: Header + zfs send stream
	Interface with metadata plugin: new functions, etc.

	(Refer to Section 5, Reference Documents for more details)

    4.6. Doc Impact:
	The ndmp man page will need to be updated, along with
	other relevant documentation, including SS7000 help 
	documentation.  Additions will be made to a new NDMP 
	admin guide that is planned by the AIE group.

    4.7. Admin/Config Impact:
	A new backup type, "zfs", is introduced, along with
	a new NDMP environment variable, new path syntax, etc.

	(Refer to Section 5, Reference Documents for more details)

    4.8. HA Impact:
	N/A

    4.9. I18N/L10N Impact:
	N/A

    4.10. Packaging & Delivery:
	Same as current ndmpd

    4.11. Security Impact:
	No new security impact

    4.12. Dependencies:

	N/A

5. Reference Documents:

	See case directory (when available)		

6. Resources and Schedule:
   6.1. Projected Availability:
  	Q1CY10

   6.2. Cost of Effort:
	1 development engineer - 12 months
	3.5 test engineers - 2 months each
	2-3 technical writers - 1 month total

   6.3. Cost of Capital Resources:

	Development:
		. x86 (MP) system (2)
		. Windows clients (2)
		. tape library (1)

	QC Testing (estimate):
		. x86 (MP) systems (10)
		. sparc (MP) system (1)
		. Windows/Linux clients (3-5)
		. tape library (3-5)

   6.4. Product Approval Committee requested information:
   	6.4.1. Consolidation or Component Name:
		ON

	6.4.3. Type of CPT Review and Approval expected:
		Standard

        6.4.4. Project Boundary Conditions:
		N/A

	6.4.5. Is this a necessary project for OEM agreements:
		No

	6.4.6. Notes:
		N/A

	6.4.7. Target RTI Date/Release:
		Q1CY10 Solaris Next

	6.4.8. Target Code Design Review Date:
		Q1CY10

	6.4.9. Update approval addition:
		N/A

   6.5. ARC review type:
	Standard

7. Prototype Availability:
   7.1. Prototype Availability:
	Basic zvol prototype demonstrated in 2009

	Fuller-functionality prototype currently available

   7.2. Prototype Cost:
	N/A