The Oracle ZFS Storage Appliance product supports direct backup of replicas and replica snapshots with the "zfs" backup type. It is not necessary to first clone a replica dataset (project or share) in order to back it up.
To enable replica backups, apply the corresponding deferred update. For more information, see Deferred Updates in Oracle ZFS Storage Appliance Customer Service Manual.
Replica backups require software version 2011.1.0 (or later on the source.
If the replica backup will be restored to the source with the original replicated dataset, the source must run software version 2013.1.4 (or later).
To back up a replicated project or share, input the ZFS dataset name without a snapshot extension into the DMA. ndmpd uses the appliance software to determine the latest complete replica snapshot to back up. To specify a replica dataset for backup, use copy and paste to avoid mistyping long replica dataset names which may include a UUID.
If a user-generated snapshot extension is included, ndmpd backs up the indicated user snapshot. If a system-generated extension is included (begins with .rr) the backup fails and generates a message that is logged to the DMA console.
Persistent holds are taken on backed-up snapshots when the backups complete. This is necessary for future incremental backups, which use current snapshots as a base, otherwise the replication subsystem may delete replica snapshots it no longer needs. Holds are released by ndmpd when the snapshots are no longer needed.
Persistent holds can be cleared manually. When deleting a replica snapshot with a hold on it, a confirmation is displayed warning of the potential impact to ongoing or future NDMP backups. Snapshots required by the replication subsystem cannot be deleted.
If incremental backups are not needed, prevent persistent holds by setting the DMA UPDATE parameter to no (UPDATE=n). UPDATE=y is the default mode. For more information about the UPDATE NDMP environment variable, see the whitepaper NDMP Implementation Guide for the Sun ZFS Storage Appliance (http://www.oracle.com/technetwork/server-storage/sun-unified-storage/documentation/index.html).
Continuing (incrementing) a backup series across a replication reversal or sever is not supported; instead, start a new backup series. Use a full (Level-0) backup for the first backup after a replication state change has occurred, such as on a new source after a reversal or sever has taken place.
Static snapshot extensions that do not change per level are NOT supported for user-generated replica snapshots (snapshots not starting with .rr). This prevents name collisions, which generate an error and can cause replication to fail.
Some DMAs do not support zfs-type replica incremental backup and restore operations for snapshot extension name changes per level. To conserve appliance space and ensure that such snapshots are not preserved for future incremental backups, set UPDATE=n at the time of backup of replica. User-generated snapshots can be removed manually.
Even if no user data has changed in a restored dataset, changed metadata can cause incremental replica restores to fail. To avoid this, always roll back to the base snapshot before incremental replica restores by setting the ZFS rollback before restore parameter to Always.
For non-incremental replica backups, such as for one-off backups, set UPDATE=n so future snapshots are not saved and consume space. Some older replica snapshots preserved for future incremental backups, such as those created by setting UPDATE=y, may no longer be needed and waste space. These snapshots are safe to manually destroy. Snapshots needed by the replication subsystem cannot be deleted. Unneeded snapshots can be deleted after confirming the warning message about possible impacts to ongoing or future NDMP backups if the snapshot is deleted.