NDMP Backup and Restore: Dump and SMTape

NetApp supports two different backup data formats, Dump and SMTape:

  • Dump is essentially a file system backup of the volume. The Dump format is generally used to back up specific files, folders, or qtrees and selective file restore is a priority. Dump can only archive data from one point-in-time. The point-in-time data is either at the root of the volume backed up by an automated snapshot that the controller coordinates in the background, or the data is backed up from a specific preexisting snapshot.

  • SMTape is a block-level image of the entire volume, including all snapshot data. SMTape is generally used when a full volume restore is necessary for disaster recovery or for seeding a secondary remote storage system for subsequent SnapMirror synchronization.

    Note that SMTape is supported for 7-Mode Data ONTAP as well as for Clustered Data ONTAP version 8.3 and later. For Clustered Data ONTAP backups and recoveries, SMTape can be used only when all the nodes in the cluster are upgraded to Clustered Data ONTAP 8.3 (or later). For recovery, the volume must be of type DP (Data Protection) and should be placed in the restricted mode. At that time, you must give the volume read/write access by issuing the following command:

    system smtape break -vserver <vserver-name> -volume <volume-name>

    For additional details see the NetApp Clustered Data ONTAP 8.3 Data Protection Guide at https://library.netapp.com/ecm/ecm_download_file/ECMP1610205.

  • For additional information about Dump and SMTape, read knowledge base article 42154.

For a comprehensive reference on NetApp tape backup methods, see the NetApp Data Protection Tape Backup and Recovery Guide, which is part of the core Data ONTAP documentation set.

The following table summarizes the differences between using Dump and SMTape for protection of primary data (CIFS/NFS or LUN storage) and secondary data (DPX Block, NetApp OSSV or, NetApp SnapVault).

Note. Dump backup and restore does not preserve NetApp storage efficiency features such as A-SIS deduplication and volume compression. Thus, data backed up to tape and restored from tape could be significantly greater than reported by the deduplicated or compressed source volume. SMTape, on the other hand, preserves all enabled storage efficiency features and only backs up and recovers the amount of data actually used in the volume.

Operation
Dump
SMTape

Backup Primary Data

Dump is a Snapshot, copy-based backup and recovery solution from Data ONTAP that helps you to back up files and directories to a tape device and restore the backed up data to a storage system. Typically, the latest snapshot is backed up and is used to archive data beyond what the local snapshot storage can hold. See Defining an NDMP Backup of the Latest Snapshot with for 7-Mode. The backup contains the data from a single snapshot or from a special temporary snapshot if the live volume data is selected. The backup size is typically less than for SMTape since snapshot data is not included, but may depend on volume storage efficiency settings. See the DPX Best Practices Guide in the Catalogic Knowledge Base. Dump supports base, differential, and incremental backups for primary data sets.

SMTape is used to back up the entire NetApp volume, including all snapshot data. This can increase backup time and space usage compared to Dump, especially if the volume storage is large due to the number and size of retained snapshots. SMTape is useful if restore requests usually require pulling data from multiple snapshots (points-in-time). SMTape is also used to seed a NetApp storage system for SnapMirror if the bandwidth between the two storage systems is slow. SMTape is a full volume base backup. It does not support incremental or differential backups.

Backup Secondary Data

Backs up a single point-in-time DPX Block backup. Since file history is supported, individual qtrees, which usually correspond to DPX specific client devices, can be selectively restored. Backup of a DPX Block backup is always a base backup to tape, because Dump relies on file modification timestamps.

Backs up all recovery points to one tape archive. This is useful for disaster recovery purposes when multiple recovery points are desired. If the SMTape recovered volume contains snapshots corresponding to DPX client backups in the Catalog, you can use the management console to recover DPX client data. This recovery is typically accomplished with the alternate secondary feature. If there are no corresponding catalog records, which could occur if the DPX client data is expired from the Catalog, BMR still functions and you can use manual IA map procedures to recover specific files. Backing up all recovery points at once may save space over Dump if the data protection plan requires offsite storage of multiple recovery points. SMTape is a full volume base backup. It does not support incremental or differential backups.

Restore Primary Data

Dump selectively restores individual files or LUNS as needed.

SMTape requires recovering the entire volume, which requires sufficient space for the recovery.

Restore Secondary Data

Individual qtrees, which correspond to DPX client devices, can be recovered. This can help save space and recovery time for large jobs that include many servers and/or many physical devices.

All data for all servers covering the available recovery points must be restored at the same time.

BMR

Manual procedures are necessary to identify the server in question, recover the data, and then create the necessary snapshots to access DPX block-level client data. Windows BMR partially automates this process.

All the recovered data is immediately available for use by BMR. No additional setup or configuration is needed.

IA Map

Manual procedures are necessary to identify the devices desired, recover the data, and then set up an iSCSI map to a supported host.

If the DPX block client data is available to browse in the management console, then the alternate secondary feature can easily access the data. If the DPX client data has expired, then the same manual procedures are needed to set up an iSCSI map to a supported host.

Note the following considerations related to DUMP and SMTape:

  • Backup of LUN or VMWare VMFS datastore data by either Dump or SMTape requires planning. Neither the storage system nor VMware quiesce this data when a Dump or SMTape NDMP backup is requested. Live data in the volume may not be in a consistent state, and a backup may result in a recovery point containing corrupt data. Whenever backing up live LUN or VMWare VMFS datastore data, use one of the following methods to ensure a consistent state:

    • Coordinate a consistent NetApp snapshot first and then back up that snapshot.

    • Use the DPX scripting features to quiesce the data just prior to backup.

    • Use an external process to take periodic primary storage snapshots, which you then protect with SMTape.

  • Dump backup depends on file timestamp modification to discern incremental and differential status. Since DPX Block backup modifies all files at each backup, a Dump backup of such files effectively runs as a base backup. If your volume contains DPX Block backup data, use only Dump base backup. Any other method in this case introduces confusion and possible error. For more information, read knowledge base article 46383.

  • Dump backup cannot back up the .snapshot folder of a volume. The .snapshot folder contains multiple snapshots of the volume. Each snapshot is considered a full base backup of the entire volume. Attempting to back up this folder results in backup tapes usage equal to a volume base backup multiplied by the number of available snapshots. Thus, the NetApp Dump engine does not permit backing up the .snapshot folder.

  • If you select multiple subdirectories as source objects, DPX backs up the entire common ancestor. If you select more than one folder within the volume, the backup includes the entire volume. If you attempt to select data in more than one snapshot, the selection rolls up to the .snapshot folder, which is an invalid operation that results in a backup job error. If you select data in the volume and from a snapshot, the roll up backs up the entire volume, but the backup does not include any snapshot data. If you need to individually back up separate folders within a volume, break up the request into separate backup jobs.

  • Selecting the data format to use, Dump or SMtape, requires consideration based upon the desired data protection plan:

    • Dump backup is appropriate when a specific point-in-time data set must be sent offsite. However, Dump may not be appropriate if every recovery point must be sent offsite because Dump in this case can consume a significant number of tapes. Dump is well suited for CIFS and NFS primary storage archival, since the backup of these volumes can follow the familiar tape efficient base/differential/incremental protection paradigm. However, Dump is not tape efficient for frequent offsite storage of DPX Block snapshots, as each backup is the equivalent of a base backups.

    • SMTape is appropriate when multiple recovery points must be sent offsite in bulk. A weekly or bi-weekly SMTape backup can be effective in sending many days of recovery points offsite in a tape and space efficient way. SMTape is also very useful for seeding SnapMirror relationships. With SMTape backup, it is generally recommended to run the backup at approximately one half of the intended on-disk snapshot retention period. For example, if your storage volume contains 30 days of snapshot recovery points, use SMTape backup every 15 days. This strategy retains an overlapping window of redundant backup that helps mitigate tape media problems such as loss or destruction of specific tapes.

You cannot run both Dump and SMTape backups of a single NetApp storage server. Select only one method in the Configure Enterprise window.

Last updated