Salesforce

NDMP Backups: dump vs. smtape

« Go Back

Information

 
Symptoms
Resolution

In DPX, there are two different methods (or types) you can use with NDMP backups and NetApp filer appliances: dump and smtape.

Dump is the default and most prevalent backup type. It backs up data at the file level. The dump type can back up a file, directory, qtree, or entire volume (exception, it will not backup up the .snapshot directory itself, but can backup individual snapshots in the .snapshot directory). In addition to backing up data in files, the dump type can back up the following information about each file (when applicable):

  • UNIX GID (Group ID), owner UID (User ID), and file permissions
  • UNIX access, creation, and modification time
  • File type
  • File size
  • DOS name, DOS attributes, and creation time
  • Windows NT Access Control Lists (ACLs)
  • Qtree information

A dump backup uses a snapshot of your data, so you do not need to take the filer or volume offline before initiating the backup. It names each snapshot it creates snapshot_for_backup.n, where n is an integer starting at 0. Each time the dump command creates a snapshot, it increments the integer by 1, but the filer resets the integer to 0 when it is rebooted.

When Data ONTAP executes multiple dumps simultaneously, the dumps create multiple snapshots. For example, if Data ONTAP is running two dumps simultaneously, you find these snapshots in the volumes from which data is being backed up: snapshot_for_backup.0 and snapshot_for_backup.1. When you are backing up from a snapshot, a dump does not create an additional snapshot.

You can use the dump type backup to back up data from a SnapMirror or SnapVault destination volume. The dump command uses its special snapshot to copy data to tape. The basic limitation of the dump backup type is that it works exclusively at the file level. This means that incremental backups will require all changed files to be backed up again (not just the changed blocks). It also means that metadata that is not associated with the file (that is, is not listed above) - but is rather associated with the volume, like SnapMirror status information, snapshot/SnapVault/SnapMirror serial numbers, etc. - will not be backed up either.

The solution for the latter is smtape backups (short for "SnapMirror to Tape")

In Data ONTAP versions before 7G, smtape backup was a separately licensed feature. Starting with 7G, a license is no longer required.

You may use SnapMirror to back up a volume from a source filer to tape in the following situations:

  • You want to establish a SnapMirror relationship between two filers, but the transfer time of the baseline transfer between the SnapMirror source and the SnapMirror destination is very high (for example, the two filers are in different geographical locations and connected via a slow WAN).
  • You are backing up SnapVault secondary storage data to tape for offline storage or to protect against the possible loss of the SnapVault secondary.

Before we discuss that, however, it is important to note that smtape backup does have significant differences, namely, contrary to dump backups, it does not allow file-level restores (the granularity does not go below the volume level). smtape is an "all-or-nothing" backup type (that is, you can only restore a full volume). The fact that it is a block-level backup means you may get a performance increase in relation to dump backups if you have a lot of very small files (since the file system overhead is bypassed). However, this is generally far outweighed by the lack of file-level restores.

smtape is very useful in the following two scenarios:

1) You want to establish a SnapMirror relationship between a source filer and a destination filer over a low-bandwidth connection. The data change rate is such that block-level, incremental snapshot mirroring from the source to the destination over the WAN is possible, but the initial base snapshot is too big to transfer over the WAN.

In this situation, it will be more convenient (and realistic) to first back up an initial base snapshot image from source to destination using a temporary storage tape that is physically transported from one site to the other. Then set up incremental SnapMirror updates to the destination filer via the low-bandwidth connection.

This method requires tape drives to exist physically at both locations and to be configured in Backup Express using smtape NDMP.

Also, as with most SnapMirror situations, to prevent slow tape-to-filer performance, it is recommended that the destination filer disks be the same size and in the same RAID configuration as the source filer disks.

These are the steps required to establish this initial SnapMirror relationship using tape as an intermediary:

On the source filer, use DPX (configured to use smtape type backups) to copy all of the SnapMirror source volume to tape.

Physically transport the tapes generated in the first step from the source filer site to the destination filer site.

On the destination filer, use the vol create and vol restrict commands to set up a SnapMirror target volume.

Use DPX to restore the tapes created in the first step to the destination filer. Then, use the snapmirror update command to manually mirror the first incremental update from the source to the destination filer over the WAN, and/or edit the snapmirror.conf file to set up an incremental update schedule from the source to destination filer.

After completing the first manual or scheduled incremental update over a connection, you can use the snapmirror release command to eliminate the source-to-tape relationship and associated snapshot. Be careful not to eliminate the filer-to-filer relationship (these are separate).
 

2) You want to use SnapMirror to back up snapshots from a SnapVault secondary storage system to a tape drive for disaster recovery and/or to enable longer retention periods (to overcome Data ONTAP's limit on the number of snapshots it can store).

To enable this, you will need a SnapVault secondary filer or NearStore and at least one tape drive. The volume on which the secondary (OSSV/SnapVault backup) qtrees reside must also be configured as a SnapMirror source volume:

On the SnapVault secondary/SnapMirror source filer, use an smtape NDMP backup in Backup Express to copy the volume (configured as a SnapMirror source volume) to tape.

Use DPX in the same fashion (smtape NDMP), to perform incremental updates to tape as necessary.

In the event of a disaster that causes data loss on the SnapVault secondary, or if the need arises to restore an older backup that has expired out of the SnapVault secondary but is still available on tape, follow this procedure:

  • Create a volume of the same size to hold the restored data (using the old volume is ok if the data can be completely overwritten).
  • Set this volume to the "restricted" or "offline" status.
  • Restore the tape contents using a DPX NDMP restore (including all incrementals, if they exist).
  • Use the snapmirror break command to change the volume back to read-writable status.

 

 
Addtional Information
Article Number000007192
TitleNDMP Backups: dump vs. smtape
URL Name40318

Powered by